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?
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.
I’m not a javascript expert at all, so my approach could be quite dumb! In case feel free to suggest me a better pattern
@dstull Interesting. I just did a bundle update turbo-rails in which turbo-rails went to 0.5.8 from 0.5.3 and the server side modal population stopped working. Went back to 0.5.3 and everything was peachy.
Error was:
ActionController::UnknownFormat (ActionController::UnknownFormat):
app/controllers/posts_controller.rb:26:in `edit'
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
└─ @hotwired/turbo-rails@7.0.0-beta.3
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
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?
I’m using 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?
