DEV Community 👩‍💻👨‍💻

Cover image for 5 Good practices to scale your React projects easily
Jeffrey Yu
Jeffrey Yu

Posted on

5 Good practices to scale your React projects easily

For most React developers, it's easy to just get our hands on writting new lines of code. However, we sometimes missed keeping them organized and planned for future use as the project scales.

Having a plan for scaling can help you:

  1. Reuse and reduce development time
  2. Organize project and prevent project reconstructions
  3. Show you are good developer by taking consideration of the project and other devs :)

Here are 5 lessons I learned from scaling my React projects. They help me to plan ahead for my projects while writting pretty React code.

1. Always start with state management

When a project was small, I jumped right into writing state for individual components. However, it got messy when I wanted to sync up states for several components and tried to to use props and callback functions.

Always start with a state mangement tool, whether it's Redux, Recoil, or context and hooks. Even if a project is small, you'll need Authenticaiton and Alert to be managed globally.

React state managment

Besides, state management seperates logic from components. When handling backend calls, it serves like a controller/service layer between UI and database. State and actions in this layer can be reused across many components.

A tip here is always track waiting status for backend calls for conditional component rendering. It saves you from unnecessary errors and a nice loading spinner shown to the user.

2. Make your own component library

I found that even when I'm using a UI library like Material UI, I still need customization on props, logics, and styles for my project.

Create a custom components library allowed me to reuse them across pages and even exported to other projects.

Include styles, tests, types, and Storybook templates (recommended) for each custom component. A good practice is to organize the library in atomic design like the following.

custom-components
├── atoms
│   └── CustomButton
│       ├── CustomButton.tsx
│       ├── CustomButton.types.tsx
│       ├── CustomButton.styles.tsx  
│       ├── CustomButton.test.tsx
│       ├── CustomButton.stories.tsx
│       └── index.tsx
├── molecules
│   └── CustomDialog
└── organizations
    └── CustomTable
Enter fullscreen mode Exit fullscreen mode

3. Define types

As we know, JavaScript is dynamic-typed language. When a project scales, props passed across components and functions increases.

If there is no type checking, many unnecessary errors involving edge cases like null and undefined could happen. Define types also increase readibility of code.

It's better to start with or migrate to TypeScript if possible, but define PropTypes also works.

4. Use global AND specific styles

Styling is always a big headache for frontend devs. We have to handle both unified styles and individual styles.

CSS meme

If a project has UI design provided like Figma, try to define styles in global theme first. It's better to define them in the theme provider of a UI library to easily make customization on defined palettes. The theme provider also handles light & dark themes for you.

For styles of individual components, try to include them in custom components library mentioned above. If they are specific to one component, include them in a styles file under that component.

The rule of thumb is to include styles at the top level needed for reuse.

5. Sync pages folder with routes

Previously, I made pages and components folders quite a mess, keeping two in only either one folder.

Then I learned that it's better to organize the pages folder in sync with the routes. This increases readability for other devs to understand the website structure, like the following.

pages
├── events
│   ├── index.tsx
│   └── event
│       ├── index.tsx
└── user
    └── index.tsx
Enter fullscreen mode Exit fullscreen mode

events correspondes to /events, and event correspondes to /events/:id.

I'm having the same structure for the components folder to correspond components to a page where they are used. But you can also have a /components folder under each page, and make the components folder for other use.


These are my good practices on planning a React project for scale, and everyone has their own way. The two rules of thumb to conclude these good practices are:

1. Seperate & Reuse
2. Organize for readability

Happy coding! 🚀

Top comments (34)

Collapse
 
dikamilo profile image
dikamilo

Always start with state management

I will add here: abstract here from your current state management tool. Create custom hooks that will provide data. It will be easy to change from for example React providers to Redux when needed just by replacing logic in custom hooks and not refactor every component.

Collapse
 
jeffreythecoder profile image
Jeffrey Yu Author

Great advice! It's clean to wrap hooks like useSelector, useEffect and useMemo in a custom hook and not in the component.

Collapse
 
agnel profile image
Agnel Waghela

Hi, @dikamilo, can provide an example? I would like to get a clear idea through it.

Thanks.

Collapse
 
allobrox profile image
Tamas Rigoczki

Great article, Jeffrey! I am coming from backend and scaling had very different meaning, at least for me! I wrongly misinterpreted code scaling with application scalability, which is a very different abstraction level.

Thanks for you, the pieces now fell into place.

Collapse
 
jeffreythecoder profile image
Jeffrey Yu Author • Edited on

Yes Tamas, frontend scaling is different than backend. Here I'm talking about how to scale code (size of client app), where modular and extendable code are the keys.

For handling more load like scaling backend, frontend can apply caching and reducing unnecessary requests to backend. Server-side rendered clients could have more cases.

Collapse
 
omercohen990 profile image
omercohen990

Also code splitting is pretty important for frontend scaling

Collapse
 
marwababelly profile image
marwababelly

Thanks for sharing 😊👏

Collapse
 
d4rthv4d3r profile image
Julián Chamalé

Great article, however I disagree with the atomic design as it's not intuitive and building it on top of a library makes it confusing. I prefer the material-ui approach for organizing code in inputs, display, etc.

