2 April 2021
Rails: Laying the Foundation for the React to HTS Transition
by Bill Barnett
Review
In our last post, we stated our hypothesis and laid out the initial plan to prove (or disprove) it. Plainly put, we hope to validate that, using Hotwire, Turbo and Stimulus (HTS), an existing application with a React frontend and a Rails backend can be refactored into a unified Rails application without degrading the user experience if not improving it. The benefits of a unified codebase are many; from less context switching for developers and designers to more sustainable project management and talent acquisition processes for managers, all of which help keep everyone in the C-Suite happy.
Leveling the Playfield
We started our experiment by updating James Hibbard’s well-written demo Rails/React app to the latest versions of React, Ruby, and Rails to ensure each were taking advantage of their latest enhancements. As a reminder, you can follow along with our progress on GitHub. Code for the upgraded React-based application is accessible on the react-current branch.
Next, we felt that some rudimentary tests should be in place to ensure feature parity between the React and HTS implementations. As this experiment is based on an app that was created for demo purposes, we weren’t concerned that there was no existing test coverage. System specs are a great first step toward improving test coverage for applications with few or no tests. We’re big fans of RSpec. So we added some basic system specs to document the existing functionality.
Taking a Step Back
With the major frameworks updated and system specs in place, it’s time to settle upon a strategy for rearchitecting the app. In the end, we chose a straightforward approach. Namely, we chose to revert the app first to a “conventional” Rails app. In other words, we’ll remove React and replace it with server-side rendered Rails boilerplate models, views, and controllers. This will return the app to a more idiomatic Rails implementation and provide the perfect foundation for the work ahead, just as if we were building the application from scratch. At first, this seemed a daunting task but proved to be rather straightforward in the end. We’re already experimenting with this approach with more complex applications and are eager to hear thoughts on other approaches.
Next Steps
With our app reverted to a conventional state it’s time to start wiring things up with HTS but that will have to wait for our next post. Once our HTS implementation is complete, we’ll devise a test plan, crunch the numbers and share our findings here. We’re a couple of weeks on from our initial post and our excitement about the potential of a unified Ruby codebase has not diminished. We expect this next step to be very enlightening.
Find yourself managing an application with poor test coverage? Is releasing new versions of your software an exercise in patience wrought with anxiety and fear? Are you a developer with a passion for crafting software users love using and managers find easy managing? We should talk.
