React, at its core, follows Atomic Design inherently by encouraging developers to keep components as simple and as broken down as possible. From this simplicity, we can create more complex components and containers of components to create the user interfaces of our applications. Following these patterns gives us, as developers, an easy to manage (and test) ecosystem within our React applications.
Katia’s article does a great job discussing the importance of not overburdening components with too much application or context-specific stuff. This separation between Presentational and Container Components is what leads to a flexible and capable set of components that can travel to a lot of different places.
One thing I will flag is that the article talks about how simpler components (like atoms and molecules) ought not to have state attached to them, and to that I’d say I’m not so sure about that. A text field molecule might have a disabled state, error state, or success state attached to it. A dropdown molecule has an open and closed state. All of that is perfectly fine. Again, I think the main crux of the article is to keep business logic and app-specific stuff away from reusable UI building blocks.