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 hide scrollbars with CSS

How to use CSS to hide scrollbars without impacting scrolling

Learn how to hide the scrollbar in popular web browsers by making use of modern CSS techniques, and dive into some interactive examples.

Fimber Elemuwa
Mar 4, 2025 â‹… 10 min read

16 React component libraries and kits for improved UI

Discover 16 of the most useful React content libraries and kits, and learn how to use them in your next React app.

Chidume Nnamdi
Mar 4, 2025 â‹… 16 min read
typescript vs javascript

TypeScript vs. JavaScript: Differences and use cases for each

Choosing between TypeScript and JavaScript depends on your project’s complexity, team structure, and long-term goals.

Kayode Adeniyi
Mar 4, 2025 â‹… 4 min read
Understanding UUIDs In Node.js

Understanding UUIDs in Node.js

Generate and validate UUIDs in Node.js using libraries like `uuid`, `short-uuid`, and `nanoid`, covering UUID versions and best practices.

Ukeje Goodness
Mar 3, 2025 â‹… 7 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