Do you use React's components/containers approach in your projects?

Question

React

This is how I develop. However, I noticed a negative to this approach. Are there alternatives?

Answer 1

If we are talking about the concept of a container in the form of a React component:
Read Atomic Design for React, or Feature Sliced
​​If it’s completely simpler, then you can achieve that React will only be for rendering the view, and all logic will leave the React level, or most of it. This can be ideally implemented, for example, with an effector. For the last six months, there are no containers anywhere.

Why AtomicDesign will save your soul.
Some people think that this approach is too confusing. Makes you think a lot about the location of the elements, and when it gets more complicated, move it to other directories. If you ask Rodionov, there are several more reasons why you should not use Atomic Design. In this post, I want to talk about the opposite: how to use the approach of Brad Frost in React.
At the very beginning, you need to understand whether your team needs this architectural design. It is enough to answer the following questions:
- how many people will develop the frontend?
- how many teams will use your code?
- how many projects use the same UI design?
If you have one small project with only two frontends, you don't need AtomicDesign. If your project has about 10 front-enders and a second project is planned, you need to think about implementing AtomicDesign. Especially if projects in your company use a common library of components or implementation is planned.
Many people ask me the same question: "Where to put component X?". The answer is for all components at once: AtomicDesign is an approach that provides you with the architecture of UI components - nothing more. That is, you can put containers / connectors / routers in any directory, except for ui. I always recommend that you start by reading the author's book at atomicdesign.bradfrost.com, but I'll describe the ingredients a bit below.
It should be immediately understood that AtomicDesign components are business entities, this is what designers and developers can operate together. No need to include various block appearance timers or tab switching logic here. Even if they are described in the form of components or HOCs.
So why does all this save souls? To understand the answer, let's look at another front-end topic: typed javascript. Typescript / Flowtype was invented to impose certain restrictions on the code so that it would be easier to maintain and read in the future. AtomicDesign imposes restrictions on designers and front-end developers, obliging them to communicate in the same language of business entities.
But it is necessary to add a few words about the support of the AtomicKit component library. At some point, the problem of complicating the components arises, and many people ask themselves: "What should we do, do we really need to move the component from atoms to molecules?" - Not.
Before starting development, it is necessary to carefully design a set of components and not change its purpose while it exists under that name. If you need to complicate the component, add some elements to it - just create another component that will add what you need. So you do not break compatibility with the entire library and implement the fun you need