[✨] useVisibleTask$ - add IntersectionObserverInit option with 'intersection-observer' strategy

[GrandSchtroumpf]

Is your feature request related to a problem?

I'm using useVisibleTask$ to attach an IntersectionObserver on an element in order to load more item when it's 300px from the viewport :

const LoadMore = component$(() => {
  const ref = useRef<HTMLElement>();
  useVisibleTask$(() => {
    const observer = new IntersectionObserver(([entry]) => {
      if (!entry.isIntersecting) return;
      // loadMore();
    }, {
      rootMargin: '300px 0px'
    });
    observer.observe(ref.value!);
    return () => observer.disconnect();
  }, { strategy: 'intersection-observer' });
  return <div ref={ref}></div>
})

The main issue here is that the first operation happens when the ref is visible which creates a jump.

Describe the solution you'd like

Ideally I would like to set the rootMargin alongside the strategy in the useVisibleTask$ :

  const rootMargin = '300px 0px';
  useVisibleTask$(() => {
    const observer = new IntersectionObserver(([entry]) => {
      if (!entry.isIntersecting) return;
      // loadMore();
    }, { rootMargin });
    observer.observe(ref.value!);
    return () => observer.disconnect();
  }, {
    strategy: 'intersection-observer',
    options: { rootMargin }
  });

This could also help prefetching content a little bit before the element is displayed on the page.

Describe alternatives you've considered

Current I use an eager strategy and ignore first callback from my IntersectionObserver.

Additional context

No response

[gioboa]

Thanks, rootMargin could be a nice addition. I don't understand why, in your Ideal solution, you create the observer inside of useVisibleTask$. rootMargin could be managed by the tasks itself

[GrandSchtroumpf]

@gioboa as far as I understand the intersection observer used by useVisibleTask$ will be disconnected once the element is visible.
In my case I want to keep listening until the data is fully loaded :

1. initialize list with 20 items: the LoadMore is below the items
2. when scroll is 300px above the LoadMore, useVisibleTask$ should be triggered and fetch more items
3. more items are loaded above the LoadMore
4. when scroll is 300px above the LoadMore, the IntersectionObserver callback is triggered and fetch more items
5. Same process until there are no more items to load -> disconnect the observer.

On step 2 the IntersectionObserver used to run the useVisibleTask$ will be disconnected by Qwik, so I need to create another to continue loading more items until there is no more items to load.

[gioboa]

I created this POC https://github.com/gioboa/qwik-infinite-list and it's doing more or less what you described.
So change the framework API only for this use case it's wrong, because we can write a little bit of code and we can keep the framework clean

[GrandSchtroumpf]

Yes, that's more or less what I'm doing but data comes from the server so it takes more time to fetch.
As you can see the first time useVisibleTask$ is triggered, there is a delay before the data is loaded, this is because useVisibleTask$ is triggered with 0 rootMargin. Once the IntersectionObserver takes over, then you don't experience this delay, because the browser has 300px left to fetch and update the DOM.

Also, this is one case, but there are many cases when you want to prefetch / precalculate data just a little bit before the element is displayed.

[gioboa]

rootMargin option seems reasonable to me, it's a good first PR to implement.
What do you think @mhevery ?

[GrandSchtroumpf]

I've taken a look at the code and from what I understand it means to add a property alongside qvisible and update qwik loader

packages/qwik/src/core/use/use-task.ts

 if (eagerness === 'intersection-observer') {
    useOn('qvisible', getTaskHandlerQrl(task));
    // Set IntersectionObserverInit option on a qvisibleoption property
    if (options) {
      const invokeCtx = const invokeCtx = useInvokeContext();
      invokeCtx.$hostElement$.setAttribute('qvisibleoptions', JSON.stringify(options));
    }
 }

packages/qwik/src/qwikloader.ts

const results = querySelectorAll('[on\\:qvisible]');
const observerCb = (entries) => {
  for (const entry of entries) {
    if (entry.isIntersecting) {
      observer.unobserve(entry.target);
      dispatch(entry.target, '', createEvent('qvisible', entry));
    }
};
const baseObserver = new IntersectionObserver(observerCb);
results.forEach(el => {
  const options = el.getAttribute('qvisibleoptions');
  if (!options) return baseObserver.observe(el));
  // create new IntersectionObserver if element has options
  new IntersectionObserver(observerCb, JSON.parse(options));
});

I understand you don't want to add more code to qwikloader especially to create new IntersectionObserver.
Maybe we can optimize by using the same observer if elements have the same qvisibleoption.
Let me know what you think, or if you've got a better solution. I'm happy to do the PR.

[GrandSchtroumpf]

Hello, before I start the PR, I would like to know if the kind of change I suggest above is acceptable on your side. Thanks

[mhevery]

Thank you @GrandSchtroumpf, for trying to help out! Yes, we would love for you to take this on, and I would love to help you along in the process.

Let's go over how this would work. Given:

import { component$, useVisibleTask$ } from '@builder.io/qwik';

