A grid-based layout system for Flutter

flutter layout grid

a g,rid-based layout system for flutter, optimized for user interface design, inspired by css ,layout.

✨featuring:✨

• fixed, flexible, and content-based row and column sizing
• precise control over placement of items if desired, including the ability to span rows, columns,
  and overlap items
• a configurable automatic g,rid item placement algorithm, capable of sparse and dense packing across
  rows and columns
• right-to-left support, driven by ambient directionality or configuation
• gutters!

getting started

all the terminology used in this library is shared with the css g,rid layout spec. if you’re
unfamiliar, i recommend taking a look at mdn’s glossary of grid
terms.

for inclusion in your pubspec, see
pub.dev.

example

this is the source for the sample you can see above.

const cellred = color(0xffc73232);
const cellmustard = color(0xffd7aa22);
const cellgrey = color(0xffcfd4e0);
const cellblue = color(0xff1553be);
const background = color(0xff242830);

class piet extends statelesswidget {
  @override
  widget build(buildcontext context) {
    return container(
      color: background,
      child: layoutg,rid(
        columngap: 12,
        rowgap: 12,
        templatecolumnsizes: [
          flexibletracksize(1),
          flexibletracksize(3.5),
          flexibletracksize(1.3),
          flexibletracksize(1.3),
          flexibletracksize(1.3),
        ],
        templaterowsizes: [
          flexibletracksize(1),
          flexibletracksize(0.3),
          flexibletracksize(1.5),
          flexibletracksize(1.2),
        ],
        children: [
          // column 1
          gr,idplacement(
            columnstart: 0,
            rowstart: 0, rowspan: 2,
            child: _builditemforcolor(cellred),
          ),
          g,ridplacement(
            columnstart: 0,
            rowstart: 2, rowspan: 2,
            child: _builditemforcolor(cellmustard),
          ),
          // column 2
          gr,idplacement(
            columnstart: 1,
            rowstart: 0, rowspan: 4,
            child: _builditemforcolor(cellred),
          ),
          // column 3
          gri,dplacement(
            columnstart: 2, columnspan: 3,
            rowstart: 0,
            child: _builditemforcolor(cellblue),
          ),
          gri,dplacement(
            columnstart: 2, columnspan: 3,
            rowstart: 1, rowspan: 2,
            child: _builditemforcolor(cellmustard),
          ),
          gr,idplacement(
            columnstart: 2,
            rowstart: 3,
            child: _builditemforcolor(cellgrey),
          ),
          // column 4
          gr,idplacement(
            columnstart: 3,
            rowstart: 3,
            child: _builditemforcolor(cellblue),
          ),
          // column 5
          gri,dplacement(
            columnstart: 4,
            rowstart: 3,
            child: _builditemforcolor(cellmustard),
          ),
        ],
      ),
    );
  }

  widget _builditemforcolor(color c) =>
      decoratedbox(decoration: boxdecoration(color: c));
}

usage

sizing of columns and rows

there are currently three way to size tracks (rows or columns):

• flexiblesizetrack — consumes remaining space after the initial layout has completed.
• fixedsizetrack — occupies a specific number of pixels on an axis
• intrinsiccontenttracksize — sized to contain its items’ contents. will also expand to fill
  available space, once flexibletracksize tracks have been given the opportunity.

technically, you could define your own, but i wouldn’t because the api will be evolving.

placing widgets in the layoutgrid

when an arbitrary widget is provided to layoutg,rid.children, it will be allotted a single cell and
placed automatically according to the layoutgri,d.autoplacement algorithm (described
here).

layoutgrid(
  templatecolumnsizes = [/*...*/];
  templaterowsizes = [/*...*/];
  children: [
    mywidget(), // will occupy a 1x1 in the first vacant cell
  ],
)

precise control over placement of an item is provided via the gridplacement widget. you can think
of gridplacement as the
positioned equivalent for
layoutgrid — it controls the where a widget is placed, and the cells it occupies.

layoutgrid(
  templatecolumnsizes = [/*...*/];
  templaterowsizes = [/*...*/];
  children: [
    gridplacement(
      // all parameters optional
      columnstart: 1,
      columnspan: 3,
      rowstart: 5,
      rowspan: 2,
      child: mywidget(),
    ),
  ],
)

all of the gridplacement‘s constructor parameters are optional. it defaults to a 1×1 grid item
that will be placed automatically by the grid. specifying positioning or spanning information (via
columnstart/columnspan/rowstart/rowspan parameters) will feed additional constraints into
its algorithm.

a definitely-placed item (meaning columnstart and rowstart have both been provided), will always
be placed precisely, even if it overlaps other definitely-placed items. automatically-placed items
will flow around those that have been placed definitely.

accessibility and placement

take note that the meaning you convey visually through placement may not be clear when presented
by assitive technologies, as flutter defaults to exposing information in source order.

in situations where your semantic (visual) ordering differs from ordering in the source, the
ordering can be configured via the semantics widget’s
sortkey parameter.

differences from css grid layout

things in css grid layout that are not supported:

• negative row/column starts/ends. in css, these values refer to positions relative to the end of a
  grid’s axis.
• any cells outside of the explicit grid. if an item is placed outside of the area defined by your
  template rows/columns, we will throw an error. support for automatic addition of rows and columns
  to accommodate out of bound items is being considered.
• minmax(), percentages, aspect ratios track sizing
• named template areas, although they’re coming

differences:

• in flutter_layout_grid, flexible tracks do not account for their content’s base sizes as they do
  in css. it’s expensive to measure, and i opted for speed.
• flexible tracks whose flex factors sum to < 1

why not slivers?

this library is not sliver-based. i’d
considered it, but my use cases required the content-based sizing of rows and columns, and i didn’t
want to figure out the ui challenges associated with resizing tracks during scroll. i might be
interested in taking those on at some point.

roadmap

• [ ] tests!
• [ ] named template areas, for friendlier item placement
• [ ] improved track sizing, including minimum/maximums and aspect ratios
• [ ] the ability to specify row and column gaps at specific line locations via a delegate
• [ ] implicit grid support (automatic growth along an axis as children are added)
• [ ] performance improvements, as soon as i can get this profiler running(!!!)