Component Responsibilities

Hi. I have a question sort of similar to this one: React props best practice

But my question is more about where markup should go. Wherever you decide to put markup has an effect on the architecture of your components.

For example, I’m working on the first front end project, a quote machine. I’m using reactjs. There is to be an element with id “quote-box” with an element inside it called “text”. There is also to be a clickable button and a link inside quote-box.

Theres different ways I could do it. I could put minimal markup in the 1st level child components and do most of the markup at the top level. Or I could put all the markup in the Quote(child of top level App) component. Or I could have Quote render its own markup AND the markup of the child(html) elements. Or I could render child components of Quote and let them supply all of their own relevant markup.

The last option is the one I’m thinking of doing. But I think deeper nesting leads to more complicated event management. In the future I’ll learn to deal with state a better way with redux or some of the other options, but for this project I’m not using external state management. However, I want to approach this project as if it were a real one (except for proper state management) so I can develop and build on good habits.

Any guidelines on this anyone can share?

1 Like

It’s hard for me to understand what you mean without seeing it.

If I were conceiving this, I might come up with this heirarchy:


There are other ways to organize it, but this is a good one. You can get away with being less strict on a project this small, but as a processional React developer, this is what pops into my head when I think of this project.

What goes where? Quote markup goes in the Quote component. Markup and styling that surround the Quote and Author but not Controls go in QuoteBox. To me, markup should be pushed down the chain as far as is reasonably possible. The App doesn’t need to know how to show a quote - that’s what the Quote component is for. There might be some opportunities for reusable components (Do you need to implementations of a button or could you have one and feed it props?) but maybe on a project this stall, as a learning tool, you don’t worry about that.

Logic should (in general) be at the closest common ancestor of whoever needs it.