Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert existing modals to use turbo frames #401

Conversation

spaghetticode
Copy link
Member

This complements solidusio#5674 by converting previously existing modals to turbo frame/turbo stream page refresh.

Unfortunately, this PR cannot be opened in the main Solidus GH space, as the first PR is coming from Nebulab, so this PR aims to preview the changes to be done to the existing modals.

Previously, all flash messages were showing with the same (black)
background. Internally, the flash object converts and stores keys
as strings [1].

[1] https://github.com/rails/rails/blob/main/actionpack/lib/action_dispatch/middleware/flash.rb#L163
@spaghetticode spaghetticode force-pushed the spaghetticode/admin-new-tax-category branch from efc79a7 to 5584f93 Compare March 7, 2024 09:37
@spaghetticode spaghetticode force-pushed the spaghetticode/convert-modals-to-turbo-frames branch from 5425f5b to edef9ab Compare March 7, 2024 09:38
…n-flash

[ADMIN] Fix flash messages coloring
…w-tax-category

[Admin] Create new Tax Categories
We can remove all this custom behavior since we want the modal to
be rendered async on top of the current page.
This way, the modal can be loaded async into the current page.

Please note that the order page rendering, which is discarded on
turbo-frame calls, needs to be moved to the bottom, as it includes
an empty turbo frame tag with same ID that would interfere with the
modal rendering.
The `respond_to` block is required to make Turbo frames and streams
work.

With this change, the order edit modal can be rendered async on top
of the calling page (order edit). Form submission, when successful,
triggers a turbo stream page refresh, updating contents (namely the
order email) while preserving the scroll position.
URLs for editing addresses are handled via turbo frames, enclosing
the modals inside their appropriate turbo frame tag addded on the
page.
Just like we did a few comments before with the order email modal.
`Turbo.visit` already supports turbo frames, so we just need a way
to pass the information from the table HTML to the `visit` call.

This implementation, although arbitrary and possibly questionable,
has the merit of being simple, meaning that enabling turbo frames
in a table row requires just to update the URL to include the
`_turbo_frame` param. This param is removed from the URL, so it
won't have any possible further side effect in the application.
This leverages the new functionality from the previous commit.

Also, adds the turbo_frames list to be injected into the component
view.
Since the modal open and closes on the current page, close links are
not needed anymore. Same goes for the explicit q and page params.

The `Cancel` button is simplified to use dialog standards.
Separated from the previous commit for easing reviews.
With the modal managed via turbo frame and turbo stream refresh,
all this custom explicit params management is not needed anymore.
@spaghetticode spaghetticode force-pushed the spaghetticode/convert-modals-to-turbo-frames branch from edef9ab to b3b0e2c Compare March 11, 2024 08:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant