---
title: "Discussion on \"Rails Components: More Installer Over Library\" | Hashnode"
description: "Discussion on \"Rails Components: More Installer Over Library\". Explore shadcn-ui gem for customizable Rails components, using installer-based approach to avoid dependency bloat and promote unique designs"
url: "https://hashnode.com/posts/rails-components-more-installer-over-library/64ca25fe19ba871aedda8f46"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Rails Components: More Installer Over Library](https://code.avi.nyc/rails-components-more-installer-over-library?utm_source=hashnode&utm_medium=feed)

Explore shadcn-ui gem for customizable Rails components, using installer-based approach to avoid dependency bloat and promote unique designs

Aug 2, 2023 · 6 min read · code.avi.nyc  
Updated Aug 7, 2023  
Read the article

-   [#ruby-on-rails](https://hashnode.com/tag/ruby-on-rails)
-   [#components](https://hashnode.com/tag/components)
-   [#libraries](https://hashnode.com/tag/libraries)
-   [#dependencies](https://hashnode.com/tag/dependencies)
-   [#rails-components](https://hashnode.com/tag/rails-components)

## Written by

[Avi Flombaum](https://hashnode.com/@avinyc)

@avinyc · New York, NY

  
[View profile](https://hashnode.com/@avinyc)

Engineer, educator, and entrepreneur that loves building products.

I'm an engineer, educator, and entrepreneur that has been building digital products for over 20 years with experience in startups, education, technical training, and developer ecosystems. I founded Flatiron School in NYC where I taught thousands of people how to code. Previously, I was the founder of Designer Pages. Currently I'm the Chief Product Officer at Revature.

## Responses 1

Markdown supported · ⌘↵ to post

[Lucian Ghinda](https://hashnode.com/@lucianghinda)

[Aug 2, 2023](https://hashnode.com/posts/rails-components-more-installer-over-library/64ca25fe19ba871aedda8f46/comment/64ca6bb3fc5843b339eb9d20)

Here is my perspective on this:

-   I think it should be an installer and the users should generate the components they need
-   Upgrading means that they can choose to regenerate the same component with option of replace y/n

Why:

-   I am a user of TailwindUI and some other UI components
-   The times I never needed to change a bit something from there is almost zero.
-   With HTML, a small tweak is needed in a project: adding a class, adding an attribute for accessibility ...

Thus a generator is the best option here. I want to generate the components that I need. If I don't need any customization, they will remain under `app/views` somewhere. But if I need to change something I can easily do it.

But if this were a library, it is hard to change just a bit of a component from the HTML perspective, especially if that is partial. It is hard to inherit it and add an extra `aria` attribute.

Someone might say: then let's make the components flexible so that everything that is needed to be added can be added via locals/variables. But that will mean a very complex code.

As an example: authentication-zero. It is a great choice to make authentication a generator because almost every time, something specific needs to be changed with authentication. In case of devise I almost always generate the views and refactor them with a different HTML code.
