You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm very much liking this package and have successfully implemented except for a few issues.
The first issue is that I'm having to name the form used in the modal differently to an existing form in the base route.
For example, let's say I have an organisation and a contact with the name attribute. When opening the contacts modal, the name seems to be overwritten (at least initially) with the name attribute from the base organisation. I fixed this issue by renaming the form for the contacts modal to contactForm but I'm wondering why it the occurs in the first place.
// Setup method in base route (i.e. 'organisation.edit')setup(){constform=useForm({name: null,})return{
form,}},// Setup method in base route (i.e. 'contacts.edit')setup(){constform=useForm({// issue can be fixed by renaming to contactForm =name: null,})return{
form,}},
The second issue is that I would like to redirect to the previous base route (not the default one) when updated. Doing the following in keeps the modal open:
It's worth to note that the redirect works correctly in this way. So in above example, you are starting from contacts.index and when you open the modal, you navigate tocontacts.edit then post to contacts.update. So when doing back() from the backend, you are actually going to contacts.edit, which is the right behaviour. Changing it to "do move two steps back" would not always be the desired behaviour.
Option 1 would be to instead of going back() from the backend, you redirect to_route('contacts.index') and the front-end will follow suit. This approach would not work well however, if you used the same modal on different pages.
Option 2 avoids this problem, if you specify the redirect action onSuccess: () => window.history.back() for the form submission on the front-end. This however, by its nature going back will NOT update the pagination if your modal trigger button was placed on the index page of contacts in your example.
Option 3 is a bit more cumbersome, but works a treat. You can capture the redirect target in the session in the controller when hitting edit() and redirect to that route from update(), if that makes sense.
This latter approach will take you back to the page from which you have triggered the modal window and will also ensure you are going forward in history, so updates appear as expected. (Note that if you are using pagination as a component, you might need to add the :key property to it, for example :key="contacts.meta.total" in order to trigger the updates.)
I'm very much liking this package and have successfully implemented except for a few issues.
The first issue is that I'm having to name the form used in the modal differently to an existing form in the base route.
For example, let's say I have an organisation and a contact with the
name
attribute. When opening the contacts modal, thename
seems to be overwritten (at least initially) with thename
attribute from the base organisation. I fixed this issue by renaming theform
for the contacts modal tocontactForm
but I'm wondering why it the occurs in the first place.The second issue is that I would like to redirect to the previous base route (not the default one) when updated. Doing the following in keeps the modal open:
Is there anyway of determining what the current base route is so I can redirect to it without having to close the modal from the frontend?
I did see some responses in #29 that may help with this...
The text was updated successfully, but these errors were encountered: