React-ing to Hotwire

by David Hill

In the presentation titled "React-ing to Hotwire", David Hill, a staff engineer at Care Rev, recounts his experience migrating a complex stand-alone React application into a Rails app using Hotwire as the new front-end framework. This shift was prompted by the challenges faced while maintaining the original React application, particularly after the departure of key developers who had built it. The talk reflects on the strengths and weaknesses of React while advocating for the advantages of Hotwire.

Key points discussed in the presentation include:

Background on React: Hill shares his positive beginnings with React, highlighting its ease of getting started and capabilities for creating interactive UIs.
Transition Necessity: Hill narrates the internal struggles at his previous job, where he faced a critical React application with diminishing support, leading to a need for a strategic change.
Challenges with React: He describes a frustrating experience with modifying a seemingly simple feature in the React app, which turned out to require extensive changes across multiple files, exacerbated by using additional libraries like Redux and Re-kit.
The Argument for Hotwire: Hill outlines how he successfully persuaded management to transition to Hotwire by demonstrating its simplicity and by working on a small proof-of-concept project using Hotwire that showcased better maintainability.
Benefits of Using Hotwire: The advantages of Hotwire included reduced server costs, easier code management, and improved developer onboarding due to its Rails-like structure.
Using Stimulus with Hotwire: He highlights the ease of creating interactive functionalities with minimal code, exemplified through his implementation of a character count feature using Stimulus.
Successful Outcome: After four months of rebuilding the application with Hotwire, the project launched successfully, leading to ongoing satisfaction among the developers and continued use of the system he built.

The main takeaways from Hill's presentation stress the importance of maintainability in development, the reduction of client-side state management overhead, and how environments that are closely aligned to Rails conventions can lead to better developer experiences and productivity.

00:00:00.900 Hello everyone. I'm David Hill, a speaker at RailsConf.

00:00:13.519 I have a little bit of nervous energy, so please wave at me if I start talking too fast.

00:00:25.680 Today, I'm going to talk about my journey of migrating from React to Hotwire.

00:00:30.060 I currently work as a staff engineer at CareRev. To quote our company description, CareRev is a labor marketplace platform that connects hospitals and health systems with vetted healthcare professionals, helping them have more control over their schedules.

00:00:39.420 We are hiring, so if you're interested, please come see us at our booth in the exhibit hall. As for Hotwire, we're not quite using it yet, but there was a recent pull request from another team that may initiate its use, which is exciting.

00:00:52.920 Now, let's talk about React. As Britney mentioned, this is kind of a storytelling session about our experiences. To talk about this transition away from React, I first need to discuss what I appreciated about it. I don't dislike React. In fact, it allowed me to take a break from Rails by working at a React shop for six months, learning and using it as the primary development language.

00:01:54.720 React can do many things well, and many aspects initially attracted me to it. The main goal of React is to create interactive UIs and design views based on application state, which it achieves effectively.

00:02:03.600 As a developer with little experience in React, I found it easy to get started. You don't have to deal with the complexities of data transport layers or application state when first learning React because the primary goal is to build user interfaces.

00:02:09.899 Using browser extensions for React Developer Tools was a big advantage. I recall finding a simple tic-tac-toe game to explore. In the components panel, I could see the names of the rendered components and easily locate their corresponding files. The straightforward structure where knowing a component's name leads you directly to its file was a pleasant experience.

00:02:18.000 This Rails-like structure of code organization was something I appreciated.

00:02:22.560 At my previous job in 2019, we were a small team supporting three projects, one of which was an internal auditing tool to keep our work orderly. The second was a new healthcare program waiting on other companies to join, and the third project was primarily focused on the company's managed surgery centers. The importance of these projects varied significantly, and unfortunately, within three months, we lost three developers, including both JavaScript developers. This left me to maintain the important React portion of our application.

00:03:05.880 Before discussing transitions, let's dive into how the application was structured. On the Rails side, there was an API feeding data to the React app. There was also an admin site where employees could log in to manage domain data, with limited React sprinkled throughout those pages to add some dynamic functionality.

00:03:35.640 When I started helping support and maintain the application, I thought I was entering a simple React setup created using the create-react-app CLI. However, I quickly realized that any small change necessitated an overwhelming number of adjustments.

00:04:06.180 For instance, I was tasked with adding a new 'Remove Link' item to a dropdown menu that would open a modal to fill out a form for documentation removal. Although this seems simple, it led me down a complicated path where I couldn't locate the expected component structure in the React Developer Tools.

00:04:48.780 What I saw baffled me; it provided no insight into the app's structure. Initially blaming the original developers, I later discovered that the problem seemed embedded in the overall React setup, particularly with create-react-app. I found myself spending a significant amount of time deciphering which components rendered where to implement the change.

00:06:00.840 Working on this transition also required adjustments on the Rails side, as I needed to update the routes and create a new action in the forms controller for removing the documentation. The experience of expectations versus reality in the application's complexity was overwhelming, especially since my original belief was that the application was straightforward.

00:06:54.540 After these revelations, I recognized the necessity to convince my management of the need for a significant overhaul of our system and potentially migrating to Hotwire.

00:08:13.959 I anticipated the conversation's progression and how best to frame my argument. Thankfully, my team lead and our director were already aware of the pain points experienced by previous developers. I found it crucial to start with something small to prove the concept, so I took the React-based pages and rewrote them in Hotwire. This contained project provided proof of concept for our management.

00:09:59.720 Transitioning to Hotwire increased the resemblance to Rails, making applications more maintainable and reducing the learning curve for new developers. Since we were able to eliminate the dual deployment of separate servers for the client and API, this shift also helped reduce server costs.

00:10:46.520 In my experience with Hotwire, I noticed that the sheer amount of JavaScript code required for asynchronous requests and state management in React created a significant development overhead. I found it much simpler to fetch current state from the server as Hotwire allows.

00:11:46.680 Hotwire made it easier to build dynamic systems while requiring less skill for future developers to maintain and enhance the project. React, with its many layers, led to complexity that increased the barrier for new developers.

00:14:10.120 Successfully migrating to Hotwire took about four months. Upon launch, we scheduled regular catch-up meetings to discuss progress. After completing this project, I transitioned to updating another project with Hotwire before pursuing a position at my current company, CareRev.

00:15:50.580 I later reached out to my former director for insights on the current state of the project. He mentioned they are still using the system I built and continued to build upon it.

00:17:09.380 To conclude, I have my Twitter handle, but be aware that I rarely tweet about tech stuff; it's mostly about my family and board games. Thank you for your time.