It all started with a five minute lightning talk at our Product, Design, and Engineering offsite in January. I did a small demo of Storybook and how it could help bridge the gap between product managers, designers and engineers. My presentation and working demo went well, but there was a catch — my demo featured React components, but our front-end framework was AngularJS 1.6. I demonstrated that we could inject my React component into our AngularJS application with react2angular to provide a way for us to incrementally migrate our front-end. Then, the flood gates opened.
The lightning talk spurred a lot of interest and discussion. We already had a lot of in-house knowledge about AngularJS, and the development team was pretty split between choosing React or Angular 7. We settled on writing two proof of concept (POC) apps, one in React and the other in Angular 7, that would recreate a small section of our admin app. We would then gather the developers who had strong opinions and discuss the challenges around each implementation. We set a two-week deadline on the POCs. The section of the admin app that each POC would recreate required multiple nested routes, calling APIs, form validation, and a paginated list. A lot to do in two weeks!
The React POC came together nicely, but we felt that a lot of flexibility for migrating came from react2angular. Thanks to this library, we could slowly build new components and inject them in the app. We could build full react pages and have the ability to place existing angular 1.x components into these react pages if desired. We also noted that our Angular 7 branch had added or changed a lot more files than our React one.
An example of how we injected our
<ProductManager> component into our Angular controller:
And of course the updated template file:
<ProductManager> component was injected, it became the usual React dev experience (with Routing, Suspense, & Lazy loading!):
This was super clean and easy to reason about. We had no trouble creating components, loading them into Storybook, and testing them with Jest and Enzyme. There were several other factors that helped sway our opinion:
- Developer ramp-up
- Existing React Native mobile app
- Easy testing with Jest and Enzyme
The battle might be over but the war between our new front-end and our old front-end has just begun. We are holding a bunch of small focused meetings around the fundamentals of a great React app. Out of these areas, we bundled the ones that need to come before the others to get developers started as soon as possible. The chart below shows the highest priority areas we’re tackling first from left to right.
Once we have good documentation and examples for these areas, our team can start building! We’ll discuss and add things like Apollo, Redux, Relay, etc as the complexity increases; state management, tooling, and GraphQL are next on the priority list:
One area not listed above, but core to our business, is our design language system. This is being developed in parallel with our design team and will be discussed in part 2 of this series. Stay tuned!
Duane Bester is a Tech Lead for the Engineering Enablement Product Line Team here at RigUp. He focuses on core infrastructure and technology that gives our developers maximum time and ability to focus on their work and deliver great products.
Earlier this year RigUp announced a Series C “… to rapidly expand our products and services in response to a fast-growing customer base,” — CEO and co-founder Xuan Yong. To aid in this effort, RigUp has been hiring a lot of software engineers to aid this effort. The time was coming to transition to a more modern front-end library/framework as it would enable faster ramp-up and development for the team.