-
Notifications
You must be signed in to change notification settings - Fork 50
Initial nav state is always asynchronous (for Linking.getInitialUrl) #12
base: master
Are you sure you want to change the base?
Conversation
I like this change, and it seems well implemented. In most cases I think things will behave the same. But it may break things for people who expect the previous behavior of initializing the navigation state and doing another action for the URL. So I am cautious about moving forward. cc @brentvatne, should we defer stuff like this to v4? This nuance is undocumented, so we might get away with a v3 release. |
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.
Code looks good but I'll leave it to @brentvatne to decide release strategy
Thanks @ericvicenti |
@Minishlink - could you possibly write up some documentation explaining this behavior? once that's ready we can decide whether we can land it in v3 as-is, put it behind a feature flag, or defer until v4 |
Hey all, looks like this fixes some behavior I'm seeing. Any idea when this might be released? Thanks |
Any idea when this will be released? Thank you for this PR. |
Also waiting for this PR to fix the issue described on react-navigation/react-navigation#5844 |
Has this issue been fixed already? Should I just update react navigation? Thanks! |
Hey, is this fixed yet ? |
Can this PR be updated to resolve the conflict and merge ? |
Unless there is a core contributor who wants to merge this, I probably won't update it until I upgrade one of my projects to RNav 5 (two to four weeks), feel free to do another one :) |
Follow-up of react-navigation/react-navigation#4213