As you develop more and more React apps, you will start to "feel the need" to do things in a certain way. You will start to organize your code in a way that "makes sense" to you and your fellow developers.
But, you will also learn, through mentorship or the "school of hard knocks" that some things, attitudes and practices are essential to you as a developer.
What follows in this guide is a collection of the "best practices" I have learned and applied over the years. They are not specific to frontend/React developers alone; the principles herein are useful and usable whether you are responsible for building the API backend or the React app that is responsible for the UI of your platform.
So, what are the best practices you should follow as a React developer?
Here are a few:
Use the Latest Stable Version
Always use the latest stable version of the framework or library you are using. But before you migrate, test the new version in a sandbox (separate test repo, testing server, etc.) to make sure there are no breaking changes, deprecated API/features, etc.
Also, make sure that the dependent libraries and frameworks you are using are compatible with the latest version of React (or whatever framework/library you are using.) For example, if you are using `react-bootstrap` for styling, make sure that the latest version of React works neatly and bug-free with it.
As a rule of thumb, it is a great idea to always keep tabs on the libraries/frameworks your app needs and test whenever a new version of those libraries come out to make sure that your app doesn't use libraries/frameworks with stale or deprecated code/features. Or, worse, that your code references out-of-date features and does't work.
I once was asked (at a large enterprise company) to update a React app that used a much older version (and expectedly) dependencies that were also much older. I happily (and naively) started using the newer features of React to create the components confident that it will work out alright. Then, came the demo on the "sprint call".
Then, came the flop. And, then came my realization that the version that the app used was generations older (in web years) than the latest one.
Organize Your Components
Always put all your components in an explicitly-named `src/components/` folder. Depending on the complexity of your React app and how the components are related to each other, you may want to create sub-folders inside the `src/components/` folder.
For example, in the
MediaLite app, I organized the components into sub-folders, like this:
- `src/components/layout/`: This folder contains all the app-wide UI components, like `Header`, `Footer`, etc.
- `src/components/auth`: The authentication-related components go here, such as `Register` and `Login`.
- `src/components/manager/`: To contain all the components related to the writers (`Editor`, `ManagerHome`, etc.)
- `src/components/publisher/`: To contain all the components related to content published in the app, such as `Article`, `ArticlesHome`, `Comment`, etc.
- `src/components/auth/`: To handle all the components related to the authentication logic, including, `Register`, `Login`, etc.
This way, it is both easier for you to add new components to the right sub-folder as well as for your fellow developers to know where to look for a certain component that does X or where to create a new component that should do Y.
There are many benefits of being "modular" in how you organize your app's code. Being able to look at a codebase and seeing that it is logically-organized is one uber benefit that can't be beaten.
Keep API Logic Separate
Most React apps you create will need some API or another (no matter how simple or complex it is) to get, set, update and delete component data/state.
You should create an `api` (or similar-named) folder at the root of your app's `src/` folder. Then, put all the API logic (API classes, custom API hooks, etc.) in it.
This way, you can just import and use the API objects or hooks as needed in your components and other files of your React app. For a sample of how to do this, please see the
MediaLite: API Section (on Github) and how it is organized.
Don't Need It? Don't Use It
It is tempting to one to use any "new" or "cool" library, framework or tool that you come across or that comes highly-talked about in your developer community. Wait and think before you use it.
Does your app absolutely need to use that library to make a certain feature of your app work? Or, could you write some custom code or use some built-in feature to get the same result?
If you just want to try out that new tool/library, feel free to create a project to play with. But, don't use it in your production code without being sure whether the tool will stick around (i.e. be actively developed) or if your app has a critical non-negotiable need for it.
You have probably heard the saying "if it aint broke, don't fix it"? Well, if you don't absolutely need it, don't use it.
Be Reluctant, But Observant and Vigilant
This is related to the best practice above.
Keep an eye out for what is making the rounds in your developer community: new tools or libraries, new versions of existing tools or news you need to know. But also be smart enought to know which tools you must use, which ones you could use and which ones you should avoid like a pandemic.
But be vigilant. A new tool or library may just be the "silver bullet" you were waiting for you to help you implement or refactor a critical feature of your app.
Just know what is happening, what to take or what to leave ... even if for just this moment.
Write the Docs
A software developer is one-part code-writer and one-part great communicator. And, a good part of being a great communicator is being able to write simple, logical and readable documentation. This documentation can take the form of:
- Project Docs: Working on a project? Write the documentation incrementally as you create different parts of the app. Remember to include the "why" (you used one tool versus another or how you organized your app in a certain way instead of another), the list of tools and libraries you used and why and similar technical considerations.
Also, include how to start, stop, test and refactor the app. It might seem "intuitive" to you now, but let a developer take a look at your code sans documentation a few months down the line, and you will then realize the importance of proper documentation for your app.
- Open Source Documentation: Got a project you are stoked about but that has terrible, non-existent or flaky documentation, jump in and help write, proofread and document the project. You won't only get developer "stars", you will build your developer profile and reputation along the way. And, that, my friend, could be career-changing in a multitude of ways.
- Tutorials: It is not unheard for a developer to discover a new tool/library, read the documentation and then create a working project/app out of it. Then, months or years later, when the same developer looks at the tool, it looks as strange to him as something he has never used before.
I have personally encountered this many times. Then, when I come back to try and use the same tool or implement the same solution, I am back to square one: the docs, an article here or a Youtube tutorial there.
One great solution to this is, whenever you learn something new or implement a feature that took you some time to learn the ropes about, take a half or full hour of your precious personal time to outline the steps you took, the library's API that you used and write a tutorial that can help a fellow developer new to the tool/technique implement the same thing you did.
Writing a tutorial has a two-fold benefit: You will help another developer learn and implement the same thing logically and quickly.
You would have also documented your process, gotchas (bugs) and how to properly implement such a solution. This, in the future, will be a much better reference for you than having to read another person's guide or looking at the official docs.
Plus, the information in the guide or tutorial you wrote will be much easier for you to consume since it came from your mind initially.
Always Be Reviewing (Old Code)
Good developers write good new apps and implement useful new features. Great developers know the importance of looking at their old (project/app) code to see how they did things, check for what they can refactor (if necessary) and, thereby, measure their progress on the "developer-meter".
So, don't just write new code. Review your old code. It is like pair programming, except it is just the old you and the new you at that code editor.
Read the Docs
When you come across a new tool, don't just go for a "crash course" or "intro" tutorial on Youtube and call it a day. Dive into the docs and see what gems you can find therein.
Knowing the underlying API of your (new) favorite library or framework helps you not just with learning the design decision that went into the project but also makes you a master reference for that project. If you work alone, you will spend less time on Google and StackOverFlow.
If you work with a team, you will be "super man" or "10x developer" reference on that tool/library/framework for your team. And, that, is a great feeling ... and potential component for a raise during the year.
Learn the Basic Building Blocks
Are you learning a new framework to build a web app? Learn the underlying programming language and achieve some level of mastery in it, not just a "passing familiarity." For example, if you are learning React (or Angular or VueJS), learn its underlying building blocks, including:
- JavaScript: Which is what almost all your app's files will be written in.
- HTML: Which is basically the same thing as the JSX markup you will be writing. (I know, JSX is a JavaScript extension; but beyond the cases where you are writing or referencing JavaScript code in your markup, the JSX you are writing is actually HTML.) So, learn and master HTML to some degree, at least.
- CSS: If you are going to writing a web app with a sleek UI, you might as well learn CSS. The React documentation won't teach you this; the React docs will simply show you how to use CSS in/with your JSX markup. So, grab a book or video or tutorial series and learn the styling language of the web.
The same thing applies if you are working on an app's backend. Learning Django? Get the handle on Python first. Want to work with Rails? Learn enough Ruby first to work with first.
When I first started doing web development with Django, I posted a question in one of the Django user groups for help on how to implement a certain piece of logic in my Django views (aka "controllers"). A kind soul responded and added that that wasn't a Django-specific issue and that it just requires a better understanding of Python (which was the underlying programming language that the Django framework used).
So, don't just consume the docs for the framework. Learn the underlying language and tools that were used to develop it. The better you master the basics, the more confident and prepared you are to implement more useful and complex features in your apps, frontend or backend.
Give Back to the Community
Take from the community (official documentation, Q&A posts, and user groups) to help you learn, master and profit from the library or framework you are using.
Then, when you have benefitted from the community, use some of your precious time to devote to giving back to the community and "pay it forward" with:
- Writing tutorials to help others new to it or less experienced than you.
- Contributing to the official docs.
- Answering questions on the community's developer forums.
- Writing docs for your projects and apps. It might only help a handful of developers, depending on how large your organization is, but one developer you help to well-equip is a seed you would have planted in the community garden. It will germinate, grow and help somebody else.
Did I miss or skip a best practice that you are very particular about? Please, add it in the comments below.
What's Next?
That's a great question.
- Starting taking notes of the features, APIs and associated tools that your framework works with or depends on.
- Create some app(s) using your newfound knowledge. And, keep the best practices discussed in mind: be modular, document, give back!
- Then, write a tutorial or two based on that.
- Help a fellow developer on a discussion forum, Q&A board or local tech group.
Technical Reference
These resources are not exhaustive, but are a good starting point. Use these and add more to the list as you progress in your journey.