leastbad / optimism

The missing drop-in solution for realtime remote form validation in Rails.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error with Rails 6.1.0

alliedarmour opened this issue · comments

After upgrading Rails to the new 6.1.0 version the (great) Optimism gem throws an error when you try to start the server.

The error states:
mattr_reader': module attributes should be defined directly on class, not singleton (TypeError)

Tracing the stacktrace I think the error happens in this piece of code inside the Optimism module:

class << self
    mattr_accessor :channel, :form_class, :error_class, :disable_submit, :suffix, :emit_events, :add_css, :inject_inline, :container_selector, :error_selector, :form_selector, :submit_selector
    self.channel = ->(context) { "OptimismChannel" }
    self.form_class = "invalid"
    self.error_class = "error"
    self.disable_submit = false
    self.suffix = ""
    self.emit_events = false
    self.add_css = true
    self.inject_inline = true
    self.container_selector = "#RESOURCE_ATTRIBUTE_container"
    self.error_selector = "#RESOURCE_ATTRIBUTE_error"
    self.form_selector = "#RESOURCE_form"
    self.submit_selector = "#RESOURCE_submit"
  end

Is it possible to move those accessors out of the singleton-class?

@alliedarmour hello! Just yesterday I said that I'd be counting down until folks started pointing out that Optimism breaks under Rails 6.1. Unfortunately, the prognosis isn't good.

Optimism was always a stop-gap solution; DHH has said several times that the next version of Turbolinks/NEW MAGIC is supposed to replace UJS and provide a native fix for remote form validations. Unfortunately, those solutions have somehow not surfaced yet and inexplicably to me, they released 6.1 without addressing this.

While it's true that the singleton concern is problematic and likely could be refactored, the far bigger issue is that Rails 6.1 has a completely new errors object. In order to provide a version of Optimism that works for <6.1 and ^6.1 at the same time, there would have to be two separate implementations of the same logic that run based on the Rails version.

Realistically, I'm not in a position to be able to do that given that it could be a week or two before Basecamp release NEW MAGIC and the whole issue becomes totally moot. Keep in mind: ideally, Optimism shouldn't exist. I can't believe Rails 6 shipped with broken validations on remote forms. I 10x can't believe Rails 6.1 shipped with broken validations on remote forms. The reason it's called Optimism is because I look forward to a day when it can be formally deprecated by Rails itself.

Where does this leave us (you and others)? Well, I'm open to PRs that would make this library work with 6.1, if you don't care that the code could be obsoleted in less than a month. I also encourage you to look at the library and re-implement a version that does what you need in your project... though, if you do that work in processing the new errors object, perhaps you might as well PR it.

I feel badly but I want to be up front and realistic about my availability and - if I'm honest - motivatation for getting this working for 6.1 given the end is theoretically so near. What do you think of all this?

@alliedarmour hello! Just yesterday I said that I'd be counting down until folks started pointing out that Optimism breaks under Rails 6.1. Unfortunately, the prognosis isn't good.

Optimism was always a stop-gap solution; DHH has said several times that the next version of Turbolinks/NEW MAGIC is supposed to replace UJS and provide a native fix for remote form validations. Unfortunately, those solutions have somehow not surfaced yet and inexplicably to me, they released 6.1 without addressing this.

While it's true that the singleton concern is problematic and likely could be refactored, the far bigger issue is that Rails 6.1 has a completely new errors object. In order to provide a version of Optimism that works for <6.1 and ^6.1 at the same time, there would have to be two separate implementations of the same logic that run based on the Rails version.

Realistically, I'm not in a position to be able to do that given that it could be a week or two before Basecamp release NEW MAGIC and the whole issue becomes totally moot. Keep in mind: ideally, Optimism shouldn't exist. I can't believe Rails 6 shipped with broken validations on remote forms. I 10x can't believe Rails 6.1 shipped with broken validations on remote forms. The reason it's called Optimism is because I look forward to a day when it can be formally deprecated by Rails itself.

Where does this leave us (you and others)? Well, I'm open to PRs that would make this library work with 6.1, if you don't care that the code could be obsoleted in less than a month. I also encourage you to look at the library and re-implement a version that does what you need in your project... though, if you do that work in processing the new errors object, perhaps you might as well PR it.

I feel badly but I want to be up front and realistic about my availability and - if I'm honest - motivatation for getting this working for 6.1 given the end is theoretically so near. What do you think of all this?

Thanks for your detailed answer! Yeah I was looking forward to the new remote form validations as this was (or still is) quite of a gap in my opinion with some workarounds you have to do to show validation errors and highlight the fields (js.erb templates for the according action and adding classes via JS). That's why I loved this gem as it made this so easy to accomplish.

I can understand your POV, hopefully those new validations will arrive soon :). I saw the PR but as I'm working with Stimulus Reflex a lot in my applications, it's no option to change it myself and get in trouble somewhere else.

Thanks for your work on this library anyway, it helped me out quite a lot!

Great news, @alliedarmour... thanks to @joshleblanc we have #27 and I was just able to publish Optimism v0.4.0, which supports Rails 6.1 and StimulusReflex 3.4. Huzzah!

Note that you will have to change your initializer from config.channel to config.channel_proc.

That's what I call an early christmas present! Awesome! 💯