My usecase is a grid for a timetable where the vertical coordinates are 15 min timeslots and the horizontal axis are events (in my case lessons) happening simultaneously. I can imagine this being a use case for others, too. Unfortunately I don’t have the time now to look at it myself, so just an idea for now. Thank you for sharing with the community!
oki. what you need is a time(table) widget. This is a bit different, but that might be an interesting challenge once I’ll have reached v1 (I hope soon).
Atm, target is dashboard/grid engine for stuff like analytics, iot (like grafana) etc. But sure, it can also be used for building UI with lazy loading (and it’s also composable with others slivers which is handy).
Actually, my goal is to fill the gap between Flutter and JS grid engines.. the direct “JS contender” is react-grid-layout (I’ve been heavily inspired by this package). And I added some fancy features and opti.
Remaining tasks on my todo:
- Allow to create your own custom compaction and positioning algo
- Sections/visual headers to segment the dashboard, with sticky option
- Allow items to be dropped into or dragged out of groups.
1 Like
For those following my iterations, in next coming version (0.9) :
- new feat: add your custom compaction algo, by implementing CompactorDelegate to define custom rules (e.g., specific gravity, fixed zones).
- huge performance boost on compaction algo. noticeable when there are a lot of items in dashboard
Compaction algo comparison v.0.8 (old) vs 0.9 (new), on desktop:
┌──────────────────────────────────────────────────────────────────────────┐
│ BENCHMARK RESULTS │
├──────────────────────────────────────────────────────┬───────────────────┤
│ Test │ Time │
├──────────────────────────────────────────────────────┼───────────────────┤
│ COMPACTION │ │
├──────────────────────────────────────────────────────┼───────────────────┤
│ Vertical Old (100 items) │ 1.22 ms │
│ Vertical New (100 items) │ 17 µs │
│ Horizontal Old (100 items) │ 355 µs │
│ Horizontal New (100 items) │ 17 µs │
│ Vertical Old (500 items) │ 99.90 ms │
│ Vertical New (500 items) │ 99 µs │
│ Horizontal Old (500 items) │ 10.30 ms │
│ Horizontal New (500 items) │ 101 µs │
│ Vertical Old (1000 items) │ 898.88 ms │
│ Vertical New (1000 items) │ 222 µs │
│ Horizontal Old (1000 items) │ 37.99 ms │
│ Horizontal New (1000 items) │ 217 µs │
│ MOVE │ │
├──────────────────────────────────────────────────────┼───────────────────┤
│ Move Element (100 items) │ 72 µs │
│ Move Element (500 items) │ 1.40 ms │
│ SORT │ │
├──────────────────────────────────────────────────────┼───────────────────┤
│ Sort Layout (100 items) │ 6 µs │
│ Sort Layout (500 items) │ 43 µs │
│ Sort Layout (1000 items) │ 99 µs │
│ OPTIMIZE │ │
├──────────────────────────────────────────────────────┼───────────────────┤
│ Defrag (100 items) │ 4.76 ms │
│ Defrag (500 items) │ 855.42 ms │
└──────────────────────────────────────────────────────┴───────────────────┘
Optimize Defrag is not called by dashboard, this is an api that can ponctually be used when you want to “defragment” your dashboard.
Would be interesting to compare to the JS contender I mentioned previously. Although they use mutable state if I’m not wrong, and my package uses immutable and copyWith, I wouldn’t be suprised if we get better results thx to AOT (maybe same for web wasm..). When I’ll have more time, I’ll compare both.
Final stretch before the 1.0 …
2 Likes
POC: nested dashboards/groups
- Sections
- Folders/Groups (nested dashboard)
- scrollToItem by its logical id
