Live data from Hacker News

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

finnian.io

31–40 of 44 posts

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

#31
post #9

Earlier quoted context omitted.

Yeah, that's undoubtedly the case. Rails appears to have (Apple-style) taken some cues from elsewhere and made the user experience actually nice.

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

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

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

#32
post #7

Earlier quoted context omitted.

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...

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

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.

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

#33
post #3

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.…

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.

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

#34

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

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.

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.

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

#35

Earlier quoted context omitted.

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?

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 - t…

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.

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

#36
post #7

Earlier quoted context omitted.

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...

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

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.

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

#37
post #35

Earlier quoted context omitted.

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 - t…

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.

Any time, peter.yates@graphia.co.uk

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

#38
post #26

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/ [2] https://unpoly.com

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.

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

#39
post #38
post #26

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/ [2] https://unpoly.com

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.

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

#40
post #28
post #21

Earlier quoted context omitted.

Maybe django-components, if you need something a bit higher level than plain include or inclusion tags: https://github.com/EmilStenstrom/django-components/

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 S…

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.

Post reply on HN