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
Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?
31–40 of 44 posts
Re: Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?
#32Earlier 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?
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?
#33I'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.…
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?
#34Will 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.
Re: Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?
#35Earlier 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…
Re: Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?
#36Earlier 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?
Re: Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?
#37Earlier 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.
Re: Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?
#38I'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
Re: Ruby on Rails: View Components, Storybook and Tailwind - a match made in heaven?
#39I'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?
#40Earlier 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…
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.