Support for react-native-navigation?

[META-DREAMER]

Will this library work with react-native-navigation considering that each screen is it's own react root?

[IjzerenHein]

Hi, that's a very good question! I haven't gotten around to test this, but my initial guess would be that this would indeed be possible. Assuming that react-native-magic-move can properly measure the elements, and can draw in front of the RNN screens, it should work.
It would also be necessary to create a binding that would transfer state information from RNN to RNMM. The react-navigation-magic-move binding was fairly easy to create, so I assume the RNN binding would also be easy to create.

So to sumarize

• Has it been tested with RNN? No
• Could it work as is? Probably Not
• Can it be made to work? Probably Yes

At the moment this has no priority for me as I don't use it myself, and RNN supports shared element transitions on its own. PR's and investigative work are very welcome though

[alexfoxy]

I have a snack with this working using react-native-magic-move + react-navigation: https://snack.expo.io/@alexfoxy/473def

The only problem is that when going back, or navigating to the previous scene the animation doesn't reverse.

@IjzerenHein Am I doing something wrong?

[IjzerenHein]

Sweet! That's probably because it now works when a new component is mounted. In order to make that work you'll need to control the active prop of the scene

[GioLogist]

Spent some time looking into this. It appears that the main issue is that MagicMove.Provider needs to be wrapped around the entire app. With react-native-navigation, each screen is responsible for its own HOC's, as explained here.

So, even if we register our screens as so, they still won't share their Magic.Provider value and thus have a different context. This is due to the use of this in Provider.js. The context value can't be shared among separate providers. Unlike the redux example in which store is created once and shared among all providers.

Navigation.registerComponent(
  'ScreenExample',
  () => (props) => (
    <MagicMove.Provider>
      <ScreenExample {...props} />
    </MagicMove.Provider>
  ),
  () => ScreenExample,
);

A potentially simple workaround is to allow for exporting the shared value, like redux does. So that we can pass it explicitly via MagicMove.Provider.