Dan Abramov talks about a convention for structuring React components, which resonates with me very much. I talked about how I tend to be frustrated with a lot of the React demos, projects, and boilerplates I come across:
In a popular course, you create a “fish” component, which immediately limits what kind of content can be poured into that component. I tend to create fairly dumb, reusable components (i.e.
media-block,card,hero, etc) and keep specific business logic, content, and context away from that file to help ensure components can be portable and versatile. I know this is possible in React, but again I just haven’t really come across any projects that I feel set things up in this manner. I’d love to see projects that feature a library of dumb, abstract components, which then are consumed by more application-specific components.
I like creating a clean separation between dumb UI components and the super interactive stuff that makes an application tick. This gist linked up in the article talks about how to create cleaner, reusable UI components and handle logic and data elsewhere. This makes a ton of sense to me, and makes me breathe easier.
As someone who builds design systems for organizations, I’m more focused on the dumb, reusable, presentational components rather than the implementation/application-specific components. Of course I need to be aware of the kinds of data being poured into, say, a data table component or an accordion, and I need to build hooks for that stuff to happen. But I’ll leave the thorny details of wrangling that data to somebody else.