A Legacy Rails App’s Journey Into 2022: Part 1 — View Components
Part one of a series of blog articles that covers upgrading a Rails 5 web app, which suffered from a deprecated front-end and outdated libraries, into a cutting edge Ruby on Rails monolith using modern JS, HTML5 and CSS3, including Stimulus JS, View Components, TailwindCSS and Stimulus Reflex.
There’s some reverence, shock, and maybe a little heartbreak, to be felt when you see the following code in an web app:
As you know, the <font> tag was deprecated in HTML 5 and the <center> tag in HTML 4. This is a simple example of the type of markup that littered a relatively older — and the sole legacy — web app inside eXp-Realty’s Innovation Hub team. Code like this inspired me to come to the reluctant, and often publicly scorned, decision to rewrite the entire front-end. To accomplish this, I knew encapsulated components would be essential for rewriting the UI and one gem in particular; View Components.
The advantages that View Components would bestow the app were obvious to me. It would allow the creation of a UI Design Library to be used inside this rewrite, but also to be expanded into our growing, evergreen catalog of team projects; it would quickly organize the views and clean out dusty partials dirty with ERB logic; it would mix well with Stimulus Reflex’s morphs (nothing is prettier than a View Component inside of a Reflex method); accommodate reusing sections of the app and common templating patterns; automated tests and previews could be added to essential components; and the file structure would end up drastically cleaned up.
Instead of covering all the places I incorporated View Components, which would be impossible because they’re practically everywhere, focusing on one area that benefited from them would make the most sense: the Rails Flash system.
Toastr-rails was the gem handling our flash messages, and it also depended on jQuery. Since jQuery was another victim of my broad refactor guillotine, I had to replace this with a new method of tapping into Rails flash system. Below is how it looked inside the application.html.erb view.
Not only does inline JS look ugly and make our views harder to read, Toastr here is an added dependency that isn’t needed, with all the extra code that comes along. The View Component gem could help out here by componentizing flash, with sidecar assets, and then be used in our future apps as a component in our UI Library. Replacing the above script is a single line call now for our flash system.
The component directory is structured like so, with all relevant Stimulus JS and SASS tucked inside the same folder as the View Component’s Ruby file and template.
Everything inside here is relatively straightforward. The flash is rendered only if it’s present, the flash object is passed to the component to be iterated on in the template and displayed, as well as accompanying icons depending on the flash type.
The last part is to inject Stimulus JS into it so that it behaves much like the Toastr that was replaced. This includes timed dismisses — I go with a flat 5 seconds to keep things simple — and blur dismisses when the user clicks off the flash element.
Consequently, calling flash from any Rails controller will render this component.
And even cooler yet, it was pretty simple to add a reflex method inside the ApplicationReflex parent class that will render the View Component from any other reflex desired.
It’s as easy as calling render_flash then inside some inheriting class’s method.
This is a small example of the immense power and adaptability View Components can imbue an web application with. I could bloat this blog article to thousands and thousands of words discussing the many benefits of View Components; especially how much they aided in the rewriting of this particular web app. However, all I truly want to say is try them if you haven’t yet.
Thank you for reading and I hope that you will catch Part 2 coming soon enough.
