Antonello Zanini
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:

Exploring Stylex And The New Generation Of Styling Libraries

Exploring StyleX and the new generation of styling libraries

StyleX is a build-time, type-safe CSS-in-JS library recently open sourced by Meta. Explore StyleX and the evolution of styling libraries.

Ibadehin Mojeed
Feb 29, 2024 ⋅ 9 min read
Building High Performance Ecommerce Sites With Astro

Building high-performance ecommerce sites with Astro

Learn to set up a completely custom Astro ecommerce implementation that’s also highly performant and type-safe in this straightforward guide.

Onuorah Bonaventure
Feb 28, 2024 ⋅ 64 min read
Implementing Vector Search With Open Ai, Next Js, And Supabase

Implementing vector search with OpenAI, Next.js, and Supabase

Let’s build a Next.js app that implements vector search using Supabase and OpenAI to offer better search experiences for users.

Peter Ekene Eze
Feb 27, 2024 ⋅ 11 min read
Comparing React Native BLE libraries

Comparing React Native BLE libraries

Discover the most popular libraries for enabling Bluetooth Low Energy (BLE) in React Native apps, allowing them to interact with Bluetooth hardware on iOS and Android platforms.

Fimber Elemuwa
Feb 26, 2024 ⋅ 4 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