Building an Enterprise React Application, Part 2
In the first part of this article, we talked a lot about architecture. This time around we’ll be looking at the build tools, processes and front-end code organization on the project. Many of the tools we used are popular and well-tested and I can recommend using any of them without hesitation.
Build Tools and Processes
Let’s look at a few of the key tools that the front-end team used on the project:
Let’s talk about these one by one…
On this project we used npm to manage dependencies. Since then, however, Facebook has published yarn, which is probably the better choice if you’re starting a project today. Whether you use yarn or npm, the actual modules will still come from the npm registry.
Another thing I’d like to mention is our use of npm scripts instead of task runners like Grunt and Gulp. You can use npm scripts to do things like watch files for changes, run tests, transpile your code, add pre and post-commit hooks, and much more. You may find task runners to be redundant in most cases.
Browserify does much the same thing as webpack. Both tools process files. They aren’t task runners like Gulp or Grunt, which, as I mentioned, were unnecessary for us. Webpack has built-in hot swapping of modules, which is very helpful with development and is one reason why it’s widely preferred over Browserify for React projects.
I alluded to stylelint above when I discussed PostCSS. It’s a linter for your CSS. As with ESLint, it provides great value in maintaining a consistent, readable codebase.
Build Tools and Processes Summary
Another thing to note, we’ve discarded tools that we could do without. PostCSS can do the job performed by Sass, so we went with PostCSS since we’re already using it for vendor prefixes. Npm scripts can do the job of Gulp and Grunt, so we used npm scripts since they are available by default. Front-end build processes are complex enough. When we can simplify, it’s a good idea to do so.
File Structure and Separation of Concerns
JS/ app.js Views/ Header.js CSS/ global.css Header/ Header.css
With the structure above things are being grouped by technology and then are further categorized by the part of the application in question. But isn’t the actual focus of concern something else entirely? In our example above, what if we structured things more like this?
app/ App.js Header/ Header.js Header.css
When we first started using this file structure on the project, I was uncertain how well it would work. I was used to separating my files by technology and it seemed like the right way to do it. In short order, however, I saw how grouping by component created a more intuitive file structure that made it easier to track down what was going on.
Taking this line of thinking to its logical conclusion, why not just include all the code for a component in one file? I think this is a really interesting idea, but I haven’t had the opportunity to do it in a real project yet and we certainly didn’t do it on this project.
However, if you’re interested, there are some good solutions that I think are worth consideration, including styled components and Aphrodite. I realize that this suggestion is a bit controversial and many of you reading this will be put off it, but after working on React projects for the last couple of years, it has started to make a lot of sense to me.
I find it remarkable how much time is spent on the two topics we’ve addressed here. Front-end build processes can be complex. Some tools, such as webpack, can be difficult to get your head around at first and it can feel overwhelming when you’re getting started.
There are a few React starter projects I’d like to suggest that may help. The first one is from Facebook, called Create React App. It can help you get started very quickly, but there are some limits. Create React App doesn’t try to be all things to all people. It doesn’t include server rendering, for example, although you can add it yourself if needed.
We’ve created our own React boilerplate that supports server rendering, so feel free to look it over and take away what’s useful. Of course, there are many other React boilerplate projects out there—too many to mention—but I encourage you to look a few of them over if your team is planning a React project. Reviewing how other teams have approached the same problems will help you decide what’s going to be the best choice for your team.