Skip to content
This repository has been archived by the owner on Sep 28, 2019. It is now read-only.

Pages are restamped over and over #10

Closed
ronnyroeller opened this issue May 3, 2016 · 6 comments
Closed

Pages are restamped over and over #10

ronnyroeller opened this issue May 3, 2016 · 6 comments

Comments

@ronnyroeller
Copy link

I've two pages:

<iron-lazy-pages attr-for-selected="name" selected="[[_selected]]">
  <template is="iron-lazy-page" name="list" path="list.html">List</template>
  <template is="iron-lazy-page" name="detail" path="detail.html">Detail</template>
</iron-lazy-pages>

When the user toggles between the two pages, my pages are restamped each time. This is especially tricky if a page holds state (e.g. load data from the backend or stay on a specific tab within the page).

Is there a way to activate the dom-if behavior (https://www.polymer-project.org/1.0/docs/devguide/templates.html#dom-if)?

  • Only hide the deactivated pages once they are stamped.
  • (Potentially) explicitly request restamping via the restamp property.
@TimvdLippe
Copy link
Owner

Thank you for the feature request!

This was actually by design, to leverage the vastness of the dom with a lot of pages. I am not sure what the effect would be when designing a hybrid version between this element and the iron-pages. An opt-in mechanism is something I would support, but it might be tricky to implement. I will try my best to tinker with the idea.

Lastly I would be very interested in what others think of this feature. Is this a highly-requested feature or a one-time usecase? Just to know if it is worth to implement this extra feature for the added complexity + payload.

@ronnyroeller
Copy link
Author

Thanks for sharing your thoughts, Tim.

It would be interesting to understand better the use case for which you build iron-lazy-pages as it might just be different from how we use the element.

Here is why/how we use lazy loading of pages:

  • We have ~10 relatively heavy pages on the top level of the application. A user visits typically 3-5 of these pages in a session. We care about initial startup performance especially on slow mobile devices.
  • Each page contains its own state. For example: a page with a tab bar knows itself which tab is selected, i.e. we don't hold such state centrally. Similarly, each page loads data which it caches locally.
  • We shard the application to load only the pages that the user really needs.
  • We use iron-lazy-pages (we used before iron-pages and dom-if) to trigger the loading of the shards and the switching between the pages.

I'm not sure if this matches the use case that you had in mind when building the element. If yes: Which pattern do you suggest to keep page-level state (e.g. which tab on the page is selected or cache loaded page-level data)?

PS: We took a lot of inspiration from the guidance on recommended usage of conditional templates (see below the code example): https://www.polymer-project.org/1.0/docs/devguide/templates.html#dom-if

@TimvdLippe
Copy link
Owner

After a quick discussion in Slack and the documentation, I think it is fair to add this feature. The only doubts I have is for the default behavior. If we change it now to non-restamping, it might break user application relying on this fact. But bumping to 2.0 for this element is imo not wanted either. E.g. I do not know what the consequences are for changing the behavior at this point. However, I doubt very many users use this element just yet, so maybe the small subset that does rely on the behavior is managable.

@ergo
Copy link

ergo commented Dec 1, 2016

Hello, Actually i wanted to test this element and in my opinion it should restamp elements by default - or at least have this as an option.
Hidden element should be destroyed and navigating to it again should yield "fresh" state.
Let's assume I build an element with iron-ajax that auto fetches some data on when element is created. I would expect it to fetch my data on every navigation by default - at least in my use case.

@TimvdLippe
Copy link
Owner

@ergo You can set restamp to do exactly what you want 😄

@ergo
Copy link

ergo commented Dec 1, 2016

Thanks, for some reason i missed this in the documentation, i thought it is default behavior :-)

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

No branches or pull requests

3 participants