4 ms·

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

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.
      - jnathsf 5y ago
        This is amazing! I’d love to chat about what we’re doing with streamlining govt procurement and how your gem could be very useful.
        petepete 5y ago
        Any time, peter.yates@graphia.co.uk
kitsune_ 5y ago
The more stuff like this I see (Rails view components and HTML over the wire) the more I realize how, for lack of a better word, "advanced" ASP.Net MVC was over 10 years ago...
- petepete 5y ago
  Yeah, that's undoubtedly the case. Rails appears to have (Apple-style) taken some cues from elsewhere and made the user experience actually nice.
  - granshaw 5y ago
    They were truly one of the first frameworks to give a hoot about developer experience
    - capableweb 5y ago
      Smalltalk will always be the first example (and probably epitome) of maximizing the developer experience.
- finniananderson 5y ago
  I have a Hotwire post cooking too - stay tuned ;)
- switch007 5y ago
  Could you explain please, for those of us unfamiliar with ASP?
  - ratww 5y ago
    Not GP, but ASP.NET had a very rich server-centric (with some client-side capability) component-model almost 20 years ago. It was possible to build a very fast component-based apps without any JS whatsoever (I did a few), with the choice of using client-side code being left entirely to the developer. If you were OK with JS, it also had the capabilities of partial server-side-rendering without page reloads. That's years before Pjax/Turbolinks/Phoenix LiveView were invented. The major issues with it was that creating components wasn't as straightforward as in a modern framework like React, it was seen as "advanced stuff". Also, it didn't really enforce code separation like MVC does, so spaghetti code was the norm. The main "escape hatch", CodeBehind, was also grossly abused by developers, so leaky abstractions were the norm in it. It was also neglected a bit by Microsoft IMO. It could have been a cool tech for niche apps, but most people chose to run to the next shiny thing rather than really learning how to make a good application in it. Kind of a shame.
jrochkind1 5y ago
i wish there was a way to share view_components in gems, with CSS and JS coming along with them. Just a further variation of the "no simple way to share JS in a gem to be packed via webpacker" story, I guess.

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.
    - jnathsf 5y ago
      This is amazing! I’d love to chat about what we’re doing with streamlining govt procurement and how your gem could be very useful.
      - petepete 5y ago
        Any time, peter.yates@graphia.co.uk

kitsune_ 5y ago

The more stuff like this I see (Rails view components and HTML over the wire) the more I realize how, for lack of a better word, "advanced" ASP.Net MVC was over 10 years ago...

petepete 5y ago
Yeah, that's undoubtedly the case. Rails appears to have (Apple-style) taken some cues from elsewhere and made the user experience actually nice.
- granshaw 5y ago
  They were truly one of the first frameworks to give a hoot about developer experience
  - capableweb 5y ago
    Smalltalk will always be the first example (and probably epitome) of maximizing the developer experience.
finniananderson 5y ago
I have a Hotwire post cooking too - stay tuned ;)
switch007 5y ago
Could you explain please, for those of us unfamiliar with ASP?
- ratww 5y ago
  Not GP, but ASP.NET had a very rich server-centric (with some client-side capability) component-model almost 20 years ago. It was possible to build a very fast component-based apps without any JS whatsoever (I did a few), with the choice of using client-side code being left entirely to the developer. If you were OK with JS, it also had the capabilities of partial server-side-rendering without page reloads. That's years before Pjax/Turbolinks/Phoenix LiveView were invented. The major issues with it was that creating components wasn't as straightforward as in a modern framework like React, it was seen as "advanced stuff". Also, it didn't really enforce code separation like MVC does, so spaghetti code was the norm. The main "escape hatch", CodeBehind, was also grossly abused by developers, so leaky abstractions were the norm in it. It was also neglected a bit by Microsoft IMO. It could have been a cool tech for niche apps, but most people chose to run to the next shiny thing rather than really learning how to make a good application in it. Kind of a shame.

jrochkind1 5y ago

i wish there was a way to share view_components in gems, with CSS and JS coming along with them. Just a further variation of the "no simple way to share JS in a gem to be packed via webpacker" story, I guess.