Fast Element lifecycle

[miroslavstastny]

I have a question related to the lifecycle for Fast Element (version 2.0.0-beta.20) - I have read The element lifecycle section in docs, but it does not provide any details on method call order.

Use case

1. I have a web component (popover) which has boolean open attribute.
2. Based on that attribute, it conditionally renders an element inside its template.
3. There is a ref on this conditionally rendered element (spanRef member attribute).

Now I need to programatically position the conditionally rendered element when it is added to DOM.

My original idea was to access that element in openChanged method, but at that moment, the spanRef is not set yet. This is kind of expected.

My next attempt was to call Updates.enqueue() inside openChanged(), but even there, the element still does not exist in DOM and the spanRef is not set.
❓ Is this expected?

The next idea was to annotate the spanRef as @observable. With that spanRefChanged() is called. There are two surprises with this:

1. If the web component is mounted with the open attribute set (<my-component open></my-component>), the spanRefChanged() is called before connectedCallback().
2. If the value of the open attribute changes to false, it spanRef is never cleared and the spanRefChanged() is not called. This is especially confusing for any React developer where a ref is cleared on its component unmount.
   Also when the open is changed again to true the original DOM element is re-used.
   ❓ Is the spanRef not being cleared an expected behaviour?
   ❓ Is the DOM element being reused guaranteed?

Based on the observed behaviour, I need to call the positioning functionality from three different places:

1. connectedCallback() - if the web component was mounted with open set to true,
2. spanRefChanged() - on the first open, if the component was mounted with open set to false,
3. openChanged - on any subsequent open.

Repro

To test the behavior, I've created a stackblitz sandbox here: https://stackblitz.com/edit/vitejs-vite-dhhejl?file=src/main.ts.
It allows to mount the component either initially open or closed and delete the component.
The lifecycle method calls are logged to the page and console.

nit: Another surprising fact was that openChanged method is first called before class constructor. When I realize that is implemented using a setter/getter on the open field which uses a class field initializer, it makes sense, but still might confuse someone.

[nicholasrice]

My next attempt was to call Updates.enqueue() inside openChanged(), but even there, the element still does not exist in DOM and the spanRef is not set. ❓ Is this expected?

This is expected. When observable detects a change to an observed property, it first notifies the fooChanged() method if it exists on the source, then it notifies any subscribers. The template bindings use the subscription APIs so they are notified (and the view created / bound) after your openChanged() method is invoked.

❓ Is the spanRef not being cleared an expected behaviour?

It is expected, though I can appreciate the confusion. The behavior doesn't implement any behavior when it gets unbound to clear the property assignment.

❓ Is the DOM element being reused guaranteed?

It depends on how the template was written, but generally the element is re-used. When the View unbinds, the elements that exist in it are moved to a DocumentFragment. When / if it is rebound, those elements are re-inserted at the binding target. If a template is written where a new template is returned from every evaluation of the binding, a new View will be created for every ViewTemplate instance and there won't be re-use of the elements:

const myTemplate = html`...`'
when(x => x.test, () => myTemplate);

// vs

when(x => x.test, () => html`...`);

This is great feedback. I think one option here might be to open up a configuration on ref so that it assigns the property undefined when the behavior unbinds.