React-native-navigation: Using MobX instead of Redux

[perrosnk]

Is anyone using Mobx instead of Redux? If yes, would it be possible to share some boilerplate?

[mastermoo]

+1

[miladebadi]

+1

[adamski]

Just started looking at MobX and I'd be interested in using it with RNN too..
+1

[adamski]

According to https://github.com/aksonov/react-native-mobx it is "framework free" so in theory should be able to use it with RNN as-is. I will try this soon...

[perrosnk]

If you could share a boilerplate if you manage to do it, it would be very helpful for the whole community I think!

[mastermoo]

@perrosnk @adamski @knot123 there u go... navigation-mobx-example.
It's based on this redux-example.

[mastermoo]

@guyca it would make sense, to add the mobX example to this repo, as well. What do u think?

[guyca]

@mastermoo Thanks for taking the initiative and making an example project. MobX sounds interesting and we're excited to hear you got navigation working with it. Are you using MobX with Navigation in production?

If it's ok with you, I'll link your project and this thread in the readme file. Adding another example project isn't feasable at this time, since we can't commit to another framework. We have a lot planned for the library and officially supporting another framework will add a lot of overhead.

[mastermoo]

Yes it's good with me.MobX is really a joy to use compared to redux. Yes, currently, I'm building a fairly complex app using Navigation and MobX. 😊Good to hear, that there is a lot planned for this library! I would really like to contribute to this repo, but I don't know any Objective C :/

From: Guy Carmeli [email protected]
Sent: Sunday, August 14, 2016 12:47 AM
Subject: Re: [wix/react-native-navigation] Is it possible to use MobX instead of Redux? QUESTION
To: wix/react-native-navigation [email protected]
Cc: Yousef Kamawall yousef.[email protected], Mention [email protected]

@mastermoo Thanks for taking the initiative and making an example project. MobX sounds interesting and we're excited to hear you got navigation working with it. Are you using MobX with Navigation in production?

If it's ok with you, I'll link your project and this thread in the readme file. Adding another example project isn't feasable at this time, since we can't commit to another framework. We have a lot planned for the library and adding officially supporting another framework will add a lot of overhead.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[stief510]

+1

[vonovak]

+1

[maxs15]

+1

[DanielZlotin]

Great work @mastermoo !
One of the changes I have planned is to separate redux/mobx/other state containers from the core of this framework.

Optimally we would have the core Navigation, and on top of it (either another npm module completely or just a different module inside the framework) some wrappers that inject the state container logic into the screens.

For example you import react-native-navigation/redux or react-native-navigation/mobx instead of react-native-navigation.

This is just an idea right now as we have far more pressing concerns. In any case, this shouldn't be hard, and far more extensible. Can be assigned to milestone 2.1.0 I think.

[grin]

@DanielZlotin though, do we even need to make RNN aware of any framework (Redux/MobX) at all?
IMHO that shouldn't be necessary (even with separate npm modules).
Instead of _registerComponentRedux and _registerComponentNoRedux functions we could have just one function similar to this:

function _registerComponent(screenID, generator, CustomWrapper) {
  const generatorWrapper = function() {
    const InternalComponent = generator();
    return class extends Screen {
      // ...
      render() {
        if (CustomWrapper) {
          return (
            <CustomWrapper>
              <InternalComponent navigator={this.navigator} {...this.state.internalProps} />
            </CustomWrapper>
          );          
        } else {
          return (
            <InternalComponent navigator={this.navigator} {...this.state.internalProps} />
          );          
        }
      }
    };
  };
  registerScreen(screenID, generatorWrapper);
  return generatorWrapper;
}

which just takes a user-provided wrapper component.
So for example, to enable Redux in your app all you'd need to do would be to add this to the app:

function CustomReduxWrapper(props) {
  return (
    <Provider store={store}>
      {props.children}
    </Provider>
  );
}

and then register a screen with this:

Navigation.registerComponent('app.ExampleScreen', () => Example, CustomReduxWrapper);

The benefit of this approach is that it removes knowledge of Redux (Provider + store) from RNN and also enables support for other frameworks.

As for MobX support, my understanding is that it's already possible by just decorating components with @observer, so no need of any work on RNN side other than maybe adding some more docs/examples.

[DanielZlotin]

Completly agree, and that was my plan. However I do think a helper wrapper
function can be useful for some.

On Sep 24, 2016 3:45 PM, "grin" [email protected] wrote:

@DanielZlotin https://github.com/DanielZlotin though, do we even need
to make RNN aware of any framework (redux/mobx) at all?
IMHO that shouldn't be necessary (even with separate npm modules).
Instead of _registerComponentRedux and _registerComponentNoRedux
functions we could have just one function similar to this:

function _registerComponent(screenID, generator, CustomWrapper) {
const generatorWrapper = function() {
const InternalComponent = generator();
return class extends Screen {
// ...
render() {
if (CustomWrapper) {
return (



);
} else {
return (

);
}
}
};
};
registerScreen(screenID, generatorWrapper);
return generatorWrapper;
}

which just takes a user-provide wrapper component.
So for example, to enable Redux in your app all you'd need to do would be:

function CustomReduxWrapper(props) {
return (
{props.children}

);
}

and then register a screen with this:

Navigation.registerComponent('app.ExampleScreen', () => Example, CustomReduxWrapper);

The benefit of this approach is that it removes knowledge of Redux
(Provider + store) from RNN and also enables support for other frameworks.

As for MobX support, my understanding is that it's already possible by
just decorating components with @observer, so no need of any work on RNN
side other than maybe adding some more docs/examples.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/wix/react-native-navigation/issues/187#issuecomment-249363019,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGWgj7cHGuHox8zbVlWT9Fl8hbZT0gXFks5qtRt6gaJpZM4Je8Sr
.

[danikenan]

+1

[holmesal]

+1

[pietgk]

+1

[megahertz]

I've created the mobx-react Provider which can be used with RNN.
https://gist.github.com/megahertz/3aad3adafa0f7d212b81f5e371863637

[bawn]

+1

[kyle-ssg]

I share @grin 's opinion on this - I think any form of coupling with things outside of react would hinder the project a great deal

[keyadesai]

+1

[justinhaaheim]

+1

[didil]

+1

[kanzitelli]

Hey guys,

I have created a small boilerplate RNN + MobX with Provider (so we can use @inject('store_name')) as @megahertz described before

https://github.com/kanzitelli/react-native-navigation-mobx-boilerplate

And if anyone is going to try it, please let me know how it goes 👍

[anhtuank7c]

@kanzitelli
Thank you so much.
You saved my day.

[avishayil]

Hey @kanzitelli , I noticed that componentWillReceiveProps does not work on observer components, like FirstTab.
Any idea why?

[yezongyang]

use componentWillReact

[drewmca]

+1

[andreaskarantzas]

+1

[ethanyanjiali]

+1

[colincwilliams]

+1

[romandubrov]

+1

[LouisJS]

+1

[kyle-ssg]

You guys should close this issue, state management has nothing to do with this project surely.

[JorgeCeja]

+1