Remove "Rails UJS" from app?

[jrochkind]

While the last version still exists for installing, Rails team has pretty firmly deprecated it and it's no longer being installed.

rails/rails#50535

https://guides.rubyonrails.org/working_with_javascript_in_rails.html#replacements-for-rails-ujs-functionality

I am not sure in what ways our app is using it -- is Blacklight 7 still using it? BL7 gemspec doesn't say it requires ujs, but that isn't a reliable indication that it does not. (Blacklight 8 presuambly does not?) That might make it harder to remove, unless upgrading to BL8 (assuming BL8 is not).

The whole Rails JS thing is pretty frustrating -- Rails has moved on to "hotwire", but I do not necessarily think we should jump into that (unless BL8 requires it?), but ideally would simply remove the Rails UJS dependency and not replace it with any other dependencies -- rewrite local code to not require it?

But not sure what's going on, to what extent our app may depend on Rails UJS and how is confusing.

I guess we maybe use it to make some links simulate non-GET requests? Perhaps we do replace it with Rails "Turbo", that's what the "replacements for UJS" doc linked above suggests.

https://stackoverflow.com/questions/70474422/rails-7-link-to-with-method-delete-still-performs-get-request

OK, to get Turbo method and "confirm" function (we also use), but without turbo on all links (that may break things, and may may not want), we may have to use this not really documented "opt in" behavior. I don't love it. https://stackoverflow.com/a/76286583/307106

[bensheldon]

I'll offer that I use UJS in GoodJob and don't plan on removing it anytime soon (GoodJob vendors a module-ized javascript file). From reading the Rails removal PR, other than the documentation I don't see anything functionally changing. UJS uses some HTML data- attributes and that's all. I imagine that someone will extract/fork UJS for maintenance, but it seems pretty stable/simple as JS goes.

[jrochkind]

Good to know @bensheldon , thanks! And I'm honored you are watching this repo. :)

Supplying your own forked/modularized UJS is interesting! I am interested in how you did this, in particular how you get it to apply to links (listen to events?) only in your own code, not in the whole app. Not sure how I reverse engineer that from the minimized file in your source.

I worry that future versions of Rails might no longer work with a no-longer-maintained UJS.

Or that we might in the future want to use turbo (or have a dependency that requires it), and not sure about using turbo and UJS simultaneously in an app (what you've done to limit UJS to only your own stuff might be relevant)

The Rails reliance on GET or POST requests that behave "as if" they were PUT or DELETE to the Rails back-end, that UJS and/or turbo provide, is the hardest thing to just "do without" -- I don't really even understand what UJS and/or Turbo are doing there. (Like is the request really being submitted as a PUT or DELETE via AJAX, or just being submitted as a POST with something that makes rails route it as if it were? I think UJS and Turbo may even ahve different answers there??)

The frustrating thing is how Rails seems to have made it harder to build an app that does supply HTML but does not want to use Rails latest weird JS stuff (I don't trust turbo/hotwire at the moment to stay stable, having been working Rails long enough to remeber the weird old server-supplied JS, what was that called?) -- and with all these new conventions the back-end is expected to comply to to actually be compatible with Turbo!

[bensheldon]

I came from "This Week in Rails" to the Rails PR to the backlink to here ☺️ I am a sympathetic peer.

The UJS is only applied on the pages with a script tag that includes the library. GoodJob has its own engine application layout, so UJS is only active on those pages generated by the gem.

I don't think Rails has any functionality that is specific to UJS that could be removed (the deprecation PR seems to be all JS and documentation). It looks like even turbo uses data-turbo-method instead of UJS's data-method. Maybe there's some slight convenience in link_to or button_to, but nothing I'm aware of that isn't wholly HTML data attributes and vanilla XHR requests.

I think UJS has long provided just enough convenience for how I like to build boring applications, especially when the UI design calls for otherwise invalid HTML of forms-within-forms ("oh, the delete button goes there..."). And I can't imagine pulling in all of Turbo just do do a data-disable-with. UJS has always done what it says in the name: unobtrusive. I guess I'm grieving a little bit 🤗