Philipinho ee3c5ce9d9 fix(bases): render filtered rows on first paint in standalone view ...

Track the scrollport element in state instead of reading
`scrollportRef.current` during render. The ref was always null on the
render that mounts the `.tableScrollport` div, so `useVirtualizer`'s
`_willUpdate` saw `scrollElement=null`, skipped observer attachment, and
`calculateRange` returned null — rendering zero rows even though the
`/rows` response was already in the React-Query cache.

The bug surfaced after a filter change (the `rowsLoading` skeleton path
remounts the scrollport, and no follow-on render is guaranteed once
`/rows` settles) but not on first base load (slower side queries forced
an extra render that coincidentally re-bound the virtualizer). Switching
views also masked it: the re-render triggered `_willUpdate` with a now-
populated ref.

Using a callback-ref-backed `useState` triggers a render the moment the
div attaches, so the virtualizer picks it up on the next pass — no
view-switch workaround needed.

2026-05-25 15:53:28 +01:00

..

client

fix(bases): render filtered rows on first paint in standalone view

2026-05-25 15:53:28 +01:00

server

feat(bases): clear kanban grouping when its property changes to a non-groupable type

2026-05-24 16:26:57 +01:00