I’m experimenting with Turbo/Stimulus, really nice
Now I’m playing with this (not my own) code: Doug Stull / turbo_modal · GitLab
I’m guessing how I can manage the routing on a modal interface: url changing when the user open the modal, the back/forward interaction and the deep linking (enter the app with the modal already opened).
I glued some code together around history.pushstate and it works, but I would like to know if there is an opinionated way to manage these needs. Perhaps some lib that works nicely with Stimulus?
Oh cool. I would love to see what you came up with!
Hi @dstull, thank you for your work!
The code is not presentable yet, but probably I will try to clean and share it to help the discussion.
The basic idea is the following one.
The url change is trivial, is managed with a Stimulus controller connected with every single edit button. In the open() method there is a history.pushState with the caller href. The close() method fire a history.back().
The deeplink is achieved updating the Rails routing: the edit and new actions point to the post#index. Then I created a post_router_controller.js that on load checks the pathname, if it contains the"edit/new" string it searches an element with a matching href and fire a click() event on it. This opens the lightbox.
I didn’t study in deep the navigation by the back/forward buttons.
When you click edit are you populating the modal via a turbo stream response?
@minimul the question is for me or @dstull (che code author)?
By the way yes, the modal’s opening is managed by a stream:
In my work-in-progress code I upgraded the update/create actions to use the stream, too.
Thanks to Files · master · Doug Stull / turbo_modal · GitLab I got my through my issues with populating the modal via the server.
@dstull @daniele Much appreciated.
I pushed a proof of concept working on the top of your code:
Let me know what do you think! Any idea to improve the modal routing?
Disclaimer: as everyone can see I’m absolutely not a JS guy, so the code is far from perfect, use it judiciously
@daniele I just took a look. Nice improvements.
@dstull Interesting. I just did a
bundle update turbo-rails in which turbo-rails went to
0.5.3 and the server side modal population stopped working. Went back to
0.5.3 and everything was peachy.
ArgumentError: wrong number of arguments (given 2, expected 3)
I looked through the turbo-rails changes and this one sticks out.
NPM package staying the same:
turbo_modal ☂ yarn list @hotwired/turbo-rails
yarn list v1.22.4
@minimul same issue form me
The forms weren’t submitting as turbo stream for me without the fix I posted after upgrading…likely some loading issue/contention/etc. So by loading the js module from the gem through the tag in the layout, we load it directly. I then removed from the packs as then there is no need to load it twice.
If we can rely less on webpack loading area under packs, the better off we are as that area tends to get complicated with yarn/node modules, which isn’t needed here as the js is coming from the gem. I have been bitten by the gem sourced js before when it doesn’t update in step with the js pkg…but i feel confident that won’t happen here. Since we use turbo helpers in ruby, it makes sense to tightly couple to the gem here to avoid version diff from ruby helpers to js
Oh yes, true!
This make really sense, I’m going to explore this route.
@dstull I see your rational but I decided to stick with Webpacker:
bundle update hotwire-rails # this will bump turbo-rails to 0.5.8
yarn upgrade hotwired/turbo-rails
- Note: I was using the webpack-dev-server and it needed to be restarted along with the rails server.
Yep…that makes sense. It is all about tradeoffs
I just opened a pull request in the turbo repo that enables updating URLs on frame navigation (links and form submissions) and Turbo Stream responses: Optionally update URLs on Frame navigation and stream responses by bfitch · Pull Request #167 · hotwired/turbo · GitHub
Please take a look and comment here or there if you think it might help with the uses cases above. Thanks!
@minimul @daniele since the last turbo update, the
get request use that I was co-opting has been removed.
This diff shows the updates needed turbo-rails-0.5.8...turbo-rails-0.5.9 · Doug Stull / turbo_modal · GitLab
I’ll likely update the blog soon as well.
I checked out the branch
turbo-rails-0.5.9 but the application js gives a 404.
I tried to clean up tmp/ and node_modules/ too.
I have no problems locally on mac.
I even tried
rm -rf on the directory locally and starting over. I didn’t have any issues.
I updated the readme with steps I just ran on a freshly pulled version of now-merged-into-master-updates README.md · master · Doug Stull / turbo_modal · GitLab
feel free to provide logs and such or even use an issue on that project if you like to dig into this further if you still have issues.
note: I have also updated the blog post How to use modals with forms in Rails using Turbo - DEV Community
Hi @daniele and @dstull! A year later, I’m curious to know if you’d still recommend the same approach to handling routing in modals, or if you’d do things differently?
data-turbo-action="advance" attributes on links that open modals to automatically update the browser’s history. Now I wonder what would be the best way to update it when closing the modal. So far, I’m using a Stimulus controller to which I pass the URL to visit when the modal’s close button is clicked. But there might be a cleaner solution that I haven’t thought of?
Thanks a lot!