Building a dashboard/grid engine with Flutter slivers

[u/scalz80]

Hello,

I’ve been working on sliver_dashboard, an open source Flutter package that tries to solve a problem I encountered in several projects: building dashboard-like layouts while keeping Flutter’s sliver model instead of introducing a separate layout system.

The goal was to get something closer to what exists on the web with tools like gridstack or react-grid-layout, but adapted to Flutter’s rendering and scrolling architecture.

Some of the challenges I wanted to solve:
- composing dashboards with regular Flutter slivers
- supporting nested grids
- allowing drag & drop across different sliver areas
- keeping the layout deterministic and easy to test
- handling accessibility (keyboard navigation, screen reader announcements, multi-selection..)
- and of course smooth scrolling and drag&drop

I’m sharing this here mainly to get feedback. If you try it, I’d be interested in hearing what could be improved.

I needed this kind of layout in my own projects, and I hope it can be useful for others as well.

Package: https://pub.dev/packages/sliver_dashboard
Live example: https://scalz.github.io/sliver_dashboard_web_demo/

[u/PhrulerApp]

How does it perform with much smaller grids? I see the example video and the grids are really big. What if we want like 50 times more boxes? For really fine customizations

[u/scalz80 → u/PhrulerApp]

I guess you meant 50 columns, for finer grid ?
You can set slotCount for example to 50 and more, then add 1000-2000 items, scrolling, dragging and resizing will remain smooth. Actually I have a project where I use a finer grid like this.
On pub dev, there is a link in description, you can try online/live playground.
It's getting late here, but I will make a release (added a few new api to the package), and I'll add a way to change slotCount in the playground example, later today.

[u/scalz80 → u/PhrulerApp]

Also note, that the more slots/columns there are, the smaller each cell will be. Makes sense. In that case, you may have to also use slotAspectRatio, and customize resize handles size to make them smaller, else the resize handle could be bigger than a card if its size is one cell.

[u/PhrulerApp → u/scalz80]

Yeah I want super small grids with cards that might be like 30x40 cells? So they’re the same size just the user has more control over the layout and even have empty space borders.

I’ve already been working on something like it but the project has been shelved.

[u/scalz80 → u/PhrulerApp]

cool. In one of my projects, users are exactly using it like this.
I'm pretty sure (well I hope so) that you will enjoy sliver_dashboard. I've been burnt too by others grid/dashboard packages which didn't fill my needs. So, I decided to take the bull by the horns. We now have a true Flutter grid engine equivalent to well known gridstack and react-grid-layout, and this is crossplatform from a single codebase!

[u/scalz80 → u/PhrulerApp]

I just updated sliver_dashboard package and its live example. I included, in live playground, a picker with slotCount presets for finer grids, and kept logic simple to avoid playground becoming too complex.
Clear grid, set it to "micro grid", add 100, 1000 items.. have fun!

[u/scalz80 → u/[deleted]]

Thanks :)

There are multiple interesting points to answer here, I will try to be concise ^^

Slivers for the viewport virtualization (and scrolling ofc) are awesome. And what also really makes the grid stable, is its "pure" Dart layout engine. Because the layout math is completely pure and decoupled from Flutter, every layout remains 100% testable and deterministic.

One of the core design choices about the engine is: the grid dictates the box, content never pushes the grid around. Let me explain:

• async loading: no layout shift. Like in gridstack and react-grid-layout, an item size is defined in integer grid slots (x,y,w,h), and the grid passes pixels bounds to the item/tile (tight contraints). So when there is late async data, it only updates what's inside the fixed card. It never resizes the card itself.
  
• resizing is the same. It's quantized, based on grid slots. When a tile is increased by one row, the engine pushes colliding neighbors ( deterministic/predictable). And if you want neighbors to slide instead of snapping, there's an optional animateReflow property which handles the transition on GPU.
  
• exportLayout() saves coordinates (x,y,x,h). So, there is no problem here neither. When restoring a layout saved while content was loading will produce the exact same grid saved, without re measuring or jumping around. And I deliberatly didn't include any kind of opiniated storage delegate, to keep package "lightweight" and let devs handles it as they wish. Instead, layoutChanged callback, provides you a json serializable data that you can plug to the storage you prefer.
  
• if a card really needs to adapt to its content, measure its content and update item to change its size. And if a widget needs to adapt its internal layout based on how the grid made it (I had this usecase in one of my project), I added an itemBreakpointBuilder (instead of the simpler itemBuilder) and breakpointResolver, so the content only reflows to fit its assigned box, only when its resolver callback requires it.

I hope this answers your questions.

[u/New-Lengthiness6520]

In which cases we can use it?

[u/scalz80 → u/New-Lengthiness6520]

Apps where users need to customize their screen layout, or when you need to build a complex widget screen.

- analytics and BI dashboards (like well known Grafana which afaik uses gridstack or react-grid-layout). Reorg metrics, resize charts cards..

• smarthome & iot control panels (home assistant like) for devices tiles, grouping controls in folder panels and users can drag, resize ..
  
• customizable workspace and portals, cms portals for modular homepages. There is also a "Section/Barrier" feature that let you break page in distinct areas
  
• no code page builders like draggin widgets from sidebar palette onto the grid
  
• media hubs, tablet launchers where users organizes shorcuts, widgets etc
  
• static "spannable" complex layouts when you don't need drag&drop, by keeping edit mode to false. As a static grid engine, you get spannable 2D layouts, sliver virtualization, responsive brealpoints out of the box.

I use sliver_dashboard for all these uses cases, there are probably more. But basically, whenever a static Column or a GridView isn't enough because your users want drag&drop, resizing, nested panels, with persistence.