Routing in a modal interface

Hi all!

I鈥檓 experimenting with Turbo/Stimulus, really nice :slight_smile:
Now I鈥檓 playing with this (not my own) code: Doug Stull / turbo_modal 路 GitLab
I鈥檓 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?

Thank you!



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鈥檛 study in deep the navigation by the back/forward buttons.

I鈥檓 not a javascript expert at all, so my approach could be quite dumb! In case feel free to suggest me a better pattern :slight_smile:

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)? :slight_smile:

By the way yes, the modal鈥檚 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.

1 Like

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鈥檓 absolutely not a JS guy, so the code is far from perfect, use it judiciously

/cc @minimul


@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.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

/cc @dhh

Yep鈥ame issue for me. I updated my blog and the example app last night with fix. See this commit Update and load turbo through asset pipeline (ce17a520) 路 Commits 路 Doug Stull / turbo_modal 路 GitLab

@minimul same issue form me
@dstull great!

@dstull is there a particular reason or advantage to extract the turbo/stimulus javascript from the asset pipeline? Cherrypicking a fresh rails/hotwire-rails installation I was able to update to turbo-0.5.8 just revisiting the application.js: Upgrade to hotwire-rails 0.1.3 (stimulus-rails 0.2.2 + turbo-rails 0.5.8) (e14fc020) 路 Commits 路 Daniele Tonon / turbo_modal 路 GitLab

/cc @minimul

The forms weren鈥檛 submitting as turbo stream for me without the fix I posted after upgrading鈥ikely 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鈥檛 needed here as the js is coming from the gem. I have been bitten by the gem sourced js before when it doesn鈥檛 update in step with the js pkg鈥ut i feel confident that won鈥檛 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

1 Like

Oh yes, true!

This make really sense, I鈥檓 going to explore this route.
Thank you :slight_smile:

@dstull I see your rational but I decided to stick with Webpacker:

  1. bundle update hotwire-rails # this will bump turbo-rails to 0.5.8
  2. yarn upgrade hotwired/turbo-rails
  3. Note: I was using the webpack-dev-server and it needed to be restarted along with the rails server.

/cc @daniele

Yep鈥hat 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鈥檒l likely update the blog soon as well.

1 Like

Thanks @dstull.
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.

@daniele strange.

I have no problems locally on mac.

I even tried rm -rf on the directory locally and starting over. I didn鈥檛 have any issues.

I updated the readme with steps I just ran on a freshly pulled version of now-merged-into-master-updates 路 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鈥檓 curious to know if you鈥檇 still recommend the same approach to handling routing in modals, or if you鈥檇 do things differently?

I鈥檓 using data-turbo-action="advance" attributes on links that open modals to automatically update the browser鈥檚 history. Now I wonder what would be the best way to update it when closing the modal. So far, I鈥檓 using a Stimulus controller to which I pass the URL to visit when the modal鈥檚 close button is clicked. But there might be a cleaner solution that I haven鈥檛 thought of?

Thanks a lot!