8 ms·

Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?

sudhirj 5y ago
I've been using view_components for a while, and there's no going back for me. Much easier to organise views and keep them modular and easy to change and reuse. Only thing I haven't figured out yet is refactoring, how to organise a large number of views into folders / modules without having to move tons of files manually or script it. Tailwind is pretty useful as well, but definitely needs a component system like this, or an application of the Atomic Design principles to not have to repeat your styles hundreds of times all over the place.
- finniananderson 5y ago
  Are you using the sidecar setup?
  - sudhirj 5y ago
    Nope. Does the sidecar create a folder for each component?
    - finniananderson 5y ago
      Yep. It's "experimental" but stable. It creates the .rb file at the root and then you can put the template, CSS & JS in a subfolder. `bin/rails g component Button --sidecar`
petepete 5y ago
I've used view component heavily over the last year or so, it's an amazing library. It perfectly fits the gap between helpers and partials and really does help keep things well organised. I maintain a library of components and being able to spin up a new project and hit the ground running makes for a great experience. I'm looking at documenting with lookbook instead of storybook, but both look decent. https://github.com/allmarkedup/lookbook https://github.com/allmarkedup/lookbook
- finniananderson 5y ago
  Lookbook _looks_ interesting. We use some React in some places of our app which is why I went with Storybook for now, as I figured we could render both types of components (Rails & React) in the same library, which I thought could be neat. How does Lookbook stack up against Storybook? Always keen to stay in the Ruby ecosystem if possible :-)
  - petepete 5y ago
    I only tested it out a couple of days ago, I'm no expert. So far it's been plain sailing, I'm already familiar with Yard-style docs and getting everything up and running from the spec/dummy app was really straightforward. The library I maintain currently uses a home-rolled docs page (https://dfe-digital.github.io/govuk-components/ https://dfe-digital.github.io/govuk-components/) that needs to be refreshed manually. It's been an 'ok' approach until now but as it's matured we need something that's automated and easier to maintain.
    - finniananderson 5y ago
      Wow that's awesome, I knew GDS had a design system but didn't realise there was a Ruby implementation. Quick link for others: https://github.com/DFE-Digital/govuk-components https://github.com/DFE-Digital/govuk-components I'm going to take a look through the repo as I'm sure there's some patterns you've found given you're at a much bigger scale. Any hot tips?
      - petepete 5y ago
        This isn't _large scale_ yet, we only have about 15 services using this library. I'm hoping that now we've stabilised and are spending time on making things structurally better (removing tech debt, improving the tests, rewriting the docs) that will rise. My tip would be to not worry too much about covering every last detail or feature immediately, aim to do what most people need most of the time and release early - then if there's demand for extra stuff add it as you go.
Lapsa 5y ago
Probably not. Pretty sure God codes in LISP.
- sumnole 5y ago
  I mean, ostensibly yes. He hacked most of it together in Perl.
joelbluminator 5y ago
Will this get the nod from dhh and make it into Rails? Dhh wdyt?
- finniananderson 5y ago
  I'm sure I read somewhere (either on viewcomponent.org or on their GitHub) that their end goal is to merge upstream into Rails core.
  - joelbluminator 5y ago
    They merged the ability to hijack the renderer already in Rails 6 I think, which this gem uses. But if they wanted to merge this one into Rails , Rails 7 would have been a good timing. So I'm not really sure this will go into Rails actually.
    - finniananderson 5y ago
      Yeah that is a good point. Rails 7 is going with importmaps by default too, further moving away from the JS ecosystem (unless you want it) which would've paired nicely with merging VC.
  - jrochkind1 5y ago
    I think Rails decided they didn't want it, but API so that ViewComponent can be used without patching Rails is already there in Rails 6.1.
- ksec 5y ago
  DHH said no to View Component, previously called ActionView::Component. I think there was another Rails Core that didn't like it much due to its additional complexity or something. But that was in 2019?. May be things have changed.
  - strzibny 5y ago
    I think they just said no _at the time_. However, unless DHH adops it, I don't think it will be Rails default.
