Postponed

See #3393105: Hotwire Turbo minimum viable implementation for more information. We may implement this at a later date but it's out of scope for the time being.

Problem/Motivation

References:

The links above show an overview of what Symfony UX is trying to accomplish as well as the "Hotwire Turbo integration for Symfony" which relates to this project. This issue was created to gauge interest in working to use as much Symfony UX Turbo as possible and see what contributors to this project have to say about the idea.

I believe work in the "ux-turbo" repo can be incorporated into this project, specifically the TurboStreamResponse class and integration into the router component.

Proposed resolution

I'm not far into investigating how this module can be updated to integrate with what Symfony is doing, but I wanted to see if others had feedback as well as have someplace where potential collaboration can be had between Drupal and Symfony communities.

Changes I know so far that have to be made:

  • All JS needs to be loaded in <head> and not the end of <body>. An initial solution might be to move the js-bottom to the placeholder for the head-js.
  • BigPipe - I'm not sure where Drupal is at with BigPipe and if it played out as people wanted. But I imagine the placeholder tags would interfere with registering Stimulus controllers and attaching them to events.
  • Drupal.behaviors "attach" needs to fire on turbo events. There are no page refreshes so looking for a load event won't work. It's more an event like turbo:load that needs to be listened to.
  • Drupal.behaviors would be converted to use Stimulus controllers.
  • TurboStreamResponse has to be implemented in some way for turbo streams to work properly. Hopefully using Symfony components for routing in Drupal helps make this addition easier.
  • Integrate the Entrypoints module or some other way to load bundled CSS/JS. I'm not sure if Webpack Encore will continue or they will move to an unbundled "import map" approach like in Rails 7...but if more Encore features can be utilized then it takes more maintenance burden off of Drupal's contributors.
  • A theme with templates for Turbo needs to be created and linked with this project. Symfony UX uses Twig also, so once again, hopefully, the templating work is made easier by re-using what Symfony is already developing.

That's about all I can think of for now. I really like the idea and experience of Refreshless, and I hope enough people are interested in the Drupal world to provide a coupled, monolithic version of Drupal that still feels like a SPA done with JS...then the people with large budgets and many devs can take the decoupled approach. However, every Drupal project I've worked on (in small teams, mainly) would benefit more from Turbo than Decoupled Drupal.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Comments

afinnarn created an issue. See original summary.

ambient.impact’s picture

ambient.impact
they/them
Primary language English
Location Toronto
commented

I'm very interested in helping out with this effort. I see Turbo as incredibly powerful and a great argument that progressive enhancement and a modern, app-like feel are completely compatible.

I think starting with a barebones minimum viable implementation is the way to go, and then build on that with the additional points listed. Some initial thoughts:

  • BigPipe - I've only tried it briefly for a while and then just stopped using it altogether, so at least in my own work it's kind of fizzled out. Not sure about placeholder tags but I'm assuming we can just say this isn't compatible with BigPipe and require that it isn't enabled?
  • Drupal.behaviors would be converted to use Stimulus controllers - While I'm personally interested in experimenting with Stimulus, is this required to get the basics working? I know it works really well with Turbo but I'd leave this as a nice to have unless it's required.
  • Integrate the Entrypoints module or some other way to load bundled CSS/JS - Unless this is required, I'd also like to have this as a nice to have, optional integration. Ideally, Drupal core's aggregation would just work out of the box, and this module would just work with that or whatever else is used to bundle/aggregate assets, e.g. Advanced CSS/JS Aggregation.
ambient.impact’s picture

ambient.impact
they/them
Primary language English
Location Toronto
commented
Issue summary: View changes

Fixed and improved some code formatting in the summary for you. ;)

ambient.impact’s picture

ambient.impact
they/them
Primary language English
Location Toronto
commented
Parent issue: » #3294430: RefreshLess 2.x roadmap
ambient.impact’s picture

ambient.impact
they/them
Primary language English
Location Toronto
commented
Issue summary: View changes

Added link to Symfony UX Turbo documentation.

