Skip to content
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

Support for explicitly specified row heights #122

Closed
telamonian opened this issue Mar 30, 2021 · 1 comment
Closed

Support for explicitly specified row heights #122

telamonian opened this issue Mar 30, 2021 · 1 comment
Labels
enhancement Feature requests or improvements

Comments

@telamonian
Copy link
Contributor

telamonian commented Mar 30, 2021

Feature Request

Description of Problem:

As per the conversation here, one interesting feature that @lumino/datagrid has that regular-table is currently lacking is support for explicitly specifying row height.

For at least some set of possible "fat" rows (eg double-height, img with set height, etc), it seems reasonable that the <regular-table> author would know in advance what the "height anomaly" would be for a given row. It would be neat if we could support this use case.

Potential Solutions:

The ideal solution would allow for:

  • correct calculation of virtual scroll position, such that there is parity in behavior, thumb size, etc between the virtual scrollbar of a <regular-table> and the scrollbar of an eagerly rendered vanilla <table>
  • preservation of current regular-table virtual rendering, in which only the for-real visible rows get rendered

As implemented in datagrid, the idea is that you can deal with the various complications introduced by variable row height in O(n) time, where n is the count of rows with custom heights that are affected by a given operation (eg see here). For rendering, n would only be the count of currently visible non-default-height rows.

Non-solutions:

This feature is distinct from the bug discussed in #96, whereby if any row is larger than the default 19px it causes the breakage of the calculation of number of rows to render. The solution for #96 just has to prevent the complete breakage of an affected <regular-table> (eg it doesn't have to completely fix the virtual scroll behavior, etc). Also hopefully there will be a reasonable solution for #96 that won't require explicitly known/specified heights

@timkpaine
Copy link
Member

#191

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests or improvements
Projects
None yet
Development

No branches or pull requests

2 participants