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.
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...
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.
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.
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.
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 :-)
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.
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.
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.
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.
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.
Came back to comment on this as I've been giving it some thought. Comparing with Django Components I find Slippers to be much better. The YAML approach doesn't bother me much, as it is very limited.
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.
Slippers does look interesting - not sure I like the idea of declaring components in a YAML file but otherwise it seems to address the pain points of components. Would be interesting to see how well it integrates with Django forms.
I guess Jinja macros are also pretty good as a basis for building components as well, but I've always found switching to Jinja 2 in a Django project to be too much hassle to be worth it.
Agree. I've also tried Jinja macros and despite I was satisfied with that, it feels a lot like you're moving away from the core of dj ago. Suddenly translations don't work.and you need other solutions, templatetags don't work, and most third party libraries are built for Django templates, not Jinja. Definitely not worth it.
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.
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.
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.
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.
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