Clojurians Log v2

Soz I missed this: Yes, 0tx needs it. Accounting Journal Entries have N Lines or Postings, which are either debits or credits. E.g. you made a $100 Cash payment to settle $30, $50 & $20 in liabilities (think 3 invoices from same vendor) = 1 credit + 3 debits, or 4 Lines. Most Entries have 2 Lines: 1 debit and 1 credit (i.e. double-entry), but “split entries” have 3 or more Lines. These counts are knowable up-front, i.e. you’ll have a Journal Entry “header line”’of height 32px, but on expansion you want to render those N Lines, which concretely mean additional dom/tr rows or sub-table below the expanded row. Expanded entries are typically sparse, but sometimes you want to expand everything.

i need screenshot

amazing

Cool demo! I faced similar problems with https://re-com.day8.com.au/#/nested-grid. I found that a row which expands to reveal more rows can pose the same challenges as row with variable height. Once you change the height of anything (whether resizing or adding/deleting rows), then you've changed the y-position of every subsequent row, causing that "push-down" effect. This can also be an issue if you need to render any sort of container or header to enclose those rows. Like @petrus says, it can be mitigated by adding invariants, like fixed row height, or fixed counts of "hidden" rows. I'm not sure what you mean by "sparse," though. I solved it with a data-model that nests rows inside each other (as vectors), and doing a cached traversal to calculate sizes & positions. That way, when you resize or add/delete a row, it changes the identity of all its parent-rows, causing a cache miss for every affected row. Of course, one tradeoff with a cache is that you have to remove the old identities somehow.

A virtually scrolling table with rows that render N sibling rows when expanded is common, e.g. Journal Entries with N debits or credits on toggle or a Customer List that expands Invoices on toggle, but the height will always be bounded and calculable per row, and could be known up-front during scroll as expanded rows are typically sparse. The tricky part is that rows which expanded earlier on “push down” the viewport, which I suspect could be handled in a clever way at the boundary using some offset wizardry. Not a simple problem, but most users would probably be happy for the view to shift a bit. So doesn’t need to be fully dynamic, but the caller needs to compensate for rows of differing but not “arbitrary” heights. Would require more sophisticated IndexRing.

does your accounting app have this?

Genuinely bonkers

i am also blown away, this is the foundation of "google sheets for the JVM"

Very nice. Looking forward to variable row heights 😉. Dynamically-sized rows (even if IndexRing takes a fn that can calculate row-height for e.g. expanded rows), would open open up some interesting in-line editing UIs.

dynamic heights (e.g. Slack channel history virtual scroll) has an entirely different set of tradeoffs, we have historically done a few experiments but never found a use case outside of chat and newsfeed apps

Willing to be convinced, if you have screenshots of an enterprise grid that truly needs dynamic row height i'd love to see it