Fix layout shift in NavigationStack #209
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The core problem, as identified by Abe, is that determining the final layout (including the app bar's height and visibility) requires preference values derived from composing the content itself. This creates a chicken-and-egg scenario. We now render the main content in a `Box` with `currentContentAlpha` set to `0.0` initially. And we're now tracking a state variable, `isTopBarMeasuredOnce', initially false, which is set to true in an `onGloballyPositionedInWindow` modifier on the top app bar. When `isTopBarMeasuredOnce` is true, we make the main content visible.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(I don't think we should merge this; it was generated by an LLM who didn't really understand what it was doing.)
The core problem, as identified by @aabewhite, is that determining the final layout (including the app bar's height and visibility) requires preference values derived from composing the content itself. This creates a chicken-and-egg scenario.
We now render the main content in a
BoxwithcurrentContentAlphaset to0.0initially.And we're now tracking a state variable,
isTopBarMeasuredOnce', initially false, which is set to true in anonGloballyPositionedInWindowmodifier on the top app bar. WhenisTopBarMeasuredOnce` is true, we make the main content visible.If we think this is directionally correct, I think we should rewrite it from scratch. (The LLM added some state around
topBarBottomPxandtopBarHiddenStatethat I don't think are actually necessary/relevant to the approach. Hallucinations?)Another approach which I mentioned on Slack would be to have a "preferences contract." The idea is that, e.g. NavigationStack would have a Skip-only modifier that tells SkipUI what sorts of content will appear in the app bar. Then, later, when the preferences get set, the bar could render normally, and optionally crash if the contract was violated (if we promised not to include any toolbar buttons, but then it turns out we did).
Skip Pull Request Checklist:
swift test