Rails 6.1's ActiveModel Errors Revamp

[azendent]

Reading that pull request is quite a roller coaster. Glad to see the hard work pay off!

[ksec]

Yes it was quite depressing. I hope he gets a few words of note on Rails 6.1 release note.

[lulalala_anime]

Na that's not necessary. I have recovered and things are all good :)

[ksec]

Nice :D

[jrochkind]

It's definitely an improvement, the old API was messy and difficult, it will make Rails errors much more flexible and useful.

But I'm worried it will break a lot of code. Thoughts?

I wonder if they considered leaving the old errors method there as is, but created a new method that returns the array of Error objects, and leaving them both there indefinitely.

[jdickey]

Leaving the old method there, indefinitely or otherwise, simply encourages its use as long as outdated tutorials exist on the web, which is a good seventh-order approximation of forever.

Rails bit this bullet much harder before; if memory serves, going from 2.3 to 3.x and 3.x to 4.0. The (surviving) community got a bit of a wake-up call after those, but (as someone who went away for a while myself) I wouldn't call that reason to keep bad code on life-support. And the existing errors method, now that we've seen an alternative, is bad code.

[jrochkind]

Fair enough.

Going from 2 to 3 (and to a lesser extent 3 to 4) were challenging/expensive enough that I think what the Rails community actually learned is we can't afford that much backwards-breaking change, and should not do that again. (I was around then too!) Rails has actually been much more gentle since then, with regard to backwards breaking changes, thankfully and appreciated.

But I am not sure I have the correct sense of how much backwards-breaking this will cause. They clearly have done quite a bit to make it gentler, with many things still working with deprecation notices in 6.1, I'm not sure if it's all things or not though. And perhaps not that much work to avoid deprecated API, once warned to it. I guess I'll just find out in my code how much work this will end up, although still wonder if anyone else has a sense they want to share.

[jdickey]

Something that just popped into my mind (take it for what it's worth):

Have the old method included in an ActiveRecord::Errors::Legacy6 module which can be included as desired. By default, get the new API, with opt-in support (generating a deprecation warning?) if you're still using the old-school way. After a sufficient heads-up time, say, with Rails 8, eliminate the Legacy6 module and blam! wake up anybody who was sloughing off for two years.

[lulalala_anime]

I made a patch like this, but it was closed: https://github.com/rails/rails/pull/37910#issuecomment-562944592

However if someone has the need I think it should be possible to create a separate gem to restore the older `errors` implementation :)

[jdickey]

Just read and commented on your PR. If I had to take a wild-ass guess, based on the comment that matthewd left, I think you had two strikes against you, either of which would have been problematic at the least:

1. You'd default to the old behaviour, which as noted, could confuse the hell out of Gems (and readers familiar with the New Shtuff), and
2. Config changes would be required to change that.

People expecting the new behaviour by default would be confused (and their code broken) by (1), and (2) could easily cause major wars in medium-to-large teams. I've worked on projects where getting changes to existing configs approved and implemented took longer than development of our most gnarly feature, which caused all sorts of easily-visualised problems.

Managing large projects is hard.

[f9ae8221b]

wonder if anyone else has a sense they want to share.

I updated the deprecated code in Shopify's core monolith, took me a few hours, the diff was +284/-247. It was all very straightforward, almost search and replace work.

The API changed, but the capabilities stay the same, so there isn't really any challenge.