RFC: update the client visible directive to track actual visibility

[okikio]

• Start Date: 2022-06-24
• Status: Draft

Summary

RFC that updates the client visible directive's default behavior to track actual visibility, while also leaving the option for devs to opt-out and return to the older intersection-only behavior.

This RFC ensures, that components with client:visible only hydrate when they are actually visible (in all the senses of the word), e.g. meaning if the component is obscured by another element then Astro won't load it, or if the component is made invisible via either opacity or visibility, then the component won't hydrate.

Links

• Full Rendered Proposal

[okikio]

Maybe, rename client:visible="intersection-only" to client:in-view and rename this new behaviour to client:visible

[isaac-mcfadyen]

So one of the interesting things on the Chrome details page states this (emphasis theirs):

Visibility is much more expensive to compute than intersection. For that reason, Intersection Observer v2 is not intended to be used broadly in the way that Intersection Observer v1 is. Intersection Observer v2 is focused on combatting fraud and should be used only when the visibility information is needed and when Intersection Observer v1 functionality is therefore insufficient.

This suggests that it shouldn't be default (client:visible is often used as a quick optimization and users may use it without understanding any potential performance/battery impact). Perhaps, rather than opt-out, it should be opt-in with a flag such as client:accurate-visible or client-expensive-visible?

[steveninety]

This is great! I would mimic intersection observer V2 by placing a component 1px out of the viewport, then toggling a class to bring it back into the viewport when I wanted to hydrate it. Seems like that workaround is no longer needed :D

[natemoo-re]

Thanks for the proposal, @okikio! Sorry we've taken such a long time to address this.

I'm going to close this as we're planning to move forward with Custom Client Directive in #529 which will address this use case.

[okikio]

Yes!!! Custom Client Directives would more than handle this