Gem Detective: A How-to (and How-to-not) on Incorporating Gems at Harled

Finding Gems

I set out to try and find 3 Ruby on Rails gems to incorporate into our application that would better our developer or user experience. To research and find these gems, I primarily used Ruby Weekly archives dating back two months ago. I also asked my fellow Harled developers for their opinions on gems that could be a good fit for our application and monitored for any that were being discussed internally. I also took a look at gems that we were currently working with to see if any newer approaches were available. After finding a large group of gems in all of these areas, things like code freshness and overall project health to remove any stale projects in the onset.

Eliminating Contenders

The next step was to take the list of gems with potential and start working on ruling out contention based on certain characteristics of our application. Many gems made available to developers have very specific expectations about the size of applications where they apply. There are also a certain number of implicit expectations for other services and code constructs that an application using a specific gem will have before implementation is possible. For these reasons, it's important to investigate these concepts early, before the gems are staged for addition into the application. Three of the larger contenders were eliminated at this stage.

Sorbet is a multi-threaded static type checker that operates at the method level inside of a Rails application. It uses its internal tool, Tapioca, to handle dynamic method definitions and code integrated with any other gems before Sorbet was introduced. This gem adds very useful type error checking into the application that can lead to better error readability and it can also allow for higher level method documentation. There is a tradeoff however, because this gem requires that static typing is used throughout your application via method signatures. It would only be worthwhile for larger applications that had a complicated web of payloads being sent to and from the application, which is not the case for our application currently.

PaperTrail allows for the tracking of model version history during stages of development. Conceptually this gem is good for having an added level of accountability for different migrations to the internal database. However, a lower level of this functionality is already provided by the audited gem and as such this gem was not a good fit for our application.

Storybook for Rails and Internationalization

The main contender for entry into our application was the Storybook View Components gem. This Javascript frontend workshop showcases view components in a setting outside of the main application to allow for better testing and visibility. The gem includes the ability to change appearances of components like buttons or toggles in the workshop and even has compatibility with Rails partials. One of the big reasons I wanted to use this gem was due to another gem that dealt with database and application wide translation, Globalize. This gem uses Localize to assign translation tables to models and directly assign columns of data to be translated to supported languages. If these gems could be implemented together, there would be a seamless way for developers to open up an interface where they can see how a view component changes based on screen sizes and with different text fields populated in another language, greatly improving the time it takes to test features being implemented in the application.

Issues arose in the implementation of Storybook as it seemed that there was no database compatibility brought over to the gem from its original typescript code. Its test library implementation in Rails gives a lot of functionality in the form of controls, but in its current state there seems to be no functionality for passing in ActiveRecord data directly into Storybook. The fact that only test data is accepted as inputs invalidates its helpfulness as a workshop and makes it impossible to work in internationalization through Globalize. Globalize itself is outdated and no longer being contributed to, it would have to be replaced as a translation gem.

Learnings and Next Steps

Throughout this process, one of the most important things I've learned is to set up a Rails application properly the first time. It's important to think of replicability and take advantage of initial options that frameworks offer as a way to mitigate errors from different processes that don't work well together (in my case Webpacker and Bootstrap Icons).

I would say that I did some things inefficiently throughout this process as well, primarily the move from research to implementation. I waited too long to get a large enough pool of gems that I could test on my own, when I could have been testing and coming to conclusions on viability while I was continuing my research. I won't be so stingy when it comes to what and when to test next time; there are many opportunities to eliminate very popular gems from contention early on which will leave only the best of the best for our application!

Want to help us explore and evaluate the next great gems to build upon? If so, take a moment to review our open positions!