gergospel.blogg.se - Reactjs projects

The top level directory structure will be as follows:

I'm also ambivalent about Storybook, but I'll include what it would look like with those files if you choose to use it in your project.įor the sake of the example, I'll use a "Library App" example, that has a page for listing books, a page for listing authors, and has an authentication system. I would recommend setting up your Redux as feature slices either way. I can go either way with this one, but in order for an example to work, and in the real world, decisions need to be made.Įverything here can still apply if you're using vanilla Redux instead of Redux Toolkit. I'm also going to assume the tests are alongside the code, as opposed to in a top-level tests folder. I don't have a very strong opinion about the styling, whether Styled Components or CSS modules or a custom Sass setup is ideal, but I think Styled Components is probably one of the best options for keeping your styles modular.

Global state management - Redux, Redux Toolkit.

Since this article will be opinionated, I'll make some assumptions about what technology the project will be using: The main concept I think is important is to make the architecture focused on feature as opposed to type, organizing only shared components on a global level and modularized all the other related entities together in the localized view. I'm going to show you what I consider to be an intuitive and scalable system for large-scale production React applications. I like to be deliberate about how I organize my applications so they're easy to use, understand, and extend.

Often the case is that whoever sets up the application in the beginning throws almost everything in a components folder, or maybe components and containers if they used Redux, but I propose there's a better way. React gives you a lot of freedom, but with that freedom comes the responsibility of deciding on your own architecture. There is no consensus on the right way to organize a React application.