docs(layout): drop 'intrinsic-free' overclaim for column stretch (#136 follow-up)#138
Conversation
…(PR #136 follow-up) Wind's items-stretch column uses a LayoutBuilder internally, so it is a REPLACEMENT for IntrinsicHeight (you don't wrap it in one), not something that is itself safe to nest inside an IntrinsicHeight. Reword SKILL.md and sizing.md accordingly, and list the column-stretch LayoutBuilder as another path in the 'safe to wrap' note. (Follow-up: these rewords missed the #136 squash because an intermediate commit was skipped.)
|
Warning Review limit reached
Next review available in: 14 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Follow-up documentation refinement to remove the “intrinsic-free and safe” overclaim around Wind’s items-stretch column behavior, clarifying that this behavior uses internal LayoutBuilder paths and should be treated as an alternative approach rather than something to nest inside intrinsic-sizing widgets.
Changes:
- Reworded
skills/wind-ui/SKILL.mdintrinsic-sizing limitation guidance to reflect theitems-stretchcolumn’s internalLayoutBuilderusage. - Updated
doc/layout/sizing.mdto include column cross-axis stretch as anotherLayoutBuilderpath and to reposition the guidance as a replacement approach rather than “safe to wrap”.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| skills/wind-ui/SKILL.md | Refines skill guidance about intrinsic sizing limitations and the items-stretch column’s behavior. |
| doc/layout/sizing.md | Adjusts intrinsic sizing limitation docs to include column stretch LayoutBuilder path and clarifies recommended usage. |
| ``` | ||
|
|
||
| **Why.** To resolve some sizes against the parent's real constraints, Wind introduces a `LayoutBuilder` (see `lib/src/widgets/w_div.dart`): `h-full` adds one around the cell only when the incoming height is unbounded, and a flex `basis-*` adds a single one around the surrounding flex when any direct child uses `basis-*`. `LayoutBuilder` runs during the layout phase, not the intrinsic-sizing phase, so an intrinsic-dimension query that passes through one of those `LayoutBuilder` paths asserts. This is a fundamental Flutter constraint (`LayoutBuilder` genuinely cannot answer intrinsics), not a Wind bug. Wind content that does **not** hit those `h-full` / `basis-*` paths carries no `LayoutBuilder` and is safe to wrap. | ||
| **Why.** To resolve some sizes against the parent's real constraints, Wind introduces a `LayoutBuilder` (see `lib/src/widgets/w_div.dart`): `h-full` adds one around the cell only when the incoming height is unbounded, and a flex `basis-*` adds a single one around the surrounding flex when any direct child uses `basis-*`. `LayoutBuilder` runs during the layout phase, not the intrinsic-sizing phase, so an intrinsic-dimension query that passes through one of those `LayoutBuilder` paths asserts. This is a fundamental Flutter constraint (`LayoutBuilder` genuinely cannot answer intrinsics), not a Wind bug. Wind content that hits none of Wind's `LayoutBuilder` paths (`h-full` in an unbounded height, `basis-*`, or the column cross-axis stretch above) carries no `LayoutBuilder` and is safe to wrap. |
| - Do not wrap Wind content that uses `h-full` / `basis-*` in `IntrinsicHeight` / `IntrinsicWidth`. | ||
| - For an equal-height row, use a `Stack` with a `Positioned(top: 0, bottom: 0)` element for the part that must fill, or reserve equal content so natural heights already match. | ||
| - Wind's own column cross-axis stretch (`items-stretch`, the `flex flex-col` default) is intrinsic-free (`LayoutBuilder` + `SizedBox(width: double.infinity)`), so it is animation-safe and does not hit this assertion. | ||
| - Wind's own column cross-axis stretch (`items-stretch`, the `flex flex-col` default) equalizes width WITHOUT you wrapping it in `IntrinsicHeight`. It uses a `LayoutBuilder` + `SizedBox(width: double.infinity)` internally (gated on a bounded width), so treat it as a REPLACEMENT for `IntrinsicHeight`, not something to nest inside one. |
| `items-stretch` inside a `SingleChildScrollView` needs an `IntrinsicHeight` wrapper from native Flutter; Wind has no token for it. Rare; reach for it when row children inside a scroll must match heights. | ||
|
|
||
| **Intrinsic sizing limitation.** Wrapping Wind content in `IntrinsicHeight` / `IntrinsicWidth` (or a `Row`/`Column` that needs child intrinsic heights for equal-height columns) throws `LayoutBuilder does not support returning intrinsic dimensions` WHEN that content triggers Wind's internal `LayoutBuilder` paths: `h-full` (only in an unbounded-height context) or a flex `basis-*` (a single `LayoutBuilder` around the surrounding flex). `LayoutBuilder` cannot answer intrinsic queries (a Flutter constraint, not a Wind bug). Escape hatches: use explicit `h-*` / `size-*` instead of `h-full`; do not wrap such content in `IntrinsicHeight`; for equal-height rows use a `Stack` + `Positioned(top:0,bottom:0)`. Wind's own `items-stretch` column is intrinsic-free and safe. | ||
| **Intrinsic sizing limitation.** Wrapping Wind content in `IntrinsicHeight` / `IntrinsicWidth` (or a `Row`/`Column` that needs child intrinsic heights for equal-height columns) throws `LayoutBuilder does not support returning intrinsic dimensions` WHEN that content triggers Wind's internal `LayoutBuilder` paths: `h-full` (only in an unbounded-height context) or a flex `basis-*` (a single `LayoutBuilder` around the surrounding flex). `LayoutBuilder` cannot answer intrinsic queries (a Flutter constraint, not a Wind bug). Escape hatches: use explicit `h-*` / `size-*` instead of `h-full`; do not wrap such content in `IntrinsicHeight`; for equal-height rows use a `Stack` + `Positioned(top:0,bottom:0)`. Wind's own `items-stretch` column equalizes cross-axis size without you adding `IntrinsicHeight` (it uses its own `LayoutBuilder` internally, so reach for it INSTEAD of `IntrinsicHeight`, not nested inside one). |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Follow-up to #136. The intrinsic-sizing docs called Wind's
items-stretchcolumn "intrinsic-free and safe", but it uses aLayoutBuilderinternally. RewordedSKILL.mdanddoc/layout/sizing.mdso it reads as a REPLACEMENT forIntrinsicHeight(not something to nest inside one), and the "safe to wrap" note now lists the column-stretchLayoutBuilderas another path. Addresses the CodeRabbit/Copilot precision comments that landed after #136's squash.Doc-only; no code/coverage impact.