Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TBD: Consider using mutation events to rebuild some of the AMP elements #1014

Closed
dvoytenko opened this issue Nov 25, 2015 · 2 comments
Closed
Assignees
Milestone

Comments

@dvoytenko
Copy link
Contributor

We are running rarely into issues when the composite AMP elements have their build method called when their children list is in complete. E.g. an amp-carousel may have 10 slides total, but it's build is called only when its children reports only 2 subelements. A symptom of this problem can be seen in #983. To observe the issue, you can also see http://jsbin.com/folura/edit.

We currently use three signals to build most of these elements: attachedCallback, upgrade and DOMReady. We build as soon as at least one real child is available, assuming that all children are already there. This causes problems.

Thus, we have three options:

  1. Defer building these elements until DOMReady
  2. Build these elements as we do now, but further rely on mutation events to do additional incremental builds.
  3. A compromise where we would proceed as currently, implement rebuildCallback and element visibility whitelisting as described below. But instead of using mutate events, we will simply wait for DOMReady to run rebuilds.

This will look as following:

  1. We will call buildCallback in the element as we do today.
  2. The element will do the initial build
  3. The element will apply styling that will state: "display:none all my children except those whitelisted explicitly". E.g. .-amp-composite > *:not(.-amp-composite-allowed) {display: none}. This will ensure that newly added nodes do not show immediately and give the element chance to reconfigure them.
  4. The element will also return the mutation config, e.g. {childList: true}. This way the element will say: "I'm built but I'm also interested in getting the following mutation events".
  5. The runtime will subscribe via MutationObserver and will polyfill it partially where needed.
  6. The runtime will mark an element that receives mutation events as "toRebuild"
  7. In next cycle, the runtime will call the element's rebuildCallback method and reset "toRebuild" flag.
@adelinamart
Copy link
Contributor

Is this still relevant?

@dvoytenko
Copy link
Contributor Author

No. Build cycle has been redone my @mkhatib to wait for full DOM construction for an element.

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

No branches or pull requests

3 participants