복잡한 UI 레이아웃을 유연하고 반응형 그리드 구조로 간단히 만들 수 있도록 설계된 Flutter용 강력한 그리드 레이아웃 시스템입니다. 개발자들이 여러 플랫폼에서 행, 열 및 정렬에 대해 정밀한 제어를 하여 복잡한 디자인을 만들 수 있게 해줍니다. 성능과 사용 편의성을 고려해 제작되었으며, 동적 콘텐츠와 현대 애플리케이션에 적합한 적응형 레이아웃을 지원합니다. 대시보드, 관리 패널 및 구조적이고 확장 가능한 디자인 패턴이 필요한 모든 인터페이스에 이상적입니다.
사용 사례
반응형 대시보드 구축
관리자 패널 인터페이스 만들기
복잡한 폼 레이아웃 설계
다양한 기기용으로 적응형 UI 구현하기
데이터 집약적인 표시 개발
주요 기능
유연한 그리드 정의
반응형 레이아웃 지원
크로스 플랫폼 호환성
정밀한 정렬 제어
동적 행 및 열 크기 조정
적합한 대상
경험 많은 Flutter 개발자
복잡한 레이아웃을 작업하는 UI 디자이너
반응형 그리드가 필요한 프로젝트
데이터 집약적인 인터페이스를 가진 앱
관리자 또는 대시보드 시스템을 구축하는 팀
고려 사항
초보자에게는 학습 곡선이 필요할 수 있습니다
간단한 선형 레이아웃에 적합하지 않음
매우 큰 그리드로 인한 성능 영향
내장 위젯에 비해 문서가 제한적
고급 UI 요구 사항에 가장 적합
원본 README
연결된 소스 저장소의 README 원문 스냅샷입니다. 최신 내용은 저장소에서 확인하세요.
Flutter Layout Grid
A powerful grid layout system for Flutter, optimized for complex user interface
design.
Click images to see their code
✨Featuring:✨
📐 Fixed, flexible, and content-sized rows and columns
(docs)
👇 Precise control over placement of items, including the ability to span
rows, columns, and overlap items
(docs)
💬 Named grid areas for descriptive positioning of children
(docs)
🦾 A configurable automatic grid item placement algorithm, capable of sparse
and dense packing across rows and columns (docs)
🔚 Right-to-left support, driven by ambient Directionality or configuration
♿ Accessibility considerations (this is your responsibility as a frontend
developer, so please read docs and learn
related technologies)
🩳 Extension methods and helper functions for descriptive, and short, layout
code
🐛 Debugging aids, including widget property listings in
DevTools,
Debug Painting, and visual indication of child overflow
Inspired by (and largely based on), the excellent CSS Grid
Layout spec.
Getting Started
All the terminology used in this library is shared with the CSS Grid 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, or copy
the code below:
Each element of columnSizes and rowSizes represents the function used to
size a column or row (collectively known as "track sizes").
There are currently three way to size rows and columns:
Class Name
Description
Usage
FixedTrackSize
Occupies a specific number of pixels on an axis
FixedTrackSize(64) fixed(64) 64.px
FlexibleSizeTrack
Fills remaining space after the initial layout has completed
FlexibleTrackSize(1.5) flexible(1.5) 1.5.fr
IntrinsicContentTrackSize
Sized to contain its itemsʼ contents. Will also expand to fill available space, once FlexibleTrackSize tracks have been given the opportunity.
IntrinsicContentTrackSize() intrinsic() auto
Technically, you can also define your own, but probably shouldnʼt as the API
will likely be evolving as I tackle
(#25)
(minmax()
support).
Naming areas of the grid
A gridʼs rows and columns can be sliced into areas — rectangular regions
containing one or more grid cells. These areas can be named (optionally), and
used to place gridʼs children. The areas are named using an ASCII-art string
provided to the areas parameter.
Note: We use the same format as CSSʼs
grid-template-areas,
except we use a multiline string.
If an areas argument has been provided to a grid, you must specify the same
number of sizes using columnSizes and rowSizes elements. For the example
above:
LayoutGrid(
areas: '''
header header
nav content
footer footer
''',
// 2 columns, 3 rows, just like the areas string
columnSizes: [
auto, // contributes width to [nav, header, footer]1.fr, // contributes width to [content, header, footer]
],
rowSizes: [
96.px, // contributes height to [header]1.fr, // contributes height to [nav, content]72.px, // contributes height to [footer]
],
children: [
// ...
],
)
Grid children can be assigned to named areas using the NamedAreaGridPlacement
widget. For more information, see assigning the child to a named
area.
Positioning child widgets in the LayoutGrid
Once you have a grid, you have to tell its children which rows and columns
they should occupy. There are three ways of doing this:
GridPlacement also has a super power — all of its parameters are optional.
If, for example, you do not specify a rowStart, the automatic placement
algorithm will attempt to place the child in the
first vacant spot that it can find.
Child placement in named areas
If your grid has named areas defined, you can
place children in those areas using the NamedAreaGridPlacement widget. For
example:
LayoutGrid(
areas: '''
red red blue
red red blue
. . blue
''',
// Note that the number of columns and rows matches the grid above (3x3)
columnSizes: [64.px, 64.px, 64.px],
rowSizes: [
64.px,
64.px,
64.px,
],
children: [
// Using NamedAreaGridPlacement constructorNamedAreaGridPlacement(
areaName: 'red',
child: Container(color: Colors.red),
),
// Alternatively, an extension method on Widget is availableContainer(color: Colors.red).inGridArea('red'),
],
)
NOTE: If a NamedAreaGridPlacement references a named area that doesnʼt
exist, it will not be displayed in the grid. This can be helpful when switching
between responsive layouts.
Automatic child placement
Grid children can be placed into rows and columns automatically based on partial
or non-existent placement information.
The algorithm responsible for automatic placement has several modes, selected
through the LayoutGrid.autoPlacement parameter. The behavior of these modes
are identical to those supported by CSSʼs grid, described described
here.
When no placement information is provided
If a child is provided to the grid without being wrapped in a GridPlacement or
NamedAreaGridPlacement, it will be allotted a single cell (1⨉1), and placed
into the first vacant cell in the grid.
When partial placement information is provided
All of the GridPlacement widgetʼs parameters are optional. By specifying
additional positioning or spanning information with
columnStart/columnSpan/rowStart/rowSpan parameters, more
constraints are fed into the placement algorithm.
For example, if columnStart is provided, but not rowStart, the placement
algorithm will walk across the gridʼs rows until it finds a vacant area, in the
specified column, that accommodates the child.
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.
Automatic semantic ordering is currently being explored in
#50.
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. Handy, but weʼre not there yet.
(#5)
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.
(#7)
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
Roadmap
[x] Tests! (we now have a decent suite going)
[x] 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)
[x] Performance improvements, as soon as I can get this profiler running(!!!)