Transitioning to React & Redux: Learnings from our First Engineering Experiment

By July 20, 2016 July 21st, 2016 clypd Blog, Engineering, Technology

What do you do when your parents pull you out of school to go to Disney World but you have a project due the next day?

For the past year at clypd, the UI engineering team has been moving our JavaScript code to React and Flux. The team was very excited about the transition because it meant better organization of our code and the ability to write unit tests.

Our stack before Redux

Our stack before Redux

However, there were a few issues:

  • Jest, our testing framework, was causing us problems.
  • Flux was better than what we had, but still not as good as we wanted.
  • The whole transition was moving very slowly.
  • We still used Rails.

To address these issues, four people were pulled away from their regular work to form a small team to experiment with moving our front-end code from Rails, React, and Flux to React and Redux, with the goal of eliminating Rails completely.

Here are the things we learned along the way:

A small, well-balanced team was key to the project’s success.

With only four people, as opposed to our usual team size of eight to ten, everyone was on the same page. We were all working on the same project, but our skills were complementary, so we could tackle any kind of work, be it devops, front-end, or back-end work. This also meant that we could each focus on a different aspect of the project and not step on each other’s toes.

Less process meant more freedom.

For this four-week project, we threw out our usual rigorous process. We still had stand-up and code reviews, but we skipped getting approval from product for our tickets. Our team was small enough to plan our sprint during a single planning meeting rather than spending hours discussing priorities before actually scheduling work.

We were also free to iterate on a single feature without going through the full review process each time. This meant we could spend more time experimenting to get the necessary results.

However, the lack of process caused issues when we didn’t timebox iterations. Sometimes we ended up with massive chunks of code to review. In the future, we’d likely mitigate the size of reviews by having iterative pull requests.

Having deadlines gave us focus.

For this project, we had a very clear timeframe: four weeks. We created a document outlining our goals, process (or lack thereof), and individual responsibilities.

Given the tight deadline and well-defined goals, we were able to generally stay on track and achieve the results we wanted.

However, we did lose some time to distractions. We spent a couple of days on a UX re-design of a page we were working on. With such a short time frame we couldn’t afford to spend time on UX, so we cut the re-design short and didn’t make most of the proposed UX changes.

In the future, we might improve on this in two ways:

  • Make sure that we only work on tasks that bring us closer to our goals.
  • Reassess our goals at the halfway point to make sure we are able to still meet them.

Training our own team had many benefits.

After the mission, we prepared training slides and exercises for the rest of the front-end engineers. After a full day of training, the UI team acquired practical knowledge about Redux and React, their utilization at clypd, and our plan to transition our codebase.

The coding exercise was the most successful part of the training. Building blocks were provided for a small app and each person wrote Redux code to complete it. We worked one-on-one with anyone who had questions or needed help. Within thirty minutes, everyone on the UI team had built their first Redux app!

Conducting our own training had a lot of benefits:

  • Custom-tailored to our team and code base.
  • Cheaper than hiring outside teachers.
  • The “teachers” are still available to teach and guide the codebase transition.

Documentation is hard.


Out-of-date documentation

We didn’t document our work until we created the training materials, so it was a lot of work to write it down. Even then we didn’t document everything.

On one hand, not having documentation for everything makes it harder for engineers new to the codebase to ramp up. Incomplete information slows down development or lead to mistakes.

On the other hand, the codebase is still changing. If we spend time documenting parts of the codebase that are still in  , then it quickly becomes stale. Out-of-date documentation is misleading and can cause more issues than none at all.

A longer transition period into the project could have been beneficial.

We were able to start really quickly, but in retrospect, we could have used more time to finish up other work. It would’ve been helpful to have some time beforehand for environment setup and additional research. Then, we could have spent the entire four weeks working on our prototype, instead of just the two weeks after setup.

Luckily, we didn’t have any time critical, company-wide projects happening at the same time, which meant all four of us remained undistracted throughout the project.

The results: success!

At the end, all of our hard work paid off with a demo of a new tool built in our new stack.

A whole new stack

A whole new stack

We are now working on converting our entire front-end stack. This will be a long process, but it will have many benefits that make it worthwhile not only to the engineering team, but to the company as a whole. Here are just a few:

  • Our JavaScript will have a well-defined structure, making it faster and easier for engineers to find and change code.
  • Redux and React allow us to create small, reusable components which can be assembled in different ways. This means less, but more flexible code.
  • These small, reusable components allow us to quickly restructure the layout of a page.

All of this will allow engineers to develop new features more quickly than before. And, developing in Redux is fun!

Ready to go to Disney World?

Leave a Reply