2021-05-21
2465
#react
Antonello Zanini
49484
May 21, 2021 â‹… 8 min read

Optimize React apps using a multi-layered structure

Antonello Zanini I'm a software engineer, but I prefer to call myself a technology bishop. Spreading knowledge through writing is my mission.

Recent posts:

how to add custom fonts in React Native

How to add custom fonts in React Native

Custom fonts provide your apps with a unique identity. Explore modern ways to add custom fonts in a React Native app, including Google Fonts.

Nitish Sharma
Apr 7, 2025 â‹… 10 min read
React Useref Hooks

How to use the React useRef Hook effectively

Learn how to use React useRef for managing references, avoiding re-renders, and applying best practices in functional components.

Rahul Chhodde
Apr 7, 2025 â‹… 11 min read
How to eliminate render-blocking resources — CSS and JavaScript

How to eliminate render-blocking resources — CSS and JavaScript

Use Lighthouse to eliminate render-blocking resources, which block the first paint of your page, in both CSS and JavaScript.

Anna Monus
Apr 4, 2025 â‹… 8 min read
Mocking Complex APIs With Mirage JS

Mocking complex APIs with Mirage JS

Mock complex APIs with JavaScript’s Mirage JS library including JWT authentication, relational data, role-based access control, and more.

Emmanuel John
Apr 4, 2025 â‹… 10 min read
View all posts

5 Replies to "Optimize React apps using a multi-layered structure"

  1. I think I disagree with some of the structures shown. I’ve always found feature focused layers to be much easier to work on (vs type based layers).

    The reason being, most units of work tends to be feature focused. If I am working on Foo, I don’t want to open 5 different layers for reducers, actions, views, blah, blah. This encourages commits to have wide surface area.

    By organizing by feature, commits will have low surface area. You would modify foo/action.js, foo/reducer.js, foo/view.js, foo/blah.js. Everything is in 1 layer.

    This is much easier for both the reader and writer.

  2. You assume that only view layer should use other layers? Let’s look on this example. I have component with user details and it is in component layer. I want to use it on many views and I don’t want to duplicate code so I want to pass only user ID to component, but in this case I have to use API request inside component and finally I use other layer in component layer. Where I should use a API request? Each time I want to use user details component and pass result to component?

    1. Agree with u Jarek , its really practical to use API or other general logic into Component . But its also worth attention that we may abuse business logic into Component too much. So I guess author could give more example on how to minify the business logic pollution.

  3. Hi, I am the author. Thanks for your feedback!

    I would like to add that the best architecture depends on what you are working on. Based on my experience, such a structure works quite well, but it is not the only one possible. The one you presented is a very good alternative, for sure. I have worked with this file structure in many projects, with other team members, and we are all satisfied.

    At the same time, I don’t exclude the possibility that other architectures and file structures might be better than this one, especially in contexts other than those that helped me conceive it.

  4. Hi, I am the author. Thanks for your feedback!

    The view layer is the only one that might need to import files from all other layers. For example, the component layer should depend on the view layer, while the other way around is feasible. I hope that’s clear now!

Leave a Reply