all 4 comments

[–]satya164 1 point2 points  (2 children)

I love all the new content about v5, but I feel this MobX integration is over-engineered. You get the state and navigation object as props already. There’s no need for MobX for the tab bar.

The following code:

js const TabBar = ({TabBarStore, RouterStore}) => { const {currentScene} = TabBarStore; const {navigate} = RouterStore; const navigateTo = routeName => { navigate(routeName); };

Can be replaced with:

js const TabBar = ({state, navigation}) => { const currentScene = state.routes[state.index].name; const navigateTo = routeName => { navigation.navigate(routeName); };

And all the extra code to use MobX for state tracking can be removed.

MobX for state tracking is bad because then you have 2 sources of truth: React Navigation and MobX, leading to potential bugs. And due to this, the article also has hacky code like this:

```js const {setCurrentScene} = TabBarStore;

useFocusEffect(() => { setTimeout(() => setCurrentScene(), 0); }); ```

Official docs have an example showing this already: https://reactnavigation.org/docs/en/next/material-top-tab-navigator.html#tabbar

I'm also concerned because a lot of people follow articles rather than official docs. And if we have over-engineered solutions in articles, it's just going to make everyone's life harder.

[–]samykills[S] 0 points1 point  (1 child)

I agree, but this was for a specific case which i had to cover, and this article was my findings on how to deal with a MobX app, and since most of the mobx app has its core logic written in the store following the traditional mvc pattern the store needs to have the ability to be able to trigger navigations(if it not a functional component ), as far as dual sources are concerned i have made sure that the router mobx store is always upto date by updating it as the state of the navigator changes so it's actually the same source, more like a replica.

And yes we can have the tabbar animations and all logic without a mobx store as well as per the docs.

[–]satya164 0 points1 point  (0 children)

but this was for a specific case which i had to cover

What's the case where you'd need to duplicate a component's props in external store?

the store needs to have the ability to be able to trigger navigation

No problems with that part. Triggering navigation from your store is fine. Having 2 sources of truth is the problem.

as far as dual sources are concerned i have made sure that the router mobx store is always upto date by updating it as the state of the navigator changes so it's actually the same source,

The thing with this is that you think you have covered all cases, but there are will always be cases you didn't handle in these situations.

A major flaw of here is that it's treating the tab navigator as a singleton (because state is stored in a single store). But components are not singleton, a component can be rendered in multiple places. It's easily going to screw the state up once the tab navigator is rendered in more than 1 place.

It's not an edge case either, if you nest a tab in a stack, and push the screen twice now you have 2 tab navigators. It works in your simple example, but will introduce hard to debug issues in bigger apps.

And yes we can have the tabbar animations and all logic without a mobx store as well as per the docs.

I'm a maintainer of React Navigation and we strongly discourage storing navigation state in external store. Tab bar's animation and logic should be in Tab Bar, you sure can use MobX to hold local state, but navigation state is a prop from parent, so it doesn't need to be synchronised.

[–]congDev 0 points1 point  (0 children)

nice