With version 8, the stackPages feature has been removed. I would like to use this feature in a project I am developing. Why was stackPages feature removed, and what alternative method can be used instead?
2 Likes
@nolimits4web I am currently starting a new project, and would like to use V8 as well. (My last project was on v7)
What is the new ābest practiseā as replacement for the removed stackPages parameter? Previously I used stackPages to handle forms over multiple pages, and for example keep list positions on multi-level list pages.
The migration guide lists this. I use single file router components already as long as they exist, but I donāt understand the connection with stackPages.
Removed stackPages functionality in router that allows you to load pages from existing DOM elements, and keep previous pages in DOM. It is recommended to use Router Components instead
Well when you load components into the router ie : import MyComponent from mycomponent
then in the route use component: MyComponent in your route, the component is loaded immediately even if not routed.
Iāve never used stackPages so Iām sure what youād be missing, but if you are looking to preload pages and keep them loaded, you can do so with the router+component method.
Yes this the way I work with components. But image this scenario:
- User navigates from homepage to an event calendar, swipes a few months, and clicks on a particular event.
- The event details are shown. User clicks on a button to next page to reserve places for the event, possibly two-step form.
- Now when you navigate back to the calendar view, it is reloaded en does not keep the state as it was left. E.g. with selected month or dropdown with filter set.
Previously you could just set stackPages to true, and all pages with itās state were kept in history >2 steps back.
Ahh I see, yes because the router only keeps 2 pages, and even though the component is loaded itāll rerender it if past that.
I would imagine stackpages could really make things clean and easy for simple applications, or potentially make things sluggish on more complex apps, could be easily abused to the UX detriment.
Have you considered using popovers instead? In one of my apps, there are many layers like you suggest to a single module, so from the main ācalendar viewā you may wish to use popover with property push instead. This has the benefit of helping the end-user feel like they didnāt lose their place and could easily click back to it by possibly swiping down or clicking backdrop at top.
If you want the popover routable, thats possible too, though can take a little extra effort to ensure the layers all load as intended when a direct route / link is used.
If not this, then maybe make your next button load your two step form, but consider the two step form to be ONE view with maybe fullview Swiper to implement the steps.
granted annoying to lose a feature when it worked perfectly well for you, but I would imagine it had to do with tightening up the router.
Thanks for your suggestions. Yes I can think about several workarounds, but I have built several apps and stackPages worked so great. Indeed it is a possible reason for sluggishness, but I was just used to attach/detach event handlers and stop/start animations where needed.
It is recommended to use components logic instead. For example you can cache somewhere results of the forms on previous pages (e.g. in store) and then re-populate the form from that data
1 Like