How do I manage directories

This idea is probably the part that worries a lot whether it is a front-end or a back-end.

How to partition directories in React?

The goal with React is to create a tree of React elements and render them to the screen. The React element tree is composed of components. Then, components inevitably have a hierarchical structure. Since components have a hierarchical structure, it is natural to configure the directory structure according to the component hierarchy.

In this article, I will summarize some of the representative design patterns that provide the 'standard' for dividing the hierarchy.

Design pattern

Presentational and Container Component Pattern

This pattern was first introduced by Dan Abramov in 2015.This is the most basic and famous design pattern.

After the first introduction, Dan Abramov updated the article in 2019, and it is said that he no longer recommends dividing components according to the pattern he introduced. Although it is said that it is not recommended, this pattern was devised for a certain necessity in the past, and now let's look at why it is not recommended, and if so, what is recommended.

This approach divides components into two categories: 'Container' and 'Presentational'.

The presentational component is a component that is only responsible for being displayed on the screen. Because it is only responsible for being visible, it does not depend on other parts of the application and may know how data is imported and changed. It's just a component that shows what you've received. It can have a state, but only a state related to the UI.

The container component is a component in charge of the operation. It has no DOM markup structure or style because it deals only with behavior. Brings or changes data to be displayed in the Presentational component and defines the behavior of the component.

Advantages

• You can separate your interests. Because the function and UI are clearly separated, the structure of the code is easy to understand and the maintainability and reusability are excellent.

• Reusability can be improved. Presentational components do not depend on other parts, so they can be freely used in other containers.

• Markup is convenient. If this pattern is used, the 'layout component' is inevitably extracted. This layout component prevents you from writing the same markup multiple times.

Why I don't recommend it anymore

Dan Abramov says he doesn't recommend this pattern for two reasons. It is not necessary, but there is a phenomenon of forcing this pattern too blindly, and the work of separating the logic can now be done through Hooks.

If you use logic with Hooks, you can take advantage of being able to reuse not only views but also logic.

Atomic Design Pattern

This pattern was first proposed by Brad Frost in 2013. It's older than I thought, but this pattern was originally for a design system. That is, it refers to a method of efficiently composing components in the design system.

Brad Fost borrows terms from chemistry to describe UI components. From 'atom', which is a small unit component such as a label, input, or button, 'molecule', which combines several atoms, 'organisms', which combines several molecules, and 'template', which is the layout to put the created components in, and the components created above the template. It consists of injected 'pages'.

Remember, this design pattern breaks down components into units of functionality, not views.

This configuration of components has the advantage of excellent UI reusability, but the initial cost to build a design system is high and the logic and state must be down to a lower unit, so props drilling issues may occur.

A glimpse of how it is used in practice

Let's see how to apply the atomic design pattern in RIDI .

In the video, the two patterns introduced above are mixed and used.

It is said that Lidi divides components into 3 stages, atom, block, and pages, rather than 5 stages. In this way, props starting from pages can end in 2 steps instead of 4 to atoms, so it seems that the props drilling issue can be prevented.

And the component returns the top-level component with each directory index.tsx. index.tsxmakes it act as a container component, leaving only the logic behind, separating it from the presentational component.

What I felt after watching this video is that you should not divide anything into binary and follow it blindly. I think it is important to know the strengths and weaknesses accurately and to know how to pick and use the ones that you think are good.