Hotovo’s React web-app boilerplate
When a new project is started, the entire development environment has to be prepared. This is never a developer's favorite part, as it’s all the annoying tasks such as dependency updates and config migrations. So, what if we made that as simple as one click?
“You’re just reinventing the wheel. There’s already the create react app package.”
…one could say. And would be right. However, there are reasons why we think that’s not the best possible solution.
Why not use a ready-made solution?
- There’s no need for an army knife with its many and varied options, as we know our specific needs
- The tech stack might lack our preferred tool
- There are too many dependencies, and slow installation
- It makes for slower builds and bigger bundles
- You’ll need to change the linter
- It’s difficult to change the configuration and tailor to your exact needs
What are the pros of having your own boilerplate?
The major benefit to having our own boilerplate is the fact that the stack is tailored to our specific needs, and all our developers have experience with the libraries it contains.
They can switch to a new project and will be working with the same environment they’re already used to.
The maintenance of the boilerplate is also managed by our own team, so it stays fresh and up to date with the recent development of the frameworks and libraries. When a new library is agreed on, the boilerplate simply gets updated by the team.
Configuration of the tools also remains exposed to the project team, so it can easily be modified at any time, and tailored to the use case.
Our boilerplate configuration is also respecting the IDEs used by the team, and already contains basic configuration for them.
What does our stack look like?
We love Typescript, and it’s the default option for every new project. It not only prevents many bugs thanks to well-typed code and static analysis, but well-typed code also helps when onboarding new members to a project, and when consuming the 3rd party libraries.
The React Router library is our preferred routing library as it’s easy to use, well documented and has a big community.
For the state management, where required, we prefer the React Redux library with Redux Thunks for asynchronous actions. Since the introduction of hooks, a lot of boilerplate code was removed and it’s super simple for devs to understand the data flow and debug with the Redux developer tools available. Of course if it’s not required, state management can be opted out, and you can use simple React Context instead.
Data fetching we handle using the Axios library when more fine-grained control is required than is available with pure fetch, or if we simply need to be backward-compatible with older browsers.
For styling we use SCSS files which are coupled with components and global styles.
And finally, when required, we use Google's Workbox plugin to generate service-worker cache with the application resources.
What about tests?
Don’t worry, we didn’t forget them! Both unit testing and end-to-end tests are already present in the boilerplate, with ready-to-be-used configurations.
Unit testing is covered by the Jest testing framework, which provides fast execution and out-of-the-box report generation, and the React Testing Library for creating maintainable components tests which focus on the rendered component surface instead of implementation details. Both tools play nicely together.
For end-to-end testing we rely on the Cypress framework, but plan to migrate to Playwright as it brings in the Safari browser, wider support for test scenarios such as 3rd-party pop ups, iframes and multiple tabs running in parallel. If you are interested in knowing more about the reasons for this move and comparisons between the two, stay tuned for one of our next blogs.
If you like the sound of our stack and would like to use it, or give us a hand maintaining it, please don’t hesitate to join us!