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:

SOLID Series: Liskov Substitution Principle (LSP)

A deep dive into the Liskov Substitution Principle with examples, violations, and practical tips for writing scalable, bug-free object-oriented code.

Oyinkansola Awosan
Jun 6, 2025 â‹… 10 min read
Modern CSS Carousels: No JavaScript Required

Modern CSS carousels: No JavaScript required

This article walks through new CSS features like ::scroll-button() and ::scroll-marker() that make it possible to build fully functional CSS-only carousels.

Saleh Mubashar
Jun 6, 2025 â‹… 5 min read
hidden coast of developer elitism

It’s time to break the cycle of developer elitism

Let’s talk about one of the greatest problems in software development: nascent developers bouncing off grouchy superiors into the arms of AI.

Lewis Cianci
Jun 4, 2025 â‹… 9 min read
When To Use Flexbox And When To Use CSS Grid

When to use Flexbox and when to use CSS Grid

Flexbox and Grid are the heart of modern CSS layouts. Learn when to use each and how they help build flexible, responsive web designs — no more hacks or guesswork.

Leonardo Maldonado
Jun 3, 2025 â‹… 9 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