IntrinsicHeight/Width: Sizing by 'Natural' Dimensions
IntrinsicHeight/Width tells a child widget to size itself to its "natural" dimensions, rather than expanding to fill available space. It's useful for making all items in a Row match the tallest item's height, but it's expensive and should be avoided.
WHY IT EXISTS Sometimes a widget's parent provides infinite space (like a Column in a ListView), causing the child to try and expand infinitely, which results in an error. Intrinsic sizing was created to solve this by allowing a child to size itself based on its content's "natural" dimensions instead of its parent's unbounded constraints.
THE MENTAL MODEL Think of IntrinsicHeight as a two-pass layout negotiation. First, it asks its child, "Ignoring my constraints for a second, what's the ideal height you'd like to be?" After getting the answer (the intrinsic height), it then says, "Okay, now lay yourself out, but I'm forcing you to be exactly that tall." This same logic applies to IntrinsicWidth for horizontal sizing.
HOW IT WORKS IntrinsicHeight and IntrinsicWidth add a speculative layout pass before the final layout. In this first pass, the widget queries its child for its intrinsic dimensions without actually rendering it. It then uses this information in the second, final layout pass to provide tight constraints to the child, forcing it to adopt its intrinsic size. This process is expensive because it effectively doubles the layout work for that part of the widget tree.
WHEN TO USE IT The primary use case is forcing all children in a Row or Column to have the same size as the largest child. For example, wrapping a Row in an IntrinsicHeight will make all children in the Row as tall as the tallest one. It's also a solution when a child is in an unconstrained environment (like a scrollable Column) and you want it to size to its content rather than throwing an error for attempting to be infinitely large.
WHEN NOT TO USE IT Avoid it whenever possible due to its performance cost. If you can achieve the same layout with less expensive widgets like Expanded, Flexible, or by passing explicit sizes, do that instead. It is particularly bad in deep or complex widget trees, where its O(N²) worst-case complexity can cause noticeable jank and slow frame rates. Do not use it as a default solution for sizing issues.
ONE CANONICAL EXAMPLE To make two Card widgets in a Row have the same height, even if their content differs, wrap the Row in an IntrinsicHeight. The widget will first measure the intrinsic height of both cards, find the maximum of the two, and then force both cards to render at that taller height. Without IntrinsicHeight, each card would only be as tall as its own content requires.
Read the original → api.flutter.dev
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.