ambient.impact’s picture

ambient.impact
they/them
Primary language English
Location Toronto
commented
Version: 8.x-1.x-dev » 2.x-dev
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2692343: Use the official Turbolinks JS or rename the project

Thank you so much for taking the time to do this write-up, @afinnarn, and for refining it, @Ambient.Impact! 🤩 👏

Hesitation

I am hesitant/concerned about adopting https://turbo.hotwired.dev/ because of the big notice you can see at the top of https://www.drupal.org/project/turbolinks

They were very aggressive about it.

Then again … https://github.com/symfony/ux-turbo seems to have been around for a while and they somehow did not get shouted at by the creators of Turbolinks? 🙃🤷

Technically

Technically speaking, I'm not at all opposed to reusing a Symfony component! 😄

+1 for @Ambient.Impact's proposal to (at least initially) require BigPipe to be disabled.

Drupal.behaviors would be converted to use Stimulus controllers.

This sounds like it would be impossible to make it work automatically for contrib/custom modules' Drupal.behaviors? 😅😱 Sounds like @Ambient.Impact has similar concerns.
We'd need to figure out a way to make this work transparently, otherwise this seems not viable. (I did not look into what "Stimulus controllers" are.)

Similar concerns apply to the loading of additional CSS/JS.

Conclusion

Big +1 for creating a new branch of Refreshless that adopts this! But prior to building it all, I think we should prototype the foundations to ensure it can work as early as possible, without spending weeks/months on building this. Happy to provide reviews 😊

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#3393105: Hotwire Turbo minimum viable implementation

OMG, it looks like this prototype now already exists!?

sebastix’s picture

sebastix
Primary language Dutch
Location Breda, Netherlands
commented

@WimLeers

@Ambient.Impact showed me a video of the prototype through Mastodon a while ago, but I can't find it anymore.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

I watched presumably the same video in in a Drupal Slack DM earlier today.

The next step here is to i) review, ii) manually test #3393105: Hotwire Turbo minimum viable implementation. You could help with that, @Sebastian Hagens 😄

ambient.impact’s picture

ambient.impact
they/them
Primary language English
Location Toronto
commented

@Wim Leers

I am hesitant/concerned about adopting https://turbo.hotwired.dev/ because of the big notice you can see at the top of https://www.drupal.org/project/turbolinks

They were very aggressive about it.

For what it's worth, I read through the exchange you had with them and was appalled at how they treated you. Sure, there's some reasonable discussion they could have had about naming and branding, but they threw that out the window.

Then again … https://github.com/symfony/ux-turbo seems to have been around for a while and they somehow did not get shouted at by the creators of Turbolinks? 🙃🤷

It's probably because they use the official Turbo that it's technically okay with them. I think as long as we don't use the Turbo name other than to refer to our own integration with the official Turbo library/framework we should be following their requirements, even if we feel they're overly restrictive/stringent.

This sounds like it would be impossible to make it work automatically for contrib/custom modules' Drupal.behaviors? 😅😱 Sounds like @Ambient.Impact has similar concerns.
We'd need to figure out a way to make this work transparently, otherwise this seems not viable. (I did not look into what "Stimulus controllers" are.)

Yeah, I can't really see an easy way to do this automagically that won't break some contrib code. It'd be interesting to explore at some point, but it feels like a whole project in itself. Also, controllers in Stimulus are just JavaScript classes that get automatically attached and detached to various elements. There's a bunch of other stuff that I'm glossing over, but that's how I understand them.

OMG, it looks like this prototype now already exists!?

😎

@Sebastian Hagens

@Ambient.Impact showed me a video of the prototype through Mastodon a while ago, but I can't find it anymore.

Just uploaded it now to YouTube: https://www.youtube.com/watch?v=KYd7vQZRqMo

ambient.impact’s picture

ambient.impact
they/them
Primary language English
Location Toronto
commented
Issue summary: View changes
Status: Active » Postponed

See #3393105: Hotwire Turbo minimum viable implementation for more information.