How do I architect a React project?

Programming is a bit like gardening. Rather than trying to deal with bugs, we prefer to keep everything neat and tidy, lest we end up in a wilderness jungle. Poor architectures can drag us back and make it easier for bugs to get into the system.

There are several ways to structure your project. I believe that the evolution of the architecture according to your circumstances is far better than sticking to some dogma. Next I will introduce some basic methods for you to think about.

Put everything in one file

The simplest item can be put into a file. And that's the way I chose to handle my webpack configuration. The biggest benefit of this approach is that everything you need is in this file. If you're organizing your code from top to bottom, it's a good idea.

You can start the work of a react project in a similar way. When you are prototyping, you want to try to figure out the hierarchy, you can comb the components in a file. This will become cumbersome as the file grows slowly. For example, the processing of the test will be more difficult than the original. Merging the file branches will also be a problem.

Split into multiple files

The obvious way to solve this problem is to start splitting things up. At the beginning you can move the components into separate files, like this:

Here index.jsx can be used as an entry for the application. It uses Reactdom.render to render the App and let this part start up. The App then uses Note to do something interesting. If I want to have another component, simply add it below the/components.

If you want to test your component, you can add a separate directory for testing and develop the test code in that area. You can even try out test-driven development methods to consider the constraints of the components before they are implemented.

Using this basic architecture you can go quite far. Although it also has its limitations. For example, how do you work with styles? The main style file Main.css may become quite large. Its prospects are a bit scary.

Place components in their own directory

The last question in the previous section can be solved by adding more architectures to the system. Here's what you'll end up seeing:

The name of the ① component (for example, APP.JSX) begins with an uppercase letter to make them easier to find. The Index.js file provides us with a neat entrance to these files, so we can easily use them elsewhere.

② now each component is an individual entity. We can illustrate this by using examples such as CSS modules. Extracting these components from the project makes it easy to manage them independently of each other now.

③ now the tests associated with each component can be found effortlessly. We can also still have a/tests directory under the project root directory to handle higher level tests.

Of course the real project complexity will be higher, and the current architecture will begin to break through the constraints of complexity. Do not know if this is suitable for your idea?

To add a view to a combination of schemas

This may be where opinions begin to diverge. I'll let you compare your points of view in the comments. Here is a kind of architecture that I feel comfortable with:

Because we have a route now, the App becomes redundant. Now it's more like a view in charge of its responsibilities. They are simply following our routing rules and using components based on their respective requirements.

This architecture can be further expanded, but even it will be constrained as the project grows. I recommend adding a concept like "functional characteristics" between the view and the component. Feature is the aggregation of components in some way and form, of course, the functionality itself can be aggregated.

Handling Data issues

Given that most practical applications have to deal with the data in varying degrees, our current architecture may not be enough. This depends to a large extent on what type of architecture you choose. It might be possible to put some data issues into the current schema. Or you might introduce new root-level catalogs, such as/actions,/constants,/libs,/reducers, and/stores, and here are just a few ideas for you.

Summarize

There is no right way to structure your project. Instead, you should remain pragmatic. Sometimes just reorganizing a project can help you make it clearer and make it easier for you and others to understand. I am very curious about what type of architecture you have chosen for your React project and why you are making such a choice. So please feel free to comment at the bottom of this.

To make it easier to learn more about the world of React, we have prepared a special package, some of which come from independent developers. It can be used for a limited period of time. If you want to deepen your understanding of React, now is a good time to get started. I hope you will enjoy the books, videos and consulting services included.

The last question in the previous section can be solved by adding more architectures to the system. Here's what you'll end up seeing:

Original link: How to Structure a React Project?

Juho Veps?l?inen

Translator: Jay Micro magazine-leo Xu

See more content

Scan QR code to download liberation app, see more exciting content, find the same fellow

How do I architect a React project?