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
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.
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.
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.
> 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 :)
"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.
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
ksec|5 years ago
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.
tenderlove|5 years ago
marinhero|5 years ago
Fellshard|5 years ago
mhoad|5 years ago
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.
freehunter|5 years ago
rsanheim|5 years ago
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.
jaredcwhite|5 years ago
dmix|5 years ago
I recently saw a report on w3 showing Ruy is now more popular server-side than Java.
https://w3techs.com/technologies/overview/programming_langua...
Dirlewanger|5 years ago
Oh shit, I didn't realize that that's the scheduled Christmas release. Finally, all strings frozen by default!
cactus2093|5 years ago
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.
sbuccini|5 years ago
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].
[0] https://www.stevenbuccini.com/how-to-use-delegate-types-in-r...
[1] https://github.com/rails/rails/pull/39341
ilikepi|5 years ago
skipants|5 years ago
polutropos|5 years ago
tomca32|5 years ago
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.
arthurcolle|5 years ago
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!
timdorr|5 years ago
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.
timwis|5 years ago
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 :)
[1] https://www.rubyonrails.link/
baggy_trough|5 years ago
unknown|5 years ago
[deleted]
simonw|5 years ago
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)
jamie_ca|5 years ago
kadabra9|5 years ago
When I came back to it to scratch an itch for some pet projects, I barely recognized it. I felt completely lost.
Life moved pretty fast, I guess. Are there any good resources out there for someone from the 2.x days to get back to speed?
xionon|5 years ago
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.
30minAdayHN|5 years ago
Currently, I depend on Rails Guides, and I think they do a pretty good job. Would be good to know other resources.
https://guides.rubyonrails.org/
thismodernlife|5 years ago
onnnon|5 years ago
http://railsdiff.org/6.0.3.4/6.1.0
_gtly|5 years ago
More refined release notes here: https://edgeguides.rubyonrails.org/6_1_release_notes.html
And yet more release notes: https://weblog.rubyonrails.org/2020/12/9/Rails-6-1-0-release...
bleonard|5 years ago
unknown|5 years ago
[deleted]
Existenceblinks|5 years ago
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.
nickjj|5 years ago
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.
joelbluminator|5 years ago
asdf333|5 years ago
pdoub|5 years ago
pupdogg|5 years ago
dlrush|5 years ago
tistoon|5 years ago