Polymer: is="dom-*" elements that "hydrate"

Created on 30 Dec 2015 · 12Comments · Source: Polymer/polymer

_Filing this as a master bug to track potential work._

Problem

First paint improves quite a bit when meaningful markup is provided in light DOM at page load. It removes any dependency on slow loading imports/scripts which could delay element upgrades, and therefore delay FP. We offer <template is="dom-*"> elements for generating dynamic markup from data. These elements are simple to use but suffer from the same issue. They hide content until script runs and elements upgrade. It would be awesome to provide an alternate fast-path solution for advanced users that hydrates rather than hides markup behind a <template>.

Take the following examples. First load of these apps are at the mercy of a fast connection.

<link rel="import" href="elements.html" async>
<body>
  <template is="dom-bind">
    <h1>My blog</h1>
  </template>
</body>

<link rel="import" href="elements.html" async>
<body>
  <my-app title="My blog"></my-app>
</body>

In both examples, "My blog" doesn't paint until my-app.html is loaded, Polymer has bootstrapped the templates, and relevant elements have upgraded.

Solution: leverage more light-dom, lazy bind, hydrate data elements from children, etc.

Instead, it's advantageous to use markup and leverage the fact that element upgrades are progressively enhanced markup. Instead, the page can render critical markup instantly at page load time without being hindered by connection. A light-dom enabled element like <body is="dom-body"> can still provide features like data binding by hydrating its light dom with polymer features.

"My blog" paints instantly:

<link rel="import" href="elements.html" async>
<body is="dom-body">
  <h1>My blog</h1>
  ...other components...
</body>

Similarly, a non <template> version of dom-repeat could seed its data model from an initial set of light-dom children. The advantage is that the list renders instantly b/c the markup is there at page load time (either from dynamic content from the server or a static page). For future updates (sorting, items changing, etc.), you still control the items with a data model. I've implemented this setup for our codelab frontend and it works great and is super fast.

<link rel="import" href="elements.html" async>
<body>
  <ul is="dom-repeat" from-lightdom>
    <li>item 1</li>
    ...
  </ul>
  <script>
    // Optionally. Provide server's real data for later.
    // A from-lightdom attr would ignore this set until items are changed later.
    document.querySelector('ul').items = [/*real data model from server*/];
  </script>
</body>

I have a a couple of demos of these techniques here: https://polymerfast.appspot.com/

Two quick prototypes I think we can implement:

[ ] <template is="dom-bind"> -> <body is="dom-body"> (already in labs, but needs final polish and moved into core)
[ ] <template is="dom-repeat"> -> <div is="dom-repeat">

fast path p2 performance wontfix

Source

ebidel

👍16

Most helpful comment

For everyone that cares about this issue, please "+1" the first comment with github's new reactions! I'd like to remove the other comments :)

ebidel on 11 Mar 2016

😄2

All 12 comments

:+1:

<body is='dom-body'> making it into Polymer core would make my day! Allowing me to have data binding, as well as control of elements :unresolved render state, sign me up!

/sub

jshcrowthe on 25 Jan 2016

@kevinpschaaf is the big dog now! Pinging to land dom-body in master.

We have a couple of apps already using dom-body and proving its value and speed over <template is="dom-bind">. I'd also like to switch the IO web app over to using it. @robdodson was also building something based on it.

Benefits: leverage more of the platform (:unresolved, markup up front for fast paint) while still retaining Polymer features.

There were a few concerns about adding more imports....

the refactoring in https://github.com/Polymer/polymer/tree/standard-layer is a good thing. You've refactored the imports in a logical way and it allows power users to load fewer elements when they don't need them.
all that stuff was already being loaded. It's just a refactor.
Adding duplicate imports is fine. URL de-duping takes care of the extra imports in Chrome when you're dev'ing.
Serious apps vulcanize. 1-3 are really moot.

ebidel on 25 Jan 2016

/sub

leodido on 22 Feb 2016

/sub

MeTaNoV on 22 Feb 2016

hehe, y'all there's a subscribe button! ➡️

screen shot 2016-02-22 at 6 57 02 am

robdodson on 22 Feb 2016

👍1

@robdodson notification is one point, but by adding a comment, they are categorized in "Participating" which is why (at least for me) I do this...

MeTaNoV on 22 Feb 2016

@MetaMemoryT I get email notifications with just clicking on the subscribe button.. I guess you have to set this up in your settings

sandro-k on 22 Feb 2016

@sandro-k @nylki Again, in my settings "Watching" is configured for me as only Web and "Participating" as both. Since I already watch the repository, I am already receiving notifications, but I want some to fall in the "Participating" category, that's why I do such comment...

MeTaNoV on 22 Feb 2016

For everyone that cares about this issue, please "+1" the first comment with github's new reactions! I'd like to remove the other comments :)

ebidel on 11 Mar 2016

😄2

I know I +1'd the idea a long while back, but I want to kind of bump this and remind your team how helpful a feature like this would be for me. I have a couple of web applications that are rendering their templates on the server to generate HTML, and we are using Polymer as a way to 'accomplish' more with HTML tags, rather than writing UI components that 'mount' or render into a div (like you would have to do using jQuery UI or React). The declarative, native HTML-like nature of web components and polymer, and being able to simply put a tag on the page in order to use a UI component, makes it an optimal candidate for our architecture, but currently it takes a good bit of 'glue' to update any sort of list type of structure that was rendered using a server-side repeat. Seeding the client-side model for a dom-repeat from data rendered initially in a server-side template would make our lives significantly better...

joineral32 on 19 Jun 2016

@tjsavage @kevinpschaaf can we include this in Polymer.next planning?

ebidel on 19 Jun 2016

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.