ReactJS Seed Application: Why Not Start with the Real Deal?
Making the decision to go with ReactJS as the framework for our new UI was just the first of of many steps in our implementation. Step two was deciding how to tackle the project. Since React was new to us, we decided to build a seed application first.
We did this for a few reasons. For one, a seed application allowed us to try out different libraries and project structures without the restriction of a particular use case. As we all know, when you develop something for a specific task (e.g. a dashboard application), you tend to build everything tied to this one use case. Which is all well and good, but as soon as you try to reuse some of the code or extend the application to a different use case, you can run into big problems.
You might be wondering, “why didn’t you just use an existing seed application?” Everyone knows if you google for “React seed application” or “React boilerplate” you will find tons of prebuilt seed applications out there, some of which are being used by thousands of people. After looking at these, we found that though a lot of them offered unique and interesting concepts, none of them seemed very scalable to us for use in large web applications. So we got creative. If you take a close look at our concepts, you’ll see that many are a mix of existing seed applications and our own engineering.
Getting Started: Finding a Module Builder
Browserify was the first technology stack our team worked with at Hyperwallet. We looked at this tool to build the final browser version; we were also looking for tools to replace JSHint and JSCS for code quality. We settled on Gulp as our main build tool, but we’ll get to that later.
In terms of supporting libraries, we decided to use Redux for our data flow. This enabled us to do make some major changes during the seed application development. Our first attempt was splitting off reducers and actions… however, we quickly figured out that it was a lot easier to keep these in one file since one can’t work without the other, after all. This improved the readability of our reducers and actions quite a bit.
A Note on Folder Structure
Last but not least, we changed the directory structure. Looking at the most common React seed applications you will see that they have, for each component, a custom folder and they group them all as components. Again, this works very well for small applications and test projects. But imagine having a full blown web application with signup, login, dashboard, profile, … you get the picture. You’re going to end up with thousands of smaller and bigger components each in their own folder. Keeping track of all the files is going to be very difficult. So we decided to go with a different approach and created modules. Each module can contain multiple React components, one reducer (optional) and multiple services/utils. This makes it easy to identify components that belong together while still allowing cross-component usage. For example, if you have a UserTable component you also will have a UserTableColumn Component. Within the structure we used they belong to the same module and the same user-list module.
Working on a seed application can help you steer the foundation of your project to a goal that works not just for the one use case you have in mind at that moment, but actually provides a foundation that can both scale and extend, as well as be reused for new projects.
But enough with the theory. Next time we’re going to explain our build system (Gulp), why we went with it, and what usual tasks we have.