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

Need to @click='close' when using links inside modals? #62

Open
netpalantir opened this issue Jul 22, 2023 · 4 comments
Open

Need to @click='close' when using links inside modals? #62

netpalantir opened this issue Jul 22, 2023 · 4 comments

Comments

@netpalantir
Copy link

Hi,

when I am inside a Modal, and there is an (inertia) Link in there, when I click on that link the modal goes away, but only partially: the new view is correctly loaded, but the scroll is still locked and there are some headless-ui dialog elements still present.

If on the other hand I click on the background, the dialog is closed correctly.

I solved this like this (i.e. I simply added a call to close() on click:

...
import { useModal } from "momentum-modal"
const { show, close, redirect } = useModal()

...
<Link class="btn btn-primary btn-sm me-2" :href="`/taget/` + some.id" @click="close">

Is this supposed to happen? Is this the correct way to do it?

Thanks a lot...

@danhanly
Copy link

I'm experiencing this same issue - but oddly only with one of my modals, and I'm not 100% certain why it's occurring on one but not the other.

With my case, my modal has an Inertia Form on it, which upon submission, redirects to a new page. It's on this new page that the modal appears to be still present and active but not showing (locking the scroll of my page).

I'm investigating it now, if I can figure it out, I'll update here.

@danhanly
Copy link

Here are my observations, so far:

It's something to do with the state of the modal not being preserved between page loads. I can replicate it directly if I set preserveState to false on the link (or in my case, the form posting options).

Inertia's docs show the following:

By default, page visits push (new) state (window.history.pushState) into the history

Pushing state means the existing state is preserved and new state is added to the history. So if the modal was closed in the previous state, then that's preserved in the new state, so it stays closed.

However, in some circumstances, I've been able to see that the state is not preserved, but rather it's replaced. This causes the page to render anew and doesn't 'remember' that the modal should be closed.

I've managed to fix it, but it's not the 'correct' fix, but rather just a band-aid solution.

Within my Modal layout, I use HeadlessUI, and I amended it to this:

<TransitionRoot as="template" :show="show" v-if="show">

In addition to the show attribute, I use a v-if to block the render of the modal entirely if show is false.

I'll continue trying to figure out why this is happening - perhaps the expert @lepikhinb can jump in and give some ideas as to why this is occurring.

@danhanly
Copy link

In my case, my form posts asynchronously, so the (async/await) promise wasn't fulfilled correctly by the time the navigation occurred. I restructured so it doesn't post the form asynchronously, and the issue went away.

Because of this, I'd suggest that some things can interrupt Inertia's navigation capabilities, and affect the component state. In my case, it was due to an unresolved promise in my modal, but others may find that other things affect the navigation state.

I've got nothing further to add on it, as my underlying problem has been solved. However, I hope others in future get some value out of my investigation to help solve their own issues.

@vpuentem
Copy link

I'm experiencing this same issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants