[petepete]

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

[kitsune_]

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]

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]

They were truly one of the first frameworks to give a hoot about developer experience

[capableweb]

Smalltalk will always be the first example (and probably epitome) of maximizing the developer experience.

[finniananderson]

I have a Hotwire post cooking too - stay tuned ;)

[switch007]

Could you explain please, for those of us unfamiliar with ASP?

[ratww]

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.

[dsego]

I remember that you could build components (controls) in in a visual editor and wire up events with your code written in C# or whatever. Some controls came with baked in JS, like accordions and such. You could also wrap a part of your page in a ajax wrapper, and it wouldn't reload the whole page. The framework would generate all the glue code to send the POST requests etc, essentially abstracting the HTTP layer altogether. It would even keep local state in a hidden input field between re-renders.

[dustymcp]

haha my exact thoughts

[nsonha]

Some people just wont shut up about this. Sure, requiring a server to display some html is really "advanced", doubly so when you use a dozen of "technologies" because a js only codebase is lame.

[finniananderson]

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]

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/) 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]

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

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]

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]

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]

Any time, [e-mail]

[jrochkind1]

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.