-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Expose cached offsets and heights #278
Comments
I think the structure of CacheSnapshot should be public and stable in some day but it's not ready yet. For example, I'm planning to replace the offset cache with better data structure for performance. If that suceeded, that may break some user implementations if public. To address the real sticky problem, the Virtua is designed to calculate visible range filling viewport and extend it with |
@inokawa Thanks for the feedback! Have you verified that a I can kind of fake it by creating a fixed-height container within the custom const Item = forwardRef<HTMLDivElement, CustomItemComponentProps>(
({ children, style, index }, ref): ReactElement => (
<div ref={ref} style={style}>
<div style={{ height: 20 }}> {/* The virtualized item will be this height */}
<div style={{ position: 'absolute', height: 700 }}> {/* The sticky content will scroll within this box */}
<div style={{ position: 'sticky', top: 0 }}>
{children}
</div>
</div>
</div>
</div>
),
) In any case, the vanilla version of this still only enables "global stickiness" instead of "ranged stickiness". Meaning we can set a "top: X" but if we don't know the offset of the next sticky header we can't set a "bottom: Y". That means all the sticky items will simple stack on top of one another (like the tanstack example) rather than "moving out of the way for one another" (like the virtua example). If Virtua doesn't offer an API for items to know the position of other items, I suppose the best solution would be inspecting the DOM, and hoping the component is updated when cached positions change to re-calculate the DOM positions. |
I checked your branch again and read your comments, I understood what you meant, trickiness of positioning of sticky items and the difference of "global stickiness" and "ranged stickiness". Probably adding |
|
Is your feature request related to a problem? Please describe.
VListHandle
exposes acache
object with really useful details about the virtualized rendering — but unfortunately the keys are obfuscated in production and theCacheSnapshot
type is opaque. I think there are valid use cases for consumers to access this data and would love to see it exposed in a way I know I can rely on.One example use case — true sticky items.
Virtualization makes
position: sticky
challenging, because the sticky element may get scrolled outside of the rendered range and disappear. The official Sticky demo skirts around this with pseudo-virtualization — each group is virtualized to ensure that the header will always be rendered. However this creates limitations, such as making it impossible toscrollToIndex(...)
on any particular row (#241).However, if we know the virtual position of all the rows, we can actually have true sticky headers by rendering them next to the virtualized items. I've got an example in this branch — load it up in Storybook and you can see that to the user it looks exactly the same as the official Sticky demo. But now, each row is individually virtualized, meaning we can be more efficient with our overscan and use imperative functions like
scrollToIndex(...)
as expected.However, this technique relies on grabbing offset data from the cache. I feel hesitant doing that, especially when in production it's clearly not meant for human consumption.
Is there any reason not to expose the inner data of
cache
so we can rely on it? Thanks!Describe the solution you'd like
VListHandle.cache
should not have its keys obfuscated in production, and should have transparent types and documentation.Describe alternatives you've considered
We can already use the data in
VListHandle.cache
— but since it's not exposed to users I don't know if it's safe to assume it will always be available in that format.The text was updated successfully, but these errors were encountered: