expose method to get coordinates of a grid item?

[giladgray]

v1 had an internal _getItemStyle(row, col) method on the VariableSizeGrid ref that I used to great effect to implement a spreadsheet selection region. I am looking at v2 and do not see a similar method. would it be possible to expose a first-party (not _'ed) method to solve this use case?

for context, Virtua exposes handy ref methods here: https://github.com/inokawa/virtua/blob/main/src/react/VGrid.tsx#L143-L154

[bvaughn]

Hmm. My initial thinking is that this does not seem like an API I want to expose. The method you’re referring to in the. earlier version of the library wasn’t intended to be public.

I’ll leave the issue up for a couple of days and think about it.

[giladgray]

Haha, I'm aware it wasn't intended to be public, but it was crucial for me. I would strongly urge you to consider making this public in a safe way, like Virtua did. A way to query the size cache would be huge for advanced library developers (like myself).

[bvaughn]

Exposing a public API like that would limit my options regarding positioning of lazily-measured content. I’ve done some experimenting already with estimating their size and offset so as to minimize what I need to measure and how often I need to invalidate the cache, and there is a good chance I’ll do more in this area in the future

Fwiw I think you could probably implement one externally in a few lines as a custom size cache (similar to how I did for dynamic rows). An advantage you would have is the ability to only support deterministic row heights (which I imagine you’d do for a spreadsheet)

[bvaughn]

I've looked at two possibilities for this (#866 and #867) and I'm currently leaning toward the latter. Though it's a bit more verbose than adding an imperative API, I think it keeps the library slimmer for the overwhelmingly common use case.

I don't know if I'll move forward with either though. In my opinion, both approaches involve internal details of the library and will limit my ability to make certain kinds of changes later that I might want to make.

[bvaughn]

I've decided this is not a use case I want to add code to support directly. I think it's too much of an edge case to justify the trade offs mentioned above.

Fixed-height lists are simple. (Just multiple the row index by the row height.)

For variable height lists, I would write a custom hook, e.g.

export function useBoundsCache({
  rowHeightFunction,
  rowProps = {},
}) {
  return useMemo(() => {
    const cache = new Map();

    function getBounds(index) {
      // Lazily fill cache up to the requested row
      while (cache.size - 1 < index) {
        const currentIndex = cache.size;
        const rowHeight = rowHeightFunction(currentIndex, rowProps);

        if (currentIndex === 0) {
          cache.set(currentIndex, {
            rowHeight,
            scrollTop: 0
          });
        } else {
          const previousRowBounds = cache.get(currentIndex - 1);

          cache.set(currentIndex, {
            rowHeight,
            scrollTop: previousRowBounds.scrollTop + previousRowBounds.rowHeight
          });
        }
      }

      // This will be the computed scroll offset and height value
      return cache.get(index);
    }

    return {
      getRowHeight: (index) => getBounds(index).rowHeight,
      getScrollTop: (index) => getBounds(index).scrollTop,
    }
  }, [rowHeightFunction, ...Object.values(rowProps)]);
}

Then you can use it like so:

function Example({ items }) {
  const cache = useBoundsCache({
    rowHeightFunction,
    rowProps: { items },
  });

  return <List
    rowCount={items.length}
    rowHeight={cache.getRowHeight}
    rowProps={{ items }}
    {...rest}
  />

  // ...
}

[giladgray]

thanks for the code sample here! you're right that with the constraints of my spreadsheet use case, it's easy enough to build up the cache locally.

i really appreciate the lengths you went here to consider this proposal. I looked at both those PRs and I can support your conclusion to not provide a first-party API for this 👍