projectblacklight
Remove Rails UJS in favor of Turbo
Discussed on the 5/18/22 committer call. Rails 7 recommends using Turbo instead or UJS and Turbo functionality has been added to the main/8.x release branch of Blacklight. There is some documentation on the turbo-rails gem which may also be useful. Most of the ujs dependencies may be already removed. There are some references in these files:
- https://github.com/projectblacklight/blacklight/blob/46c2970610835f6f382b4b357ca9b45c1217a35a/app/views/search_history/index.html.erb#L10-L12
- https://github.com/projectblacklight/blacklight/blob/46c2970610835f6f382b4b357ca9b45c1217a35a/app/views/bookmarks/_clear_bookmarks_widget.html.erb#L2-L4
- https://github.com/projectblacklight/blacklight/blob/bd405bd43a19d0e2b252f32a9b78f487087d8505/lib/generators/blacklight/assets_generator.rb#L62
- Wiki page
I get this suggestion, to stay with supported Rails happy path.
But I don't use turbo in my app and don't really want to.
Would there be a way to avoid turbo infecting the rest of my app, but just have it available for Blacklight to use where Blacklight needs it? I don't want turbo's page transitions for instance, all over my app, I just want ordinary page transitions.
Or is it crazy to consider replacing the limited use of UJS with custom-fit plain JS instead of turbo? Or removing custom JS behavior?
@jrochkind sure, someone could absolutely do that. For my app, I'm going to stick with the Rails defaults though.
@jrochkind sure, someone could absolutely do that.
Are we sure someone could do that? How? My concern is that this change would force me to have turbo in my entire app, if I wanted Blacklight to work. If there's a trivial way to avoid that though, then my concern is addressed. But I don't know it myself?
Part of it is that I have an existing app that would probably have to have many parts re-written to work properly with turbo features enabled everywhere. Part of it is that I've just never been fond of turbo. If many other Blacklight app devs are in the same circumstance (I think probably? but maybe not?), then not wanting your app to be forced to use turbo everywhere may be a use case important for Blacklight to support?
@jrochkind This was me inviting you to contribute that code. I'm happy to use the rails defaults. If you don't want to, please contribute the code necessary to replace it.
Oh okay, thanks. I thought you were affirming it was possible. I don't even know if it's possible, and don't know how to write code to contribute.
This is me expressing concern at an issue directing a change (to have BL rely on turbo) to blacklight (this is not an issue on your app, but on blacklight that we all share), that seems to suggest making a change that may make my intended use-case impossible. But I'm just one person, perhaps I'm alone. (I missed the committer mtg yesterday cause I was out on PTO)
If this is a use case that matters, I don't think it's appropriate to merge a PR that breaks it, based on the invitation that someone else can submit another PR to restore support for the use case if they can figure out how -- but that is also just my opinion. This is just me leaving my opinion, I understand it may not represent community consensus.
I hear your feedback @jrochkind. Perhaps what we can do is make sure we annotate each element we use for turbo with data-turbo="true" (https://github.com/hotwired/turbo-rails#navigate-with-turbo-drive). That way upstream folks can disable global Turbodrive with Turbo.session.drive = false?
Discussed in the 19 October Committers Call: we should add some documentation saying that turbo is enabled, and with the procedures for turning it off. And we were in consensus about the approach mentioned in Trey's comment with data-turbo="true"
