React Architecture Tips & Tricks

We’ve all been there—a complicated project, under-resourced and under-documented, with little continuity or direction. Luckily, Bitovi does things differently.

In this post, we’re sharing five tips for organizing your React architecture to help your project run smoothly.

Small and Single Responsibility Principle (SRP)

Single Responsibility Principle, or SRP, means that newly created React components should only have one purpose. A component that was created to display a table should only handle the table.

Let’s say you want to reuse the table component. It would be easy to import it and display it as is, but what if you decide to have the component display a table, handle a form, and display a comment section? Now it’s difficult to reuse the table because the form and comments are dragging along. Keeping components pure reduces unnecessary bloat and will make your life and future developers' lives better.

Independent components

The key to making a good component is independence. It would be really nice to just import a component and render it as is, and call it a day. If your component requires data from outside your component, then consider utilizing context to get the data required. If you have a component that has lots of dependencies or props, then you’ll have to understand what needs to be passed into the component to get it to render.

While this might seem like a straightforward task, it still requires some work. The fun part is when you will need to refactor either the component or the parent that is rendering the component. You have to consider any side effects that could come from this refactor and prevent them. This gets harder when your dependencies grow.

File Naming Convention

You might be surprised, but a lot of developers have problems naming variables, components, functions, etc. I've seen developers name a variable data, a function buttonClickFunction, or a component displayDataComponent.

If you are having trouble naming something, ask yourself, "What is this?", "What does it do?" or "What section of the page is it?" Instead of naming a variable that contains the user's information data, call it userInformation or user. Instead of naming the onClick function on a submit button buttonClickFunction, call it handleSubmit or submitUser.

As a general rule of thumb, functions or components should consist of at least 2-3 words. Put yourself in a new developer's shoes, the name should be easy enough to understand what that thing is.

Dynamic for Scalability

Whenever I create a variable, function, or component, the first thing I ask myself is if this can be used in another location of the application, like Section Headers that can accept children elements to display next to the section title.

One way to set yourself up for dynamic success is by creating independent components. I once had an independent component, but later I found out I need it in a different section of the application under a different context. Sadly I had to create props for this component to have it sharable in different contexts. If props are required, there should be elements that will be different between the locations this component is being rendered. This refactor was quick and easy to perform since we kept it as close as possible to being pure. 

Organize File Tree

One of the most important things about architecture is the file tree structure. It is important to structure your file tree so that new and old devs can navigate through the repo with ease. File structure, in a way, can be its own form of documentation when every file's name and location can denote its intention within the application.

Another principle that applies here is the separation of concerns. Not only could this be applied in the code architecture but also in the file tree architecture. The root of your directory can hold your navigation component, like Home, About, Products, Community, or Downloads, which could be all sibling directories at the same level. As you go into Home, you have components that only render the Home page. Shared components could also stay at the root, and to prevent long relative pathing direction (../../../), you could consider _moduleAliases the shared directory so that you can simplify the pathing.

Conclusion

Implement these tips, tricks, and concepts, to support your teams across a spectrum of applications. These tips will help new team members understand the application so they can start developing quickly after onboarding, which simplifies continued development and scaling by not having to "follow the thread" to understand how the code works.

Architecture is the absolute foundation of good development. With that in mind, we hope you consider applying a few of these concepts to your own work.

Need some help?

Bitovi has a team of expert React Consultants who are ready to dive in and help with anything from web components to suspense. Book your free consultation to get started!