This is probably a bit of an aside to the implied problem at hand but.. considering this from the React side of my company's codebase, I wish this question was at least kept softly in mind when designing components. I frequently encounter components that were very clearly created as "one-shot"s that are then unfortunately extended by piling on more props and conditional behavior by the next developers who need something like the current component but ever so slightly different.
Often the solution initially would have been to separate out the presentation side of the component from the behavioral wrapper that chooses what data needs to be shown / what actions are performed by interactions. By the time the component arrives at my lap (because I too need something same same but different), however, it has become a monstrosity that can take a long time to disentangle via ADD (anger driven development).
I think asking oneself a simple question such as "how would someone make this search box work with a different data source?" would probably result in components that are decomposed into simpler, smaller parts that allow for much easier reuse and adaptation.
On the flip side, I'm also of the belief that the second developer to touch a component is necessarily better equipped to answer that question, so the onus should probably be on them to make the proper generalizing changes.
(I'm still trying to figure out how to write a document that expresses this idea more concretely to my coworkers because it often isn't quite this simple..)
> On the flip side, I'm also of the belief that the second developer to touch a component is necessarily better equipped to answer that question, so the onus should probably be on them to make the proper generalizing changes.
This.
Given a long enough timeline, pretty much all abstractions fail. People are too timid to replace them when they do, and given enough churn, the code gets out of hand.
I think there are some quick wins that doesn't take too much dev time but makes components reusable or at least easily make it reusable in the future.
- Like you've already said, prefer splitting components into purely presentational components("dumb components") and components with some logics ("smart components")
- If you are using design components, make sure to pass on those props. e.g. if you are using Chakra, pass BoxProps to <Box>.
- try to split out logic into hooks. This can be very specific to the current use case.
These aren't hard things to do but lets you quickly create a generic component by only changing the smart component/hooks or only reuse the dumb components with another specific hook, if the use case is a bit different.
Yes! This is such a great summary of the pains of front-end, although I'm sure these pains transcend any one arm of software development. What laypeople may see as a simple search box is probably a monstrosity of spaghetti code that was coded by a single person under a surprise deadline and interfaces with 3 different APIs (recent suggestions, search-on-type quick results, full search...) don't forget the many different states- focus, active, disabled, loading- necessary to consider and to build styling around. Everything is tightly coupled and semantically horrific because that's what the designers and managers demand for this year's particular flavor of the product's design under whatever deadline has been sprung on those involved in actually building the thing.
I think the interactive nature of these things and years of 'training' that the average computer user has endured to expect how a search box behaves tends to hide the hidden complexity lurking in UI elements everywhere. Another great example is a <select> element.
Most abstractions will accept one layer of ugly hacks for situations they were never meant to deal with. I'd recommend waiting until the second layer of hacks starts to form, then refactoring with what you've learned, since that second layer of hacks is when things start to really fall apart.
Right - the former case is one that’s unavoidable and, in the case the first developer didn’t get it quite right, should ideally be covered by code review, but doing a good code review is IMO pretty hard, and giving that sort of feedback requires that the reviewer also understands the problems at hand (which in our case is frequently not the case as our development teams are small and we’ll often have a backend focused dev reviewing another backend focused dev’s frontend work).
And in the latter case, at least in my organization, we don’t often have hard “must meet” deadlines, but instead have more self-imposed deadlines that become externalized and concrete when these “deadlines” (aka ship date estimates) are communicated org wide.
So all I can figure to do is give zoom talks, write documentation that’s shared to all developers, and try to encourage coworkers to take the opportunity to push soft deadlines back if needed to pay down tech debt.
Often the solution initially would have been to separate out the presentation side of the component from the behavioral wrapper that chooses what data needs to be shown / what actions are performed by interactions. By the time the component arrives at my lap (because I too need something same same but different), however, it has become a monstrosity that can take a long time to disentangle via ADD (anger driven development).
I think asking oneself a simple question such as "how would someone make this search box work with a different data source?" would probably result in components that are decomposed into simpler, smaller parts that allow for much easier reuse and adaptation.
On the flip side, I'm also of the belief that the second developer to touch a component is necessarily better equipped to answer that question, so the onus should probably be on them to make the proper generalizing changes.
(I'm still trying to figure out how to write a document that expresses this idea more concretely to my coworkers because it often isn't quite this simple..)
¯\_(ツ)_/¯