🐛 amp-list: Don't wait for amp-bind before first mutate#15613
🐛 amp-list: Don't wait for amp-bind before first mutate#15613dreamofabear merged 4 commits intoampproject:masterfrom
Conversation
| "amp-date-picker", | ||
| "amp-next-page", | ||
| "ampdoc-shell", | ||
| "disable-faster-amp-list", |
| } | ||
| }); | ||
| } else { | ||
| // Skip if setState() has _not_ been invoked yet. |
There was a problem hiding this comment.
nit, comment applies to the else case
|
Won't this break existing implementations? For example, the favicon sample relies on bindings being evaluated when list content is rendered (I thought this was intentional). |
|
It shouldn't break use cases that rely on user interaction since it'll still evaluate bindings in list content after the first |
|
In that case it will break the favourite sample as it relies on bindings being evaluated when the list is loaded. The sample should be easy to fix, but we might break other sites. |
|
@choumx so we can no longer render |
|
Depends on what you mean. If you mean doing something like If you mean doing something like: <amp-list>
<template>
<p [text]="foo.bar"></p>
</template>
</amp-list>Then yes, that won't happen on initial load anymore. |
|
|
|
Is it possible to understand how many sites could be affected by this change before launching it? (e.g. other sites that have copied the model used in the "favorite" sample) If I recall correctly, we intentionally decided to block amp-list render on evaluating bind expressions contained in those amp-lists — will this change undo that? |
Fixes #15311 and fixes #11998. Partial for #15272.
Dramatically reduces initial render latency for
<amp-list>elements on pages that also use<amp-bind>. Looks like ~95% improvement by my simulations onexamples/bind/list.amp.html.A picture of me not thinking things through thoroughly enough:
/to @aghassemi