export default component$(() => {
  return (
    <div>
      <div style={{ height: '100vh' }} />
      <Child />
    </div>
  );
});

export const Child = component$(() => {
  useVisibleTask$(
    () => {
      console.log('task 1');
    },
    {
      strategy: 'intersection-observer',
      rootMargin: '100px',
    }
  );
  useVisibleTask$(
    () => {
      console.log('task 2');
    },
    {
      strategy: 'intersection-observer',
      rootMargin: '50px',
    }
  );
  return <div>Hello Qwik!</div>;
});

Notice that we have two useVisibleTask$s defined with different rootMargen. We would like to honor the two different options when executing the code. (Something to keep in mind.) The resulting HTML currently is:

<div>
   <div style="height:100vh"></div>
   <div on:qvisible="chunkA.js#_hW[0] chunkB.js#_hW[1]">
    Hello Qwik!
  </div>
</div>

1. So the problem is how do we pass the extra options to chunkA and chunkB. Because if we only pass one option, it will affect both of the handlers.
2. The second problem is when the code is ready to run, we fire a synthetic qvisible, and that would again execute both of the handlers together.

So we need to do something special for the above to deal with this correctly....

Here is my proposal:

<div>
   <div style="height:100vh"></div>
   <div on:qvisible
        q:visible-options="[{rootMargin: '50px'}, {rootMargin: '100px'}]"
        on:qvisible:0="chunkA.js#_hW[0]"
        on:qvisible:1="chunkB.js#_hW[1]"
        >
    Hello Qwik!
  </div>
</div>

• We generate empty on:qvisible so that the existing logic can still work as expected. The attribute may be empty or it may have the default handlers without the options.
• When qwikloader runs and fines on:qvisible attribute it will check if there is q:visible-options attribute. If so it will set up additional IntersectionObservers with those options.
• When the IntersectionObserver fires it callsi dispatch(entry.target, '', createEvent('qvisible', entry)); but this code will then be modified to optionally add :0 or :1 as a suffix to the event if it is non-default value.

---

Not saying that my solution is the best, I am open to other suggestions, but I do think we need to solve the above corner case correctly. Would love to hear your thoughts. Or if you agree feel free to start implementing.

NOTE: this is tricky so we will have to make sure to have tests for this case. (I can help with that if you get stuck)

---

NOTE: The other thing to keep in mind is that as of right now this will only work for the initial render. Once the app is running in the client useVisibleTask executes eagerly. So I don't think you will get the behavior you are looking for. See this example

import { component$, useStore, useVisibleTask$ } from '@builder.io/qwik';

export default component$(() => {
  const count = useStore([0]);
  return (
    <div>
      <button onClick$={() => count.push(count.length)}>+1</button>
      <div style={{ height: '100vh' }} />
      {count.map((idx) => (
        <Child key={idx} idx={idx} />
      ))}
    </div>
  );
});

export const Child = component$<{ idx: number }>(({ idx }) => {
  useVisibleTask$(() => {
    console.log('task idx', idx);
  });
  return <div>Idx {idx}!</div>;
});

The output will be blank, but when you click on the button you will see:

task idx 1

And then when you scroll into the view

task idx 1
task idx 0

Basically the useVisibleTask delays the initial task execution, but only for SSR (not for CSR)

We can have a sepearet discussion about that.

[GrandSchtroumpf]

Thanks @mhevery for the detailed feedback.
Wouldn't this work ?

<div>
   <div style="height:100vh"></div>
   <div on:qvisible="chunkA.js#_hW[0] {}, chunkB.js#_hW[1] {rootMargin: '100px', thresholds: [0, 1]}">
    Hello Qwik!
  </div>
</div>

Ideally we could also let the dev set a rootId that would be the id of the root element from the options, but that could be a second step.

---

Concerning the lazy SSR vs eager CSR, if navigation with Link does trigger useVisibleTask$ eagerly, I might indeed stay with strategy: 'document-idle' and ignoring first callback. But I sill think rootMargin is a good feature to have :)

[mhevery]

Wouldn't this work ?

In theory, yes, but the system is not set up to have extra details like that in on: attributes, so there would be many changes...

Ideally we could also let the dev set a rootId that would be the id of the root element from the options, but that could be a second step.

I like that idea...

[wmertens]

I think this could be a two-parter, first the strict intersection observing and later the parameters.

[mhevery]

I think this could be a two-parter, first the strict intersection observing and later the parameters.

sounds reasonable to me.

[noworry-b-still]

Hello,
I am new to open-source. I would want to start contributing. I am comfortable with TS. I saw this good-first-issue, I didn't understand the solution and the discussion that's happening above. I would appreciate on insights for me on a solution that has been discussed.

[gioboa]

I read all the discussion and the step here are two.

• implement this system here
• expose a rootId property that would be the id of the root element from the options

@lord-cosmos we can start the PR for the first step together. You can DM me on discord

[noworry-b-still]

@gioboa thank you!!

• I have sent request to your id. You may ping me there for further steps.

[gioboa]

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.