How we switched to React for front-end development at Octoblu
Initially when we started building the web application for our Internet of Things Platform Octoblu, we built the application using Angular JS. Angular as a web framework seemed very opinionated but ultimately fit our needs as we were able to build an application that allowed users to connect things and design automation workflows https://app.octoblu.com
We decided that the original application was becoming a monolith and it was becoming harder to maintain and test the original application. We wanted to build micro sites that would focus on one core feature of our IoT platform. Our lead UX engineer, Olu was campaigning hard for us to try using React. Our core philosophy as a team is to use the best tools for the job so other team members were persuaded to give it a try and so all new front-end development was built using React.
Initial Impressions — Boiling in Boilerplate
Our team values iteration speed, we release early and often and our initial development efforts with React were met with mixed results. Developers were frustrated with the amount of boilerplate code they would have to write when building components.
In order to speed up our iteration speed, we started developing yeoman generators to generate a react web application skeleton and common react components that we could share when building applications. We called them zooids
Generating the Zooids
The idea behind zooids is that we wanted a common set of components that developers could easily re-use when building web applications. The initial investment writing zooids paid off and we were able to speed up our iteration speed when developing front-end web apps. Octoblu engineers could generate a template for a new project in minutes and easily generate new components.
We also added generators that would allow you to generate stateful or stateless React components using yeoman.
Managing State — Enter Redux
When building web applications we quickly found that we were building too much business logic in our containers for managing state. We were evaluating ways to simplify our containers while also encapsulating state management so we could easily test our code. We evaluated using Flux but found we were also writing a lot of boilerplate in order to use it with our existing code. We decided to use Redux instead.
Adopting Redux was not without its challenges. The advantages it gave us was that it allowed us to treat our web applications like a giant state machine. We could track each action in an application and see whether our new state matched our expected results. One of the problems we faced with Redux was that we found ourselves spending a lot of time creating boilerplate code for creating actions initially. We found a library called redux-act that easily allowed us to generate actions and this allowed us to make our redux actions and reducers have a smaller footprint.
One particular problem that we faced was deciding when to use Redux. When we initially started developing certain web applications, Redux felt like overkill. It was only when the application grew in scope and complexity did we feel the need to try and retrofit Redux into it. This ended up causing a lot of frustration as we would try to convert an existing web application to use Redux.
We ended up settling on building generators for our apps that would give us the option to use Redux from the very beginning but not force developers to use it if they didn’t need it.
TDD with Mocha, Chai and Enzyme
Enzyme is a test framework that makes it easy for you to test your react components. You can use it with Mocha and Chai to write unit tests for React Components. The API is well documented with examples.
We wanted to way to write tests for our front-end code just like we test our micro-services.
Telling the component stories with Storybook
Once an Octoblu engineer started building new react components that a different engineer would use, they would frequently have to discuss how the component would be used if it wasn’t readily apparent by reading the code. We needed a way to be able to easily communicate how a component could be used and what options could be set in its properties with an engineer with no prior experience.
We found Kadira’s Storybook to be a great tool for communicating how a component works. You can easily write a storybook for a component and a developer could easily load the component in storybook and see all the common states and properties that could be set on a component. We added storybook to our zooid generator so developers could write stories and use storybook to document a component’s use.
Bundling with webpack
We also decided to use webpack as our build tool so we could bundle our web applications. Initially we had mixed results. Webpack has a very steep learning curve and we found ourselves getting frustrated when trying to do seemingly simple things like skipping CSS loading for certain module dependencies and including different versions of config files for different environments. Eventually we came up with a standard webpack format for our web apps and added the template to our Zooid yeoman generator
Conclusion
So far our switch to React for our front-end development has been overwhelmingly positive. Tooling around React is maturing as more and more developers use it. We have maintained and in many ways accelerated the pace at which we develop front-end code at Octoblu. Feel free to send us feedback from this article or let us know if you have any questions.
