fix: scroll to anchor after dom mutations

[nileshgulia1]

A quick fix to #13

[erral]

With the tests I have done I don't see that this fixes the issue, nevertheless I think I have a workaround:

can we change the waitForElm, to resolve the promise after all the mutations have been observed?

something like this:

export const waitForElm = (selector) => {
  return new Promise((resolve) => {

    const observer = new MutationObserver((mutations, obs) => {
      obs.disconnect();
      if (document.querySelector(selector)) {
        return resolve(document.querySelector(selector));
      }
    });

    observer.observe(document.body, {
      childList: true,
      subtree: true,
    });
  });
};

This way we do not try to find any item in the DOM until all mutations have finished, which is the case in the bug: the heading is present in the HTML (it comes after an accordion), but the accordion is expanded after the page has been scrolled to the heading.

This way we wait until everything is loaded, and the we scroll to the heading.

We will need to test if this works with Listings or some other kind of block that would be in the middle...

[nileshgulia1]

I agree to skip the early resolve of promise if that solves your use case!

[erral]

Mmm, this doesn't work. We need to wait until all mutations are finished and when we disconnect the observer, we lose track of the other mutations.

I will keep investigating the issue.

[erral]

@nileshgulia1 I have been investigating our issue, and it looks like it is unsolvable.

The point is that we can't detect when all MutationObserver events are produced. We can react each time there is a Mutation but we can't know when all of them have happened, which is what we would want to know.

If we remove the obs.disconnect() line from the code above and add a console.log to log the mutations, we can see that there are a lot of them in our case, and we want the scroll to happen after all of them but that's not possible.

So I would leave the code as it is and find another solution in our case (perhaps wait for some time before scrolling, or whatever).

[nileshgulia1]

Probably I don't have that much unique use case, I will try to test it with some more complex cases.

[avoinea]

@nileshgulia1 @erral What's the status of this one? Please convert it to draft if it's not ready for review/merge.

[erral]

Yes, this needs to be converted to draft