We are excited to open-source something we have been working on for the past six months: the Weeds boilerplate. Weeds is a universal, React/Redux project base that we are using for our new apps. You can find it here!
The primary motivation in building a new project base was to invest in our user and developer experience. We have used React and Flux before, but it was time to adopt more of the tools that are common in modern React apps. Server-rendering was a major investment to improve our app-rendering speeds, which is a real challenge in our other client-rendered apps.
It will continue to evolve as we learn, but we feel there is plenty of value in it to share. We will be writing a few blog posts highlighting patterns and lessons we have learned—check back soon.
Why we built our own
There are many similar boilerplates floating around the web. While they were very helpful in putting together our own application base, there was never a point where we could copy any chunk of code. A few reasons:
- We needed a custom authentication flow. Our legacy app already deals with authentication through secure HTTPS cookies. While this may not be the sexiest, we needed to forward that cookie through the client server to get user information. This involved a bit more than just react-router matching, which was what most boilerplates offered.
- We wanted to hand-pick our tools. We wanted our styles and babel plugins to match our other apps. This app needed to be as maintainable as possible too—we didn’t want “one-off” tools that seemed too tied to other dependencies.
- Integrating with a real development environment makes tool configuration even more complicated. For example, you probably want HTTPS in development to mirror your production environments, but getting the tools (that you don’t know well) to work is a headache. Learning how to setup and configure these tools (one at a time) is helps with debugging and maintaining your app long-term.
- We needed more robust data fetching. We needed a simple way to fetch and update data with robust error handling. Most API examples were too fragile.
This is really application development; we never expected a boilerplate to have everything for our specific needs.
Why you should build your own too
What we’ve built is likely too custom for your use. The tools may not fit your needs (or are already out-of-fashion). The code may not match the code style or babel configuration that your team chooses. Your authentication scheme is likely different from the external login method we use here.
Why are you releasing then?
We still think the boilerplate can offer some guidance on what you many need to implement in your own applications. We also want to share (through future blog posts) some nice patterns and suggestions on setting up your project for a better developer experience. Some API code may be extracted into a module in future as well!
Again, boilerplates are useful when you have the knowledge on how to use the major tools and can compare both tools and techniques. They are terrible learning tools. If you are confused, I highly recommend going through the Recommended Reading section before diving in the code.
Would you do it again?
We feel that this framework provides us with a ready codebase to quickly churn out new features. The investment in a solid application base has been a benefit as we rewrite parts of our legacy client to it. Learning your tools in depth is critical to providing your users and development team with the best possible experience.
Please check back for future blog posts on the framework, and feel free to contribute ideas and fixes on Github!