Fix fixed footer experiment #4969
Merged
Conversation
This file contains 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
For now, we'll always write them in sync. When we read them, we'll use headerMode as source of truth. This will let us keep footerMode independent in a future commit.
This isn't the right time to determine special behavior. Instead we'll adjust footerMode itself conditionally on the gate.
This lets us fork the implementation later just for this case.
This is the final piece. Normal calls to setMode() keep setting both header and footer, but MainScrollProvider adjusts the footer conditionally.
|
Your Render PR Server URL is https://social-app-pr-4969.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cr36h708fa8c73bgbajg. |
|
haileyok
approved these changes
Aug 22, 2024
|
Will want to see how it performs on-device (both platforms) once merged, but works good in simulator and code lgtm. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Haven't tested this very deeply but I think this should fix the
fixed_bottom_barexperiment.It takes an alternate approach to what I had before. The idea is to split the
modevariable intoheaderModeandfooterMode. Initially we always update them in unison (but read fromheaderModeunless we're specifically interested in the footer). Then we rip out the current conditional logic during read. Then we add some conditional logic during write, and only for theMainScrollProvidercase which governs on-scroll showing/hiding. Other cases still set both.Individual commits tell the story.
I think this should be enough.
Test Plan
Verify the old mode (without gate) works like in prod.
Verify the experiment doesn't break starter pack wizard and other screens where we intentionally hide the bottom bar.