skip to content

In Flutter DevTools, how does the inspector's flex explorer help you diagnose an overflowing Row, and what happens to edits you make there?

level: middleimportance: should knowfreq 35%

answer

  1. appears for Row, Column, Flex or a child
  2. main and cross axis, alignment, flex factor
  3. red constraints, yellow-and-black tape
  4. edits apply live to the device
  5. reverted on hot reload

basics

~20 s

Selecting a Row, Column or Flex, or a direct child, shows the flex explorer: axes, alignments, flex factors and constraints, with overflow in yellow-and-black tape. Edits to alignment or flex apply live, never touch source and revert on hot reload.

solid answer

~40 s

In the Flutter inspector I select the overflowing `Row`, or one of its children, and the Widget Explorer shows a **flex explorer** tab. It draws the **main and cross axis**, the current `mainAxisAlignment` and `crossAxisAlignment`, each child's **flex factor and fit**, and the **constraints**; violated constraints are red and the overflow shows the same yellow-and-black tape as on the device. That tells me which child is too wide and whether it is flexible. I can change the alignments or a child's flex factor from dropdowns and watch the device update, which is a fast way to test a fix. Those edits never modify the source and are reverted on the next hot reload, so I still make the real change in code.

go deeper

for a junior

Know that selecting a Row or Column in the inspector shows a flex explorer with axes, alignment and flex factors, and that overflow is drawn in yellow tape there too.

for a middle

Explain the diagnosis loop: select the flex, find the child that is too wide, try an alignment or flex change live, then apply the fix in code because explorer edits revert on hot reload.

for a senior

Show judgement in using the explorer as an experiment bench: test hypotheses in seconds, confirm on the device, and translate the result into a code change that holds on every screen size.

for a principal

Point out where a visual tool stops helping: flex layouts only, debug builds only, so recurring overflows call for responsive layout conventions and golden tests rather than more inspection.

## Where the flex explorer lives The **flex explorer** is one of the tabs of the **Widget Explorer**, the panel on the right of the DevTools **Flutter inspector**. It appears when the selected widget is a **flex widget** (`Row`, `Column`, `Flex`) or a **direct child** of one. Older tutorials call it the *layout explorer*; that was its name in the legacy inspector, which DevTools no longer offers. It matters because the most common layout failure a Flutter developer meets is a `RenderFlex` overflow: the yellow-and-black striped bar on the edge of a `Row` or `Column`. The explorer turns that stripe into a diagram you can read. ## What it shows - **Axes.** Which direction is the main axis and which is the cross axis for this flex. - **Alignment.** The current `mainAxisAlignment` (for example `start` or `spaceBetween`) and `crossAxisAlignment`. - **Per-child data.** Each child's **flex factor** and **flex fit** (whether it is flexible at all, and `tight` or `loose`). - **Constraints and sizes.** The constraints each child received and the size it chose. - **Errors.** Violated layout constraints are coloured **red**, and overflow is drawn in the standard **yellow-tape** pattern, matching what the device shows. ## A diagnosis loop for an overflowing Row 1. Run the app in debug mode and open the Flutter inspector. 2. Turn on **Select Widget Mode** and tap the row with the stripe, or select it in the widget tree. 3. Open the **flex explorer** tab and look for the child drawn wider than the remaining space, usually one with no flex factor. 4. Click that child in the explorer; with Select Widget Mode on, the selection is mirrored on the device so you can confirm it is the element you think. 5. Try a change from the dropdowns, such as giving the child a flex factor or changing the main-axis alignment, and watch both the explorer and the device animate to the new layout. 6. Once a change works, make the equivalent edit in code; which widget to use for that edit is a question of the flex layout rules themselves. ## What you can edit, and what happens to it | Property | Editable in the explorer | Notes | |---|---|---| | `mainAxisAlignment` | yes | `start`, `end`, `center`, `spaceBetween`, `spaceAround`, `spaceEvenly` | | `crossAxisAlignment` | yes | `start`, `center`, `end`, `stretch` | | a child's flex factor (`FlexParentData.flex`) | yes | the UI offers null and 0 to 5; the real value can be any int | | `mainAxisSize`, `textDirection` | not currently | listed by the docs as possible future additions | Every edit is applied to the **running app only**. The docs are explicit: property changes made from the explorer **don't modify your source code and are reverted on hot reload**. The explorer is an experiment bench, not an editor. ## Why it beats reading the error text alone - The console message names the overflowing flex and the number of pixels, but not which child caused it; the explorer shows every child's size side by side. - It shows constraints visually, which makes the "constraints go down, sizes go up" rule concrete. - It lets you test a hypothesis in seconds without a code edit and reload. ## Limits - It only covers flex layouts. For a `Stack`, a `Wrap` or a custom layout you fall back to the Widget properties and Render object tabs, or to `debugPaintSizeEnabled`. - Like the rest of the inspector, it needs a **debug** build.

  • In the Flutter DevTools flex explorer, you set a child's flex to 1 and the overflow disappears; why is the bug still there after the next hot reload?
    Edits made in the flex explorer change the running app's render data only; they never write to your source files, and the docs state they are reverted on hot reload. Hot reload rebuilds from your unchanged code, so the overflow returns until you make the equivalent change in the widget tree yourself.
  • When does the flex explorer tab not appear in Flutter's Widget Explorer?
    When the selected widget is neither a flex widget (`Row`, `Column`, `Flex`) nor a direct child of one. For a widget deep inside a flex child, select its ancestor that sits directly in the flex, or the flex itself, to get the tab back.

The flex explorer is like moving furniture on a floor plan before calling the movers: you can shuffle the pieces and see whether they fit, but nothing in the real room moves until you do it yourself, and the plan resets when you reload it.

saying these in an interview costs you the question

  • Changes in the flex explorer are saved into the Dart source automatically.
  • The flex explorer tab appears for any selected widget, including Stack children.
  • The overflow stripe only appears on the device, never in DevTools.
  • The flex explorer can only display values, it cannot change anything at runtime.
  • A hot restart is needed to see a change made in the flex explorer.