6 Tips For Building a Large Scale React App (Plus Bonus Tip)

When first learning React, or any other new Front end or even back end framework for that matter, It is common for developers to build something small just to get a feel for the technology. So after skimming some documentation or some tutorials, you may build something such as a TODO app or a weather app.

These are great for getting a quick feel for what you are working with as well as getting the basic concepts down. However, once you have to build anything of substance you will start to hit some roadblock. If you are able to get past those blocks, it is often the case that you end up with a mess of code that is not very maintainable and/or scaleable.

Having experience developing a large scale React app, I have come up with this short list of tips that will go a long way into helping you write something that is manageable (or at least somewhat manageable.

1. Start with a Boilerplate Project
React is a UI library that can be extended via libraries to create a full application. When doing this, there are plenty of decisions to make as to which libraries to include. Each decision you make at the beginning of a project becomes harder and more expensive to change the deeper you get. It is because of this that I prefer to go with something that is built and tested by more than just my eyes (or even the eyes of those on my team).

There are many of these types of projects:
- React Slingshot
- Create React App
- React Starter Kit

I prefer to use React Boilerplate
There are many things I like about this project. It comes with a sample app that you can build off of or you can just clear it out and start fresh.

The biggest guiding light I found in this project is the folder structure. It seems like such a simple thing, but if you are working with large scale apps, you will quickly notice how this simple folder structure makes developing much easier.

Taking a look at the folder structure, you notice that the components folder is simply there to hold components like Buttons, Input fields, and other HTML components. You then notice that your containers folder holds your actual "pages". Each page/section has its index.js file, actions, reducers, css, and other files that pertain to that page. Also, each section has its own test directory that has the tests for all of the files in that container. The idea is that you can have each container and just simply reuse all the pieces in that component. It basically lives as its own piece of the application dependent on very little, if anything, outside of that folder.

Another key piece is that testing is built right in using Jest and Enzyme. You start with 100% test coverage. This makes it easier to add more tests as you go along and keep your threshold for testing at acceptable levels.

2. Write Tests First (Practice TDD)
Most everyone I talk to thinks and says testing is good. TDD is very important and necessary. The problem is that it takes time (at least initially) to get comfortable with, and practice. One of the issues I had with testing React initially was just configuring our application to use Jest/Enzyme. This proved to be quite challenging and took more time than I expected. Part of that was because at the time I was actually learning what Jest and Enzyme were and the why/how to use them. Part of it was getting it to run in on our project and in our environment. I found out about React Boilerplate soon after I got this configuration working. Had I known about it first, it would have been very simple to either use their project or replicate what they were doing. Either way, I learned quite about about the whole testing process.

A big reason why you should always write tests first is that it will save loads of time. It is nearly impossible to write code first then add tests later. You will find that you spend a lot of time refactoring code anyway and dealing with bugs you didn't notice were there. This happened on the project I worked on. It took more time to write tests than it should have. In fact, a few areas we wanted to add tests to, we couldn't because the code needed a complete refactor. This means that even when adding simple changes, the code was very brittle and it ended up taking longer than expected.

Update: this code has since been dealt with and it fully tested. We need to refactor quite a bit but it is now functioning as it should be.

A few more bits about TDD that are worth reading.
The Outrageous Cost Of Skipping TDD Code Reviews
5 Common Misconceptions About TDD Unit Tests

3. Use a Mess Detection Tool to Monitor Code Complexity (plato)
Plato es-analysis

Plato is a JavaScript source code visualization, static analysis, and complexity tool. What does that mean? It means that it checks your source code and gives it a score to show you how complicated your code is. Not how complicated the application is, but rather, how your code is written.

To simplify this, it basically checks for things like nested conditionals (if else if else else if else etc) and gives an overall score for how complex. The more complicated (number of different paths your code can take), the lower the score. You want to shoot for a higher score, which means your code is less complex.

Less complex code is typically more modular, easily testable, less buggy, easier to maintain overall.

4. Use a Linting Tool
I use ESLint My ESLint Setup

Linting is important when working on a team of developers. It goes a long way in keeping everyone basically on the same page as far as formatting and things like that. It helps make code more readable, and keeps surprises to a minimum. Again, it is easier to deal with this at the onset of a project rather than double back to take the time to set it up once started. At that point it becomes very expensive.

Most boilerplate projects have ESlint built in. React boilerplate does at the beginning.

5.Organize Lifecycle Methods As They Are Called
This is a tip that does not take much time or investment up front, but could go a long way in making your code more readable and easier to follow. When you have a container and you use lifecycle methods, sometimes it is hard to keep track of which ones fire when. One way I deal with this up front is to simply organize them as they are called. This is mostly for readability and being able to logically follow your code, but it provides a lot of value when trying to figure out what is going on down the road.

I typically use this cheat sheet when needing to be reminded about which methods come when.
React Cheat Sheet (Lifecycle Methods)

6.Keep render() functions short and clean This is a good culmination of a few of the points listed above. Namely, testing, keeping code complexity in check, and linting. Render() functions should basically do one thing. Render your HTML/data to the browser. I have seen many projects where the render() function does to much. So this is not really a React tip as much as it is a good development tip.

Keep you render() functions small. For that matter, keep all of your functions small. If you are doing a test first approach, you will notice at the beginning that this is key to writing good tests. This is also key to keeping your code readable and maintainable.

Bonus Tip - Make Sure You Understand Javascript This may seem obvious, but it is very often overlooked. React is just Javascript. In order to be good at React, your must first be good at Javascript. You can fake your way around React for a bit, but eventually you will have to write or debug Javascript and actually know what you are doing.

Besides, while React might be winning the front end battle at the moment (Summer 2017), it is not a guarantee that it will be leading the way 1 - 2 years from now. For that, you need to keep up with Javascript and be comfortable with that first. Then you can move on to whatever framework you like.

Author: James Buczkowski | For more information
Profile: http://jamesbuczkowski.com
Follow me : @_theDevNotebook | Subscribe to RSS feed