sgt 5y ago
Equivalent for Django?
- danjac 5y ago
  Maybe django-components, if you need something a bit higher level than plain include or inclusion tags: https://github.com/EmilStenstrom/django-components/ https://github.com/EmilStenstrom/django-components/
  - sgt 5y ago
    Is it worth adopting? I hesitate adding more dependencies to projects unless it provides a LOT of value.
    - midrus 5y ago
      In my opinion, it is! Imagine you have a dropdown, or a list of items, etc which is composed of more than one single markup element, such as a couple divs, an ul and a li for each element. Wrapping all of this into a component helps reusing this parameterized component in as many places as you need. You might think why not just use "includes"? Well, includes are great for very simple use cases, but for example, you cannot pass a "body" of html to them (imagine you want a "ListWrapper" component, etc) among other shortcomings. Thinking in components makes things a lot easier in my opinion.
  - midrus 5y ago
    I've tried this and, honestly, I don't like it. Reason number one is how verbose it becomes on the templates when you have to pass a "body", it's at least 4 tags... when you have many nested tags it becomes messy. And then the worst offender to me is that it doesn't isolate the context from the parent template (you have to add the 'only' keyword like with includes), etc. I mean, it was my first option until I found Slippers which for my taste, makes the right trade offs and design decisions.
    - danjac 5y ago
midrus 5y ago
I've recently discovered Slippers [1] which provides something very similar but for Django Templates. I've tried it in a side project and it is amazing. I'm pairing it with Unpoly [2] and Tailwind and honestly, I wouldn't try to build and SPA ever again unless I need full offline support. [1] https://mitchel.me/slippers/ https://mitchel.me/slippers/ [2] https://unpoly.com https://unpoly.com
- meitros 5y ago
  I built something very similar with straight flask templates paired with bootstrap 5 and htmx (very similar to unpoly.) I think it’s an especially great way to build an internal tools framework, since you get the approachability of python and components make it easier for non-frontend folks to build UIs.
  - midrus 5y ago
    I'm actually a frontend dev full time at my day job, and still think this approach is better for 90% of the things we do with react. The big drawback is that it requires using python and knowing more about backend and most frontend devs are too purists to get their hands dirty this way. So, at work still doing CRUD forms with React, rxjs, redux, websockets, graphql and multiple home made validation libraries. Such a waste of energy and time.

I've been using view_components for a while, and there's no going back for me. Much easier to organise views and keep them modular and easy to change and reuse. Only thing I haven't figured out yet is refactoring, how to organise a large number of views into folders / modules without having to move tons of files manually or script it. Tailwind is pretty useful as well, but definitely needs a component system like this, or an application of the Atomic Design principles to not have to repeat your styles hundreds of times all over the place.

finniananderson 5y ago
Are you using the sidecar setup?
- sudhirj 5y ago
  Nope. Does the sidecar create a folder for each component?
  - finniananderson 5y ago
    Yep. It's "experimental" but stable. It creates the .rb file at the root and then you can put the template, CSS & JS in a subfolder. `bin/rails g component Button --sidecar`

petepete 5y ago

I've used view component heavily over the last year or so, it's an amazing library. It perfectly fits the gap between helpers and partials and really does help keep things well organised. I maintain a library of components and being able to spin up a new project and hit the ground running makes for a great experience. I'm looking at documenting with lookbook instead of storybook, but both look decent. https://github.com/allmarkedup/lookbook https://github.com/allmarkedup/lookbook

finniananderson 5y ago
Lookbook _looks_ interesting. We use some React in some places of our app which is why I went with Storybook for now, as I figured we could render both types of components (Rails & React) in the same library, which I thought could be neat. How does Lookbook stack up against Storybook? Always keen to stay in the Ruby ecosystem if possible :-)
- petepete 5y ago
  I only tested it out a couple of days ago, I'm no expert. So far it's been plain sailing, I'm already familiar with Yard-style docs and getting everything up and running from the spec/dummy app was really straightforward. The library I maintain currently uses a home-rolled docs page (https://dfe-digital.github.io/govuk-components/ https://dfe-digital.github.io/govuk-components/) that needs to be refreshed manually. It's been an 'ok' approach until now but as it's matured we need something that's automated and easier to maintain.
  - finniananderson 5y ago
    Wow that's awesome, I knew GDS had a design system but didn't realise there was a Ruby implementation. Quick link for others: https://github.com/DFE-Digital/govuk-components https://github.com/DFE-Digital/govuk-components I'm going to take a look through the repo as I'm sure there's some patterns you've found given you're at a much bigger scale. Any hot tips?
    - petepete 5y ago
      This isn't _large scale_ yet, we only have about 15 services using this library. I'm hoping that now we've stabilised and are spending time on making things structurally better (removing tech debt, improving the tests, rewriting the docs) that will rise. My tip would be to not worry too much about covering every last detail or feature immediately, aim to do what most people need most of the time and release early - then if there's demand for extra stuff add it as you go.