Collapse
 
jeffreythecoder profile image
Jeffrey Yu Author

That's a good way to organize too! Thanks for suggesting

Collapse
 
andrewbaisden profile image
Andrew Baisden

Good article and I agree having a good state management from the start will make your life easier on when the codebase grows.

Collapse
 
wilmela profile image
Wilmela

Nice write up. Thanks for sharing.

Collapse
 
madza profile image
Madza

a great article indeed 👍💯✨

Collapse
 
madza profile image
Madza

wonderful read

Collapse
 
israelmitolu profile image
IsraelMitolu

Great article! These are solid points

Collapse
 
zeffk profile image
Huzaif Qazi

I really liked the atomic design practice 🖤

Collapse
 
lyavale95 profile image
LyAVALE95

Me too

Collapse
 
ironcladdev profile image
IroncladDev

Awesome advice, will take note of when I make my next react app!

Collapse
 
etnan profile image
Etnan

Thanks, Jeffrey! Awesome tips.

Collapse
 
thatanjan profile image
Anjan Shomodder

That meme is 100% true.

Collapse
 
rafaelcg profile image
Rafael Corrêa Gomes

Awesome tips, thanks for sharing them!

Collapse
 
obayit profile image
Obay Abdelgadir

Totally agrees, I didn't do the global styles and it is giving me a headache now.

Collapse
 
rkallan profile image
RRKallan

I like your point to create your own ui library.

Collapse
 
elsyng profile image
Ellis

I'll respectfully disagree :o).

For me React is about seeing "component", as opposed to seeing "global". For me React is component-based programming

That includes: state management and styling. I'd avoid anything global as much as possible, and make a component independent (non-sharing) as much as possible.

(Forget folder hierarchies. Stick to a single level of folders as much as possible, such as: components, hooks, pages. The modern IDE's will find the file for you. I think folder trees cause duplication and redundancy.)

Collapse
 
jeffreythecoder profile image
Jeffrey Yu Author

The main reason for doing state management and styling globally is to allow reuse and easier modification in one place.

If you don't do state managment, you still need to communicate state between components, which don't make them independent but coupled. And seperating the logic to handle state and backend calls from components makes the logic independent to use by various components.

Folder hierarchies makes better readibility, but it's really a good pratice where it doesn't impact performance so it's your choice to use it or not.

Collapse
 
za5dwunasta profile image
Magdalena Motyl

Yes, fully agree :) Styles and states IMHO should stay as close to the component that needs it as possible, as long as possible.
It reduces the number of rerenders + it is easier to flexibly reuse components.

If you start coupling components with a global state/store sooner or later you won't be able to reuse it in any part of the app that does not use the same global store. And then decoupling it might be a nightmare.

Collapse
 
wyarejali profile image
Wyarej Ali

Awesome post. I will apply this on my next projects. I loved it.

Collapse
 
zivni profile image
Ziv

Great writeup.

The only thing I don't like is your use of index.tsx every where. I prefer naming my files by the component name inside (usually one component per file). This apply to other kind of files too.
That way it's much easier to find things, instead of tons of files with the same name.

Another tip is not to use default exports. It's much easier to find uses.

Collapse
 
jeffreythecoder profile image
Jeffrey Yu Author

Hi Ziv, I'm using index.tsx for components because I'm putting styles, types, tests under a folder named after the component's name. index.tsx serves as an access point to a component or a page, where exports can be organized.

I definitely agree with deconstructing exports, but naming one as default also helps identify the exported component. I would do exports in index.tsx like this.

// components/atoms/CustomButton/index.tsx
export { default } from './CustomButton'
export * from './CustomButton.types'
Enter fullscreen mode Exit fullscreen mode
// components/atoms/index.tsx
export { default as CustomButton } from './CustomButton'
Enter fullscreen mode Exit fullscreen mode

Then it's easy to import components in one line, like what Material UI is doing.

import { CustomTextField, CustomButton } from 'components/atoms'
Enter fullscreen mode Exit fullscreen mode
Collapse
 
edmundo096 profile image
Edmundo Elizondo • Edited on

As far I understand, this practice assumes a configured tree shaking on a package bundler.
I have seen sites where unused components and even tests files are still referenced from the index file (and downloaded).
Well configured, it leaves less and shorter imports.

Thread Thread
 
jeffreythecoder profile image
Jeffrey Yu Author

Yes Edmundo, tree shaking strictly bundles only explicitly exported modules and avoids unnecessary ones. I believe it's an essential practice for good production build. I also use lighthouse to scan and optomize.

Collapse
 
fastndead profile image
Umbetov Asman

i wouldn't say these tips work on behalf of 'scaling' the app per se. these are '5 Good practices to make your React project more maintainable in the long run' i think

Collapse
 
jeffreythecoder profile image
Jeffrey Yu Author

Please check out my reply to Tamas Rigoczki.

Collapse
 
spock123 profile image
Lars Rye Jeppesen

I am still baffled how React is a mess when it comes to State management, typing, and dealing with async (backend) requests.

Compared to stuff like Ngrx it seems so ... grotesquely old.

Collapse
 
elias_soykat profile image
Elias Soykat

Please share a project code for better understand.

🌚 Life is too short to browse without dark mode