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 p...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Great advice! It's clean to wrap hooks like useSelector, useEffect and useMemo in a custom hook and not in the component.
Hi, @dikamilo, can provide an example? I would like to get a clear idea through it.
Thanks.
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.
Also code splitting is pretty important for frontend scaling
Great insights on scaling React projects! 👏
Adding to the second point about creating a component library, consider implementing versioning for your library. It ensures that changes or updates to components won't unexpectedly break existing projects using the library. Versioning also facilitates better communication within your team and with other developers who might be using your component library. This practice adds an extra layer of control and predictability to your project's evolution.
Keep up the excellent work! 🚀✨
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.
That's a good way to organize too! Thanks for suggesting
Thanks for sharing 😊👏
Good article and I agree having a good state management from the start will make your life easier on when the codebase grows.
Nice write up. Thanks for sharing.
wonderful read
Great article! These are solid points
a great article indeed 👍💯✨
I really liked the atomic design practice 🖤
Me too
Awesome advice, will take note of when I make my next react app!
Thanks, Jeffrey! Awesome tips.
Totally agrees, I didn't do the global styles and it is giving me a headache now.
Awesome tips, thanks for sharing them!
I like your point to create your own ui library.
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.)
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.
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.
Awesome post. I will apply this on my next projects. I loved it.
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.
Hi Ziv, I'm using
index.tsxfor components because I'm putting styles, types, tests under a folder named after the component's name.index.tsxserves 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.tsxlike this.Then it's easy to import components in one line, like what Material UI is doing.
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.
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.
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
Please check out my reply to Tamas Rigoczki.
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.
Please share a project code for better understand.