nextTick is unreliable

[ludwig-gramberg]

Hi,
I'm breaking my brain trying to have reliable scroll behavior after alpine is finished with applying changes.
I was expecting that $nextTick fires when all changes are applied to the DOM. But it regularly does so before (or so it seams).

In my example a <ul> is made visible with x-show once it has elements. The following are screenshots of the Chrome console when the mutations are observed and then the nextTick callback fires.
The result is that a scrollIntoView does not work because the element is not actually visible yet.

Single Mutation observed after $nextTick:

All mutations observed before $nextTick:

Video of different behaviors (only to be observed after a fresh page load).

Sample-Code:
https://awesomealpine.com/play?share=m2SSM1_7XKEt

In Case the Sample is no longer online:
JS:

Alpine.data('component', () => ({
  other: {
    x: 0,
    y: 1,
    z: 2,
  },
  items: [],
  init() {
    //return;
    const observer = new MutationObserver(this.observe);
    observer.observe(this.$root, {
      attributes: true,
      childList: true,
      subtree: true,
    });
  },

  observe(mutations) {
    console.log(mutations);
  },

  add() {
    console.log('add clicked');
    fetch('/').then(() => {
      console.log('fetched');
      // simulate some deferred event, such as fetch etc.
      const some = (Math.random() + 1)
        .toString(36)
        .substring(7);

      this.items.push({ key: some });
      this.other.x++;
      this.other.y++;
      this.other.z++;

      console.log('data was set');

      this.$nextTick(() => {
        console.log('ticked');

        document
          .getElementById('item-' + some)
          .scrollIntoView({
            behavior: 'smooth',
            block: 'center',
          });
      });

      console.log('end of fetch');
    });
  },
}));

HTML:

<style>
  #component {
    margin-top: 500px;
  }
  #space {
    margin-bottom: 1500px;
  }
  li {
    background-color: #ccc;
    min-height: 200px;
    margin-bottom: 10px;
  }
</style>
<div
  x-data="component"
  x-cloak
  id="component"
>
  <button @click.prevent="add()">add</button>

  <div id="space">
    <p x-text="other.x"></p>
    <p x-text="other.y"></p>
    <p x-text="other.z"></p>
  </div>

  <ul x-show="items.length > 0">
    <template
      x-for="item in items"
      :key="item.key"
    >
      <li
        x-text="item.key"
        :id="'item-'+item.key"
      ></li>
    </template>
  </ul>
</div>

[ekwoka]

I think this is specifically an issue with scroll into view.

That the Dom is updated (like you did get the item when querying for it), but since the browser has not fully painted it doesn't know what exactly is in view or not.

Without just making nexttick arbitrarily slower, there isn't much that can be done.

You can just nest nexttick calls.

await this.$nextTick(this.$nextTick)

To wait for another frame.

The updates to the DOM are always available after $nextTick

[ekwoka]

So, in my case, the second one (for removing the hidden styling from the x-show) still happened before the tick.

But that Safari at least had itself not processed that the thing was scrollable to (due to its own ideas about layout) or was rejecting it because Safari is tricky about scrollIntoView quite often (Sometimes I've had to do a small scroll of 1 pixel with scrollY += 1 and THEN to do the scrollIntoView).

For your specific case shown in the playground, what you would actually most want to do is put an x-init on the child element from the template with THAT scrolling it into view. That would give the most stable solution.

If that is still too unstable, you might need to manually do the appropriate scroll change without the "intoView" helper, to tell it exactly where to scroll to. Doing that should also force the layout to be updated if the browser was still otherwise trying to avoid layout thrashing.

[ludwig-gramberg]

The MutationObserver is serving me well. So far across all browsers.
x-init would also only serve one usecase and it would not be reusable.
Perhaps in a future version of alpine it could use the MutationObserver itself to verify when changes had been applied by the browser. If that would even be feasible.

[ekwoka]

This is a very specific use case that doesn't much a ton of sense to actually go that route.

[ludwig-gramberg]

This is a very specific use case that doesn't much a ton of sense to actually go that route.

And its also unreliable. On Safari I did not get some of the mutations reported to the observer although they did happen.

[ludwig-gramberg]

Update: I added a ResizeObserver as a second observer, because when stuff becomes visible usually the height of something changes... why is this so hard?!