Lately, especially in the rails community, we've been witnessing lots of new stuff like the hotwire, and the new encryption system.
If you notice carefully, all of these have been extracted from pre-existing applications.
So you might be wondering, what's the deal with extractions? Why can't I just start writing the gem?
The most obvious answer that I can give you is that it is difficult to visualize the usage of the gem itself. For example, say you're building an authorization library gem. You would probably need some method
that would run before the controller
actions and pass in some attributes
like the current_user
, role
, action
name, etc to the policy
. Also, should the policies be scoped to the model
? But if you do that, how would you deal with policies that do not have a model
?
In order to answer all of these questions, it would be much easier to first implement the functionality into your existing rails application and then extract it if you wish to do so.
The story behind
Recently, I was working on a project that had the traditional dashboard design; plenty of SVG
icons, user avatar, unnecessary graphs, and charts, etc. The Figma wireframes used icons from heroicons, and naturally, the first thought that came to my mind was to look for a gem that provided a views
helper method for rendering out the icons.
I found a couple of gems that did this, and I quickly installed one of them and started using it. After some time, I realized the gem that I installed wasn't extensible. I wasn't able to pass other HTML
attributes other than the ones supported by the gem. So the only thought that came into my mind was to create a helper method that would take in any HTML
attribute like the styles
, class
, aria
, data
, etc.
The first thing that I did was to look for other ruby
gems that did something like this. I came across octicons by GitHub and liked how they implemented the gem.
Step 1 - Figuring out the syntax of the helper method
<%= heroicon "user", class: "custom-class", aria: { label: "user icon" } %>
The first argument is the icon name, and the rest of the options are HTML
attributes. Rails already provides a neat helper method called the content_tag
, so it was a no-brainer for me to utilize it.
Step 2 - Setting up the defaults
Each icon library has some defaults, like stroke-width
, viewBox
, etc. In the case of heroicon, they had two variants, namely: outline and solid. So I came up with the following syntax:
<%= heroicon "user", variant: "solid" %>
or, just
<%= heroicon "user" %>
for rendering the outline
version of the icon.
Step 3 - Implementing the logic
After you come with a syntax that you like, the next step would be to test out the helper method and write the logic for it. You're pretty much done now.
Step 4 - Bundling into a gem
What's on this step? Initialize the gem repo, copy and paste all the logic and the tests, write your gem's description, and publish it to the world.
Self-promotion
This is the gem (rails_heroicon) that I implemented following this process. Be sure to stargaze it and use it in your next project if you feel the need to use SVG
icons.
I was so satisfied with this process that I created another gem for feathericons. The gem is called rails_feather.
Conclusion
I agree that there isn't one way of doing the right thing. Especially in software engineering, it's all about trial and error. I found this process quite productive and useful and thought I would share it with you all.
I hope you find it useful.
Top comments (2)
Hey,
Congratulations on your new gem!
I will certainly use it in my next project :)
Thanks. I hope you find it useful :)