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:

Why Kimi K2 is a frontend game-changer

Agentic AI for 5x less: Why Kimi K2 is a frontend game-changer

Kimi K2 doesn’t just tell you what to write or how to solve a problem; it writes the code, executes the tasks, and gets stuff done.

Chizaram Ken
Aug 22, 2025 â‹… 8 min read
Gemini CLI vs Codex CLI: A Comparative Analysis

Does Gemini CLI fall short? Here’s how Codex compares

Compare Codex CLI vs Gemini CLI for real-world coding tasks. See strengths, weaknesses, and which AI CLI fits your developer workflow best.

Emmanuel John
Aug 20, 2025 â‹… 8 min read
Is Next.js Still Developer-Friendly?

Is Next.js still developer-friendly?

The question isn’t whether Next.js is good or bad; it’s whether the productivity gains are worth the complexity tax.

Chizaram Ken
Aug 20, 2025 â‹… 5 min read
Don’t Let AI Erase The Next Generation Of Dev Leaders

Don’t let AI erase the next generation of dev leaders

As AI tools take over more routine coding work, some companies are cutting early-career dev roles — a short-sighted move that could quietly erode the next generation of tech leaders if we aren’t careful.

Jack Herrington
Aug 19, 2025 â‹… 6 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