-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: refactor navigation infra #10977
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codewise looks good 👍
To clarify this PR is only about reorg of nav stuff, right?
export const HomeTab = () => { | ||
return ( | ||
<TabStackNavigator.Navigator initialRouteName="Home" screenOptions={{ headerShown: false }}> | ||
{SharedRoutes()} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't we just <SharedRoutes />
instead? I noticed the typings there need to be React.FC too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why this wasn't possible, was because StackNavigator.Navigator
expects its children to be of type Screen, Group or Fragment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(follow-up PR): We can make our component with this type, right? Usually, people use these extra guard-rails to avoid using wrong children, but it's just a type check in their code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I didn't get what you mean here. Do you mind if you explain it to me in code so I get better what would you like this API to look like.
d61825c
to
9e156cb
Compare
8.55.0 - 2024.10.23.12 |
5d9716a
to
da45c6a
Compare
<Box mb={2}> | ||
<OpaqueImageView imageURL={url} height={145} /> | ||
<Box mb={2} justifyContent="center" overflow="hidden"> | ||
<Image src={url} height={145} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reverts commit 4cb2960.
Hey @damassi - sorry for the late reply, I was sick and got back today. The PR is already reviewable actually and I can address any comments. |
Requests are welcome - I won't push more to this and we can have the unauthorized flow in a separate PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a big PR and I don't have many comments other than its nice to get this all into one system, and its a very good improvement.
Couple things:
- Once this is merged, we should prioritize getting in the other unauthenticated routes so that we're not in a split situation
- We should also prioritize, sooner rather than later, removing the FF split between old and new, so that we're on one system. Once that's done i think we can do a cleanup/polish pass and this will be 👌
@brainbicycle, @gkartalis - do y'all have any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, thanks for the hard work here 💪
Left a small comment for a follow-up PR
export const HomeTab = () => { | ||
return ( | ||
<TabStackNavigator.Navigator initialRouteName="Home" screenOptions={{ headerShown: false }}> | ||
{SharedRoutes()} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(follow-up PR): We can make our component with this type, right? Usually, people use these extra guard-rails to avoid using wrong children, but it's just a type check in their code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the great work! 🌟
I didn't take the time to check all the code changes in detail, but overall, it looks pretty good 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work! I did leave some questions but none are blocking.
Another generic question that I have is around the headers across the app, lets say that design/product doesn't agree with the header changes is there a way to change the headers across the app with one custom component easily now with the react navigation?
if (Platform.OS === "ios") { | ||
modules.map(({ moduleName, module }) => { | ||
register(moduleName, module) | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
readonly hidesBottomTabs?: boolean | ||
} | ||
|
||
export const ScreenWrapper: React.FC<ScreenWrapperProps> = ({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question(non-blocking): how is the screen wrapper different than our <Screen />
component from palette? Would it make sense to use the Screen here instead of this custom one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted actually to use Screen
from palette-mobile
initially here but that meant that I would have to go through all screens and fix their padding and in some cases, remove Screen
from the screens that are using it. And that felt to me something too early to do and it would require a separate PR for it. So I just copied the existing sreen wrapper that we currently have in AppRegistry
and simplified it a bit. A future step would be to have no wrapper logic here but it's probably too early for it now
{/* | ||
NOTE: we don't need safeAreaEdges but passing undefined or empty array didn't work, | ||
so we're passing "left" that doesn't actually add anything to the webview to avoid | ||
having double paddings from Screen and ArtsyWebView | ||
*/} | ||
<ArtsyWebView url={data.href} safeAreaEdges={["left"]} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question(non-blocking): why did we get rid of safeAreaEdges here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question, the reason behind that here was that after my changes, this wasn't needed anymore and there were no more paddings. But good note on this because It means I need to bring them back in case the feature flag is disabled
const space = useSpace() | ||
const enableNewNavigation = useFeatureFlag("AREnableNewNavigation") | ||
|
||
useAndroidGoBack() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be curious to understand if we do need this still after this PR stabilizes though and we do remove the feature flag
(for context: this was added in some places of the app because without it it was navigating us to the MyCollection screen when pressing the android back button instead of going back on the navigation stack probably because of our hybrid nav setup)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good note. Let me test it out actually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -18,6 +18,7 @@ export const BottomTabs: React.FC<BottomTabBarProps> = (props) => { | |||
const focusedRoute = findFocusedRoute(props.state) | |||
const params = focusedRoute?.params as any | |||
const module = modules[params?.moduleName as AppModule] | |||
// const unreadConversationsCount = 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👁️ should we get rid of this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh yes definitely
useLayoutEffect(() => { | ||
navigation.setOptions({ | ||
headerTitle: `${auctionResult.title}, ${auctionResult.dateText}`, | ||
}) | ||
}, [navigation]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how does the headerTitle show up if the title and date text is too long to be displayed? If we do use our <Text>
component in order to render this text we are okay since this is handled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
useEffect(() => { | ||
navigation.setOptions({ | ||
headerRight: () => { | ||
return ( | ||
<Touchable onPress={handleSave} disabled={!isEmailValid}> | ||
<Text variant="xs" color={isEmailValid ? "black100" : "black60"}> | ||
Save | ||
</Text> | ||
</Touchable> | ||
) | ||
}, | ||
}) | ||
}, [navigation, email]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since this is a static component (if I understand this correctly) why do we have it set in a use effect? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I am doing that to take advantage of react-navigation defined headers. (title
and headerLeft
and rightHeader
). We could define this in component withing the render tree but then we would need maintain the header in this component separately.
News is that react-navigation might be migrating to a different API where we would be defining that header withing the render method. 🤞
Email: <Text variant="xs">{userEmail}</Text> | ||
</Text> | ||
useEffect(() => { | ||
queueMicrotask(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we use queue microtask + hide the setOptions here with a feature flag versus the other places where we do set the options for the header right item without queueMicrotask + featureflag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sharp, this is not neeeded. I will remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For context, initially, I was showing modal screens just with a different presentation way and hide their bottom tabs. That led to too much stuff happening on the UI and this useEffect
was breaking the UI so I queued it. However later in the PR, I realized that it makes more sense to actually have the modals be modals and not deal with any issues like this
7cdd53e
Did a first round of the existing infra QA to make sure I didn't break anything. I will merge this PR in an hour then send an invitation for QA for next week. Thanks everyone for reviewing. |
Only thing left to do now is hooking up the unauthorized flow. Everything else should be working fine Merging this now. 🚀 🚀 🚀 🚀 🚀 |
Nice work @MounirDhahri 💥 |
Description
This PR started as a Future Friday effort to spike on a potential hybrid approach of adopting React-Navigation in the App.
After a few commits, I realized this was worth pursuing and kept working on it to get us to a mergeable presentable state.
What does this PR bring?
What does this PR not do
What does this PR allow us to
ModalStack
NavStack
and a bunch of native features about navigation.preload
linkNotes for the reviewers
What comes next
How can I test things out
PR Checklist
To the reviewers 👀
Changelog updates
Changelog updates
Cross-platform user-facing changes
iOS user-facing changes
Android user-facing changes
Dev changes
Need help with something? Have a look at our docs, or get in touch with us.