This question has more to do with how we think about abstractions than React itself. In plain CSS, you can specify a specialized parent -> child rule that affe

This question has more to do with how we think about abstractions than React itself. In plain CSS, you can specify a specialized parent -> child rule that affects the component just in this context. Or you can have two different classes for the two cases. You can also define two distinct container elements that compose the same underlying component, but the container takes care of the margin depending on the context. All of these options work with React as well. However, it lets you go further: you can pass the context info into the component, which then adjusts itself. Or the parent element in both cases can wrap the component inside appropriate html elements, or have specific container components, all using imperative Javascript to construct the view. With React you have the entire repertoire of programming abstractions to solve this problem with, while traditionally we had to work within the confines of CSS's cascade. But in cases where internal layout of the component is very different, we have to make a call between adding conditionals within a component vs giving distinct names to the different cases and extracting multiple components. I veer towards having more explicit names in my codebase and so extracts new components more often than I litter existing ones with conditionals. Also, in practice, components are surprisingly self-contained and independent of context.