Weāre trying to allow users to navigate between pages within a form but are running into a few issues, the URL structure is something like:
/contact/
/contact/page2/
/contact/page3/
(This is an example, the form in question isnāt a contact form )
Within WP the initial /contact/ page has been created but these āsub-pagesā havenāt. Iāve created a handler which will load the page data from the initial /contact/ page, accessing these pages directly works fine but when a user clicks back/forward in their browser weāre noticing within our Theme component, the router link is āundefined/ā and as such returns no data required for the page e.g. Yoast, ACF, etc.
Currently when a user navigates to the next page of the form weāre using history.pushState:
let slug = "page2"; // Slug is created based off the current page the user is viewing
window.history.pushState({ data: [..] }, 'Page Title', `/contact/${slug}/`);
Weāve toyed around with both popstate and beforeunload window events to try and capture this but they seem to either get called too late (if at all) within these events weāve tried manually setting the router:
actions.router.set("/contact/page2/");
But still have the same issue. Iām probably missing something super obvious here, but Iām not really sure whatā¦
Ideally weād like to just re-render the form with the new page instead of loading an entirely new page.
Iāve never had to deal with handling back/forward browser actions before so figured pushing these pages into the history would have been an easier way to manage moving between pages & refreshing pages so the user will land back on that page.
Iām open to suggestions, nothing is set in stone.
Itās hard to diagnose this without knowing more details
If you are using actions.router.set("/contact/page2/"); then the link should definitely not be undefined anymore!
Would you be able to provide a codesandbox example based a link to a site with the problem that you described or a short video illustrating the problem?
Could you post the code from your form component where you use your form?
Is there any error in the console in when the user navigates backwards/forwards?
Could you also try to add a breakpoint on the popstate browser event and see if by any chance the state.link inside of that event is null or undefined when you try to navigate back / forth?
@chris I guess what you want is all those Frontity URLs (/contact/, /contact/page2/ and /contact/page2/) pointing to the same WordPress URL: /contact, right?
Thatās not something that can be done in the current version of source but we are working on a new version where that configuration will be possible.
Since we get to that point, my recommendation is to stick to a single URL and save the progress of your form in the client using localStorage, including the subpage the users are currently in. That way, if the user refreshes the page, it will be in the same place where they left off.
Youāve hit the nail on the head, thatās exactly what weāre trying to do.
Weāre already using sessionStorage to store the data so we can load it when the user refreshes. Weāve already got back/next buttons within the form but a new requirement that has arisen is to tap into the browser actions so when the user hits the back button, theyāre brought to the previous page within the form and not the last page they visited.
Hence why I thought the initial theory of pushing items into the history would have been an easier way to manage this.
Fortunately weāve managed to figure out the errors in my previous post, turns out I was trying to access a property within the state object before it had finished fetching - a quick check with isFetching solved it.
Now Iām trying to figure out an issue with the form not re-rendering when properties within the Frontity state are changed - this is almost definitely me doing something dumb rather than an actual Frontity issue though.
If you do that, I think you can use actions.router.set and forth and the browser back/forward button should work.
The problem with that approach is that the SSR of the /contact/page2 URL will return a 404 because it doesnāt exist on your WordPress but you can create empty pages that match those URLs.