Lapsa 5y ago

Probably not. Pretty sure God codes in LISP.

sumnole 5y ago
I mean, ostensibly yes. He hacked most of it together in Perl.

joelbluminator 5y ago

Will this get the nod from dhh and make it into Rails? Dhh wdyt?

finniananderson 5y ago
I'm sure I read somewhere (either on viewcomponent.org or on their GitHub) that their end goal is to merge upstream into Rails core.
- joelbluminator 5y ago
  They merged the ability to hijack the renderer already in Rails 6 I think, which this gem uses. But if they wanted to merge this one into Rails , Rails 7 would have been a good timing. So I'm not really sure this will go into Rails actually.
  - finniananderson 5y ago
    Yeah that is a good point. Rails 7 is going with importmaps by default too, further moving away from the JS ecosystem (unless you want it) which would've paired nicely with merging VC.
- jrochkind1 5y ago
  I think Rails decided they didn't want it, but API so that ViewComponent can be used without patching Rails is already there in Rails 6.1.
ksec 5y ago
DHH said no to View Component, previously called ActionView::Component. I think there was another Rails Core that didn't like it much due to its additional complexity or something. But that was in 2019?. May be things have changed.
- strzibny 5y ago
  I think they just said no _at the time_. However, unless DHH adops it, I don't think it will be Rails default.

sgt 5y ago

Equivalent for Django?

danjac 5y ago
Maybe django-components, if you need something a bit higher level than plain include or inclusion tags: https://github.com/EmilStenstrom/django-components/ https://github.com/EmilStenstrom/django-components/
- sgt 5y ago
  Is it worth adopting? I hesitate adding more dependencies to projects unless it provides a LOT of value.
  - midrus 5y ago
    In my opinion, it is! Imagine you have a dropdown, or a list of items, etc which is composed of more than one single markup element, such as a couple divs, an ul and a li for each element. Wrapping all of this into a component helps reusing this parameterized component in as many places as you need. You might think why not just use "includes"? Well, includes are great for very simple use cases, but for example, you cannot pass a "body" of html to them (imagine you want a "ListWrapper" component, etc) among other shortcomings. Thinking in components makes things a lot easier in my opinion.
- midrus 5y ago
  I've tried this and, honestly, I don't like it. Reason number one is how verbose it becomes on the templates when you have to pass a "body", it's at least 4 tags... when you have many nested tags it becomes messy. And then the worst offender to me is that it doesn't isolate the context from the parent template (you have to add the 'only' keyword like with includes), etc. I mean, it was my first option until I found Slippers which for my taste, makes the right trade offs and design decisions.
  - danjac 5y ago

midrus 5y ago

I've recently discovered Slippers [1] which provides something very similar but for Django Templates. I've tried it in a side project and it is amazing. I'm pairing it with Unpoly [2] and Tailwind and honestly, I wouldn't try to build and SPA ever again unless I need full offline support. [1] https://mitchel.me/slippers/ https://mitchel.me/slippers/ [2] https://unpoly.com https://unpoly.com

meitros 5y ago
I built something very similar with straight flask templates paired with bootstrap 5 and htmx (very similar to unpoly.) I think it’s an especially great way to build an internal tools framework, since you get the approachability of python and components make it easier for non-frontend folks to build UIs.
- midrus 5y ago
  I'm actually a frontend dev full time at my day job, and still think this approach is better for 90% of the things we do with react. The big drawback is that it requires using python and knowing more about backend and most frontend devs are too purists to get their hands dirty this way. So, at work still doing CRUD forms with React, rxjs, redux, websockets, graphql and multiple home made validation libraries. Such a waste of energy and time.