Active Model’s errors are now objects with an interface that allows your application to more easily handle and interact with errors thrown by models. The feature was implemented by lulalala and includes a query interface, enables more precise testing, and access to error details.
This has been in the work since Rails 5.x and I believe Lulalala extracted it from his work on Gitlab. And it was lot of hard work.
Since both Github and Shopify now runs on Master, I dont think there are any other open source web framework that is more battle tested than Rails.
I'm really excited about the Error Objects. I guess error handling probably isn't the most glamorous thing, but lulalala's hard work will make that part of our lives so much easier. I really appreciate the work they did on this feature
DHH mentioned "NEW MAGIC" when he released the Hey stack on twitter [1]:
> The HEY stack:
- Vanilla Ruby on Rails on the backend, running on edge
- Stimulus, Turbolinks, Trix + NEW MAGIC on the front end
There has been a lot of speculation since then on what New Magic is. It was supposed to release at the same time as hey.com but they decided to postpone it till later. Many people think/hope that it is something similar to Phoenix LiveView
So we know NEW MAGIC will involve a substantial amount of integration with Rails on the server side but it could technically be ported over to other frameworks.
It's interesting because StimulusJS 2.0 and Turbolinks 6 are fully client side based on previous tweets by members of Basecamp. I wonder if NEW MAGIC will be focused on broadcasting real-time updates to the front-end while partial page updates that would normally be server rendered templates could be handled by Turbolinks 6 alone. That would be great news for anyone wanting to create amazing feeling apps with any back-end stack, without going the SPA route.
This article[1] and the others in the series give an idea of the direction by analysing how hey.com works. The page-updater library looks to bring a more declarative replacement for server-generated JavaScript responses, for example.
Couple of changes here that would be directly useful in what I'm working on. Does boost my confidence - as a dev newer to Rails - that the rough spots I'm spotting are recognized by other folks as well. It also tells me I can be more proactive in proposing changes, or at least in addressing those rough spots.
It's a really nice time to be a Ruby / Rails developer. Rails itself has made some really nice improvements with this release and there is also the "NEW MAGIC" should be following in the next couple of days which is currently being sold as what Rails was to the back end, this will be to the front end.
Ruby 3 is also just a few days away which brings optional type checking to helps add some additional structure to larger code bases.
Then in the wider community you have projects like Hanami 2.0 looking to launch next year which aims to bring all of the structure of "clean architecture" approaches and best practices with the simplicity and expressiveness of Ruby.
Man I'm hoping NEW MAGIC is like Phoenix LiveView. As a Rails dev I started looking into the Elixir/Phoenix world just for LiveView but I don't really want to switch languages... I just want that new magic that LiveView offers. I know there are gems for Rails but I'd prefer if it was baked-in and officially supported.
Haha I would love to and it seems like a really great language/community/ecosystem. I'm just a part-time developer though, so my "coding time" is extremely limited and mainly just around scratching an itch as quickly as possible. I'm confident Elixir/Phoenix would give me that speed and comfort too, but I already know Rails and the time I would spend learning Elixir/Phoenix just to get access to LiveView would be better spent just learning Javascript and moving on.
I wish I had a use case where Elixir's concurrency model makes the initial lift worth it, but my work doesn't even require me to learn how to make Ruby scale past a $5 DigitalOcean droplet.
Yeah, that makes sense. For smaller projects, I don't think anything matches Ruby in terms of pure solo-dev productivity. I still use it for scripting.
One thing I would advise, given your situation, is to avoid full-blown SPAs. You can use something like Stimulus Reflux and be way more productive than going down the whole React/Redux/library explosion rabbit hole. Ditto for spending a lot of time on Kubernetes, Docker, etc.
If you're not a full-time dev, just do things with the minimum abstraction needed.
You're spot on. I tried React and Vue and it just adds so much complexity for a solo dev. Right now I'm just using tiny bits of JS here and there, but I'm really hungry for something like LiveView that would let me do interactive front-ends while not having to manage state and authentication on the front-end.
Depending on your patience you can go and take a look at a real life implementation of it at https://app.hey.com since they enable source maps.
What the actual developer facing API is going to look like however is another question. I do kind of worry that given how much is has been talked up by DHH in particular that it is going to struggle to live up to the hype.
Either way, I am excited to see something new in the Rails front end space, that has felt like it was lacking a LOT of structure.
I was sold on hey.com's UI design already because it's using <details><summary> for dropdown menus.
The really fun part, though: the summary content isn't just a menu icon, it's a trigger for some (currently unpublished) Turbolinks variant. The menu content is loaded (and subsequently 304'd) dynamically as a server-rendered partial (sans layout).
Most tellingly, if you visit the menu content's XHR URL with regular browsing then hey.com renders that menu as the sole content in a page layout.
We can't see the server-side parts yet, but if that becomes an out-of-the-box end-to-end behaviour within Rails, then in conjunction with Stimulus 2 and Action Cable I'm stoked about the possibilities. Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled. But it's also good for mundane stuff like progressive form validation in line-of-business apps.
Based on my casual browsing of the code I assume that it pushes small HTML fragments via WebSockets whenever the backend state changes on a given ActiveRecord model. It covers things like automatically updating the state of a model on a page, adding, removing, reordering elements etc all without any custom code so long as things are wired up correctly.
Basically, all the "re-activeness" of an SPA but without ever having to worry about the concept of client side state management at all.
Edit: I am a grumpy old man in web-dev years who hadn't ever really looked into Phoenix Live View before now but after watching a video on how it works, yes, my understanding is that it works basically the same way.
> Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled.
Can you elaborate on why `<details><summary>` is specifically exciting to you?
It works without Javascript, which means a few things.
Firstly, for customers; it works behind asset-blocking insane corporate firewalls, or for some poor schmuck in the sticks getting one bar of cell data and just enough to load our HTML, or simply to impress anyone running uBlock₀ in Advanced mode.
Secondly; because front-end Javascript bitrots faster than any code I've ever seen in four decades in tech. Reducing the quantity of JS in favour of letting the browser just do its job, is one of the best investments I can make against technical debt. JS can't be abandoned completely, but I measure every kilobyte jealously, and graceful degradation to baseline browser behaviour is my north star; simply using baseline browser behaviour is by definition my optimum limit for long-term productivity.
Thirdly; for folks depending on assistive browsing technologies. Yes, they do work in the face of dynamic web pages & SPAs, but many screen readers are still at their best when tabbing through plain HTML with a sprinkling of ARIA markup.
Finally, it's also a simple yet versatile mechanism. Good for anything from FAQ items to dropdown menus, even with default styles.
LiveView is awesome - I'd be pleasantly surprised if Rails were able to pull off something that good with Ruby's more limited capacity for concurrency.
Ruby 3 is putting a lot of emphasis on concurrency with the new (experimental) Ractor Actor model [1] and the Fiber Scheduler [2]. Concurrency in Ruby is getting a lot better.
I’m so glad the pendulum seems to be swinging back to sensible server side based web dev that embraces the web and layers in dynamic front end behavior when needed. Most sites need a small amount of JS. Some benefit from quite a bit more, and for that there are things like Stimulus. And maybe you need a ton and it needs to work offline and manage a ton of local state - for that there are the usual SPA suspects. But those are and should be outliers.
The fact that “let’s use React with a JSON API Backend” is becoming much less the default is a very good thing. Web dev went into a dark time for awhile there and I’m hopeful we are coming out of it.
We're also hard at work over at the Bridgetown project to make Ruby a first-class citizen on the Jamstack. A static Bridgetown site combined with a Rails API is a killer combo for some pretty interesting use cases. Anyway, you're absolutely right—what a time to be a Rubyist! =)
> Ruby 3 is also just a few days away which brings optional type checking
Just curious, has anyone here been using type ruby type checking effectively? (since Sorbet is already available and working in ruby 2).
My experience across ruby, python, and js codebases is that Typescript for JS is leaps and bounds above anything in the other two languages, both in its capabilities and overall community adoption, and the lead is only growing. I could be wrong, maybe it will hit some critical point soon and take off, but I don't realistically see type checking catching on in ruby or python.
I tried integrating Sorbet into my side project and it was pretty challenging. I gave up. It seems to be super sensitive to small things. Can't exactly remember what made me just rip it out altogether but yeah it was a huge pain. It seems really great though, I should give it another go when I roll out some more features.
Lots of good stuff in here, including much more support for using UUIDs as PKs.
My favorite new feature is "delegated type" in ActiveRecord to offer a new way to map class hierarchies onto database tables. I wrote a blog post about it[0], but the actual PR is very readable as well[1].
We implemented something like this on our own. We have child classes that inherit from an AR-backed parent, and on the parent we implement an instance method that transforms it (via #becomes) to the appropriate child based on the value of an attribute. The final piece is another attribute that stores a serialized object of child-specific attributes, and other methods that dynamically define attribute readers at boot time. It'll be nice to migrate to this new feature to free ourselves from the burden of that last piece in particular.
Seems really nice. It's just a Rails abstraction for Multi-table inheritance (MTI) but to me that was sorely needed. MTI always felt much more manageable to me than Single-table inheritance but the latter was the only one with built-in support in Rails, until now.
Does a "delegated type" work with preloading associations, ala "includes"? This remains a pain point with many polymorphic associations in Rails, but not sure how the new functionality handles if, if it does at all.
Based on this GitHub comment[0], it appears the answer is yes although it requires a little additional customization out of the box to prevent N+1 queries..
In conjunction with Rails's "russian-doll" caching, N+1 queries are (or at least, can be) a good thing.
This sounds counterintuitive; but, in the common case of read-heavy services, N ≐ 0 after the first access. When something changes, subsequent views end up loading & rendering the one record that changed, instead of preloading an entire collection.
However, achieving this in practice requires some care in the nesting of view partials and records.
Hey, just wanted to thank you for the link. This sent me down a deep rabbit-hole of DHH interviews! I'm surprised I haven't taken notice of him before, he has so many profound insights. I am really grateful :)
You're welcome. I think he's a deceptively clear thinker, by which I mean, DHH tends to supply a correct and insightful answer without discussing all the potentially wrong ones, or even unpacking all the insights contained within. It's left as an exercise for the student to realise how any particular "road not taken" would've been inconsistent with Rails's underlying principles.
I don't mind that, since I've chosen to infer an assumption that we're all as smart as he is. (even if it does then take me years to explain things to myself...)
If you didn't find it already, his "On Writing Software Well" video series is a fascinating, and sadly abbreviated, journey into his own application code.
> Lots of good stuff in here, including much more support for using UUIDs as PKs.
I missed this. Going through the changelogs the only thing I found is support case-insensitivity for pg UUID types. Is that what you meant?
I really think that not supporting UUID PKs is one of biggest issues with Rails. You can go around it and maybe even use a gem for it, but that's still a bit risky.
Hey, sorry for the aside - I am a Rails developer since Rails 4ish and we are running Rails 5 at work. I'm using Rails 6 for my own projects and in these side projects, I've been having a huge hell of a time trying to grok "right ways" to do things with webpacker/webpack. I seem to encounter issues every single time with deploys to Heroku because of precompilation issues, or imports not running right. But tutorials get out of date so fast and I'm constantly trying to just remove stuff just to get my builds to work. Are there any Rails focused chatrooms or places where I can get into the nitty gritty of these things without needing to post GitHub issues and piss off maintainers all the time?
I just don't really grok how to use modern Javascript I guess, but also integrating with Rails webpacker has been a source of constant frustration. I can't even figure out how to properly package JS libs without just giving up and using jsdelivr instead. Would love any kind of pointers!
I would definitely advise against webpacker. It's very much the case of trying to fit a square peg in a round hole. The two don't work all that well together, despite the pretty heroic work done by the webpacker team.
For an "idiot proof", batteries included, zero config approach, I would try out Parcel: https://parceljs.org/getting_started.html You just pass it an HTML file and it figures out what it needs to build from there. You can drop everything in /public/ and it all just works without any additional installs or fiddling. It works with pretty much anything you might drop in as an asset, whether it's via HTML tag or import statement.
As a close second, you can try esbuild: https://esbuild.github.io/ It's coming along and already does a lot of what you might do with Parcel or Webpack, but is stupendously fast. Fast enough that you'd need to be shipping an obscene amount of code to the browser to have build times exceed 1 second. It's a little more quirky right now, but I like it and appreciate the forward momentum it has right now.
Hey, I'm a JS dev who's been splashing around in rails for the past year or so. I'm happy to help! I just had a similar issue this morning, and I asked in the Ruby on Rails Link slack [1]. They're pretty helpful in there.
For what it's worth, my issue was that Heroku was running `rake assets:precompile` without node_modules being installed. This was because `yarn install` failed. I looked closely at the logs and saw an error about the yarn file needing to be updated (the lockfile pins exact versions). So I ran `yarn install` locally to update it, redeployed, and it worked. So far I've been able to use node modules with sprockets this way just fine (in JS and Sass). Webpack-generated JS bundles work well too. Anyway, happy to help in there, just tag me :)
And yes, I experienced the same issue you discussed! That has helped in the past a few times. I wonder what the advantage is to precompiling as opposed to doing it at build time during the deploy step.
Wanna be friends and show me the way? Webpack seems super popular, but like there's so much shit going on. Ok node, great.. JS runtime, got it. NPM, package manager, alls good so far, just like Hex for Elixir or Cargo for Rust, perfect, makes sense. Oh wait, huh? I gotta use yarn for my webpack? Alright... yarn add <module>, then I gotta precompile my assets... why? Why can't I just have that happen at build/deploy time? ... ok....
Then I get errors like this (even though I can run my app locally and everythings fine):
<markup>
Parsed request is a module
using description file: [absolute path to my repo]/package.json (relative path: ./src)
Field 'browser' doesn't contain a valid alias configuration
aliased with mapping 'components': '[absolute path to my repo]/src/components' to '[absolute path to my repo]/src/components/DoISuportIt'
using description file: [absolute path to my repo]/package.json (relative path: ./src)
Field 'browser' doesn't contain a valid alias configuration
after using description file: [absolute path to my repo]/package.json (relative path: ./src)
using description file: [absolute path to my repo]/package.json (relative path: ./src/components/DoISuportIt)
as directory
[absolute path to my repo]/src/components/DoISuportIt doesn't exist
no extension
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt.js doesn't exist
.jsx
Field 'browser' doesn't contain a valid alias configuration
</markup>
and I don't even know what to say. What the hell is going on? Why has God forsaken me?
What's supposed to be the big win mixing webpack and Rails over, say, creating a separate React/Vue app and a Rails API? Webpack seems to slow-down the whole edit/view cycle which is pretty snappy in vanilla Rails.
You can sprinkle react components into your regular templates which is quite nice. A full blown SPA feels like way overkill (for my own projects, at least) when Rails handles forms and navigation so much better. You can include packs on a per page basis so it doesn't slow down / bloat the rest.
Completely agree, I run a Rails 6 app which provides a JSON API. This is then used by Create React App app running in the /clients folder at the root of the Rails application folder. Keeps it separated nicely.
"rafaelfranca released this 1 hour ago · 324 commits to master since this release"
That's the sign of a very actively maintained project!
(To clarify: those 324 commits didn't all happen in the past 60 minutes, but it does show that there's a huge amount of development activity going on around Rails core)
Yeah, I think this is indicative of a feature lock during the RC period, and once the release is cut that opened up a bunch of PRs that were just waiting in the wings.
For what it’s worth, the 2->3 update was by far the most consequential; they merged in Merb, rewrote how routes and controllers worked, and completely flipped expectations on how JS and views should work.
Rails 3->6 has had far fewer major user-facing architectural changes, and consisted mostly of new tools and APIs. A lot of stuff they added used to be handled by gems - password hashing, attachments, background jobs, caching, etc. all got rolled into the core framework.
Another comment mentioned https://guides.rubyonrails.org, which is good. I would focus on the new routing style, REST controllers, forms, and strong params; once you wrap your head around those, the rest will probably fall into place, or could be ignored completely.
I genuinely think someone from the 2.x days could read a "how to migrate to Rails 3" guide, skim some release notes for each of the subsequent major releases, and be generally up to speed. I've been working with Rails almost continuously since the 3.x days, and if you ignore some of the more library-like additions like ActiveStorage or Credentials, things are structurally extremely similar between 3.2 and 6.0. The biggest differences to a casual reader would probably be Ruby syntax itself developing from Ruby 1.9 forwards to this point. Things were quite different in the 1.8.x days.
Models live in the same spot. Controllers live in the same spot. Your classes generally still inherit from the same stuff, albeit with some additions to the tree like for ApplicationRecord in places where you might previously have inherited directly from ActiveRecord::Base.
The stability is one of my favorite parts of Rails. Its still modern and very usable, but I don't need to relearn it all the time.
IMO it really has not changed much even from the 1.x days it’s just a bit more polished with AR having where syntax now instead of only find and better solutions for organizing code that isn’t strictly model/view/controller. But if i opened a rails 6 or rails 1, it’d be pretty easy to find my way around...
Avoid too many after hooks and before filters(er actions) and the code will be easier to follow and maintain
Railscasts sadly is no longer but now the two big ones that operate in that space are GoRails and Drifting Ruby. Some other non-screencast resources I like however are Boring Rails and Playbook Thirty Nine (ebook of tips and tricks from the trenches of a real life smalltime Rails SaaS business)
One of my favorite characteristic of Rails community is there is less to non-existence of superiority of paradigm nonsense. Since I switched to other languages/frameworks, discussion around Slack/forum is plenty of non-realworld usage .. great engineering (without user interaction). It's painful when you want to ship, not only to play.
Rails is full of libs for building real business. Github and Shopify 's engineers are around, this contributes great sense of realword usage. Features extracted from that are battle-tested.
Bonus is DHH is still involving since he loves programming anyway, and he is a great communicator, spicy tweets on HTML CSS keeps the web sane .. from those madness.
Rails really is something special that can't be replicated by simply leaving the Ruby ecosystem and trying to reinvent "the good parts" in another language / framework.
You'll be missing out on one of the best parts of Rails which is an actual business extracts features into Rails from real world usage. That and Shopify + GitHub + Basecamp are running Rails master so by the time regular folks like us use a release it's already insanely tested in the real world with hundreds of millions of requests passing through these features. The confidence level that brings to the table that it's going to work for your app is unrivaled.
The massive amount of community support (gorails, etc.) and library ecosystem is icing on the cake.
What did u switch to? I keep wondering whether I should stick to Ruby and call it a career or just look for jobs that interest me / good career move , regardless of stack.
I'm hoping for vuejs and rails tie together. As a previous rails developer I never loved backbone angular or react but felt at home with vuejs and am jealously watching the laravel community embrace vue
Active Model’s errors are now objects with an interface that allows your application to more easily handle and interact with errors thrown by models. The feature was implemented by lulalala and includes a query interface, enables more precise testing, and access to error details.
This has been in the work since Rails 5.x and I believe Lulalala extracted it from his work on Gitlab. And it was lot of hard work.
Since both Github and Shopify now runs on Master, I dont think there are any other open source web framework that is more battle tested than Rails.
Still waiting for New Magic though.