-
Notifications
You must be signed in to change notification settings - Fork 44
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
Nested StackReducers and BackAction #77
Comments
@domchristie See facebook/react-native@807726b—NavigationExperimental has no intention to support hierarchical states. I also think reducers belong to user-level code, and the ones currently shipped with NavigationExperimental should be simplified and moved to UIExplorer for reference impl. Otherwise supporting everyone's use cases is a very quick path to a very bloated codebase. Also, docs may be forthcoming. @ericvicenti @hedgerwang What do you guys think? 🍺 |
@jmurzy : tl;dr; For navigation actions at high level, reducers from NavigationReducers does not There are a lot of good libraries available that help people to reducing things if that's At the low level, for navigation state changes that don't involve app-specific state, NavigationReducers serves very little benefit cause it does not know the app state, it does That said, we hold no interest in owning in the core navigation library. |
@hedgerwang My thoughts exactly. Thanks! 🍺 |
Thanks for the clarification. I had seen facebook/react-native@807726b, and was aware that some of the NavigationExperimental parts were going to be deprecated (e.g. containers), but I wasn’t entirely sure if that would impact reducers (I had not seen facebook/react-native@69627bf until now).
I think it’s a bit of a shame that the project has taken this stance, since even the most basic app will usually require some form of navigation. However, having worked on creating a navigation library for the app I’m working on, I can understand the reasoning—dealing with the multitude of navigation permutations is far from straightforward! I look forward to checking out the new approach with the new examples :) In the mean time, would it be worth clarifying the state of navigation in the README? It seems that a significant part of the API is deprecated (whether you use For what it’s worth, I handled the Nested StackReducer + BackAction issue by wrapping the stack reducer in another reducer. Something like: const stackReducer = NavigationExperimental.Reducer.StackReducer({…})
function navigationReducer (state, action) {
if (action.type === 'BackAction') return navigateBack(state, action)
else return stackReducer(state, action)
}
|
@domchristie : navigate states don't necessarily need to be nested. So how would you model the navigation states?
then you can build the reducer around it.
the full snippet can be found at https://gist.github.com/hedgerwang/4c9cc24b729d0787a1558ff47f0ca439. |
@hedgerwang sorry to bring this back but I'm having trouble in modelling some nested Navigations. |
I am using nested StackReducers to achieve the following navigation state (one for the 'main' stack, the other for the '_conversations' stack):
I’d expect that dispatching
{ type: 'BackAction' }
would pop the inner-most active state:But instead it affects both stacks resulting in:
Is this the correct behaviour? If so, are there any techniques to prevent the action from being handled by an outer stack?
Thanks!
(Related: facebook/react-native#6963)
The text was updated successfully, but these errors were encountered: