Explain 'constraints go down, sizes go up, parent sets position.'

What's really being asked

Whether you understand Flutter's layout algorithm as a negotiation between parent and child rather than a single top-down assignment. Senior engineers need to debug overflow errors without guessing, and that requires knowing how constraints and sizes flow in opposite directions.

The full answer

First, a crisp statement of the rule: constraints travel down the tree from parent to child, the child replies with its own size up to the parent, and only then does the parent decide the child's position. Second, the distinction between tight constraints, loose constraints, and unbounded constraints. Third, a concrete error scenario where a scrolling widget like ListView passes an unbounded constraint to its child, and how that triggers a layout failure. Fourth, the fix: wrapping the offending child in Expanded or Flexible when inside a Row or Column, or using a bounded parent like SizedBox to stop infinite constraints from propagating.

The mistakes people make

Saying Flutter layout is just like the web or that widgets choose their own positions. Blaming the child widget that throws the error instead of tracing which parent passed an infinite constraint. Recommending a Wrap widget or random shrinkWrap without explaining why the constraint direction matters. Claiming that setting width double infinity always fixes unbounded errors, when it actually causes them in unbounded parents.

What usually comes next

How does BoxConstraints work under the hood? What is the difference between tight and loose constraints? Why does a Row inside a vertical ListView sometimes fail while a Column does not? How would you implement a custom RenderBox that respects this protocol? When is it safe for a parent to pass unbounded constraints?

A concrete example

A horizontal ListView contains a Column. Because the ListView scrolls horizontally, it passes its child an unbounded width constraint. Inside that Column is a Container with width set to double infinity. During layout, the Container asks for infinite width, but the Column cannot satisfy that because its own width constraint is unbounded. Flutter throws an unbounded width error. To diagnose, you trace upward: the error is not the Container's fault, but the horizontal ListView's removal of the width bound. The fix is to wrap the Column in a SizedBox with a fixed width so the Column receives a tight width constraint, which it can then pass down to the Container. Alternatively, replace double infinity with a fixed width or use a flex parent that bounds the child properly.