You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There isn't a way to style the table to show all rows without a scrollbar unless you happen to know the pixel height in order to achieve that with your data set.
With the upgraded version of TanStack that will come when #1617 is resolved setting height: auto on the table renders no rows. There are a few workarounds that can be applied in the CSS for this, but even with those workarounds (or before the TanStack upgrade), a table with height: auto is extremely inefficient for the browser to render and can cause the browser to hang if the table is too large. This is because the table re-renders for every overscan number of rows set in the table's virtualizer. Currently, the value of overscan is 3, so the table will render with 0 rows, 3 rows, 6 rows, 9 rows, etc until all rows have been rendered.
💁 Proposed Solution
I don't have a concrete proposal, but here are a few possible ideas along with their limitations:
Disable the virtualizer
We could have a mode on the table to disable the virtualizer. Then a client could set height: auto and have the browser be able to render a single time with all the rows rather than re-render for each overscan number of rows. However, this doesn't account for styling that limits the height of the table (e.g. height: auto; max-height: 700px). In that case, the virtualizer still needs to be utilized to ensure that a large number of rows that can't fit within the max-height renders & scrolls performantly.
Set a row count to render
We could have an input on the table to configure how many rows should be rendered. This could be similar to the rows attribute on the textarea. Some questions with this approach are:
- If the row count on the table is set to a value larger than the number of records in the table, should space be reserved? Or, should the value represent the maximum number of rows to render? Implications of possibly having a dynamic number of group rows should be considered in this.
- How does CSS styling of the height interact with setting this value?
The text was updated successfully, but these errors were encountered:
…pp (#1660)
# Pull Request
## 🤨 Rationale
The nimble-table doesn't support being configured with `height: auto`,
so this styling should be removed from the example app. With `height:
auto`, no rows of the table are rendered in the app. See #1624
## 👩💻 Implementation
Remove `height: auto` from the example app's styling. Now the table uses
the default height set in the nimble-table's `:host` styling. This is
aligned with how the Blazor example app is styled.
## 🧪 Testing
- Verified the rows of the table are now rendered in the Angular example
app
## ✅ Checklist
<!--- Review the list and put an x in the boxes that apply or ~~strike
through~~ around items that don't (along with an explanation). -->
- [ ] I have updated the project documentation to reflect my changes or
determined no changes are needed.
😯 Problem to Solve
There isn't a way to style the table to show all rows without a scrollbar unless you happen to know the pixel height in order to achieve that with your data set.
With the upgraded version of TanStack that will come when #1617 is resolved setting
height: auto
on the table renders no rows. There are a few workarounds that can be applied in the CSS for this, but even with those workarounds (or before the TanStack upgrade), a table withheight: auto
is extremely inefficient for the browser to render and can cause the browser to hang if the table is too large. This is because the table re-renders for everyoverscan
number of rows set in the table's virtualizer. Currently, the value ofoverscan
is 3, so the table will render with 0 rows, 3 rows, 6 rows, 9 rows, etc until all rows have been rendered.💁 Proposed Solution
I don't have a concrete proposal, but here are a few possible ideas along with their limitations:
Disable the virtualizer
We could have a mode on the table to disable the virtualizer. Then a client could set
height: auto
and have the browser be able to render a single time with all the rows rather than re-render for eachoverscan
number of rows. However, this doesn't account for styling that limits the height of the table (e.g.height: auto; max-height: 700px
). In that case, the virtualizer still needs to be utilized to ensure that a large number of rows that can't fit within themax-height
renders & scrolls performantly.Set a row count to render
We could have an input on the table to configure how many rows should be rendered. This could be similar to the
rows
attribute on thetextarea
. Some questions with this approach are:- If the row count on the table is set to a value larger than the number of records in the table, should space be reserved? Or, should the value represent the maximum number of rows to render? Implications of possibly having a dynamic number of group rows should be considered in this.
- How does CSS styling of the height interact with setting this value?
The text was updated successfully, but these errors were encountered: