Question: do we benefit anything (performance,...?) from using this package than normal RN Views?

[jarvisluong]

[hssrrw]

I have the same question. What is the difference between mounting/unmounting view components and attaching/detaching screens?

I can assume detaching keeps shadow nodes for JS while removing a view from memory on the native side. If that's true — it's awesome!

[sapjax]

same question

[joshjhargreaves]

This tweet should provide some answers! https://twitter.com/janicduplessis/status/1039979591815897088?s=21.

Also, it should almost certainly reduce overdraw on Android too.

[kmagiera]

Hey everyone! Sorry for not communicating this well enough. I'll make sure to add some information about that to the docs in the next few days. My original idea was for this package not to be use as a direct dependency but instead to be pulled in by navigation libraries, in which case most of the people wouldn't even need to know it exists. Apparently since we want to make the transition more gradual (explicit opt-in) some words of reasoning behind this package are required.

[ovy9086]

@joshjhargreaves that is some valuable insight. Thanks!
@kmagiera thanks for this library, I also listened the ReactNative podcast where you where invited.

But I still have some troubles understanding fully what is going on under the hood.

I pulled the repo and I ran the example, and placed some logging. For instance, in the stack example, we push 4 screens on top of each other, but I see that even when setting the 4th screen on the stack as active, I still get render() being called on all the previous 3 screens. Also what I am seeing is componentWillUnmount() is not triggered for those. This also means that any updates to a redux-store would still trigger renders & updates in those screens, that are now not "active" ( visible ).

Coming from an Android background, I was somehow not expecting this, I was hoping for something similar to Fragments being stopped/view destroyed once they are no longer visible. So yeah, I think some more documentation / explanations are welcome 😃

I was paying close attention to this, as I was hoping I will be able to achieve some shared element transitions between screens more easily using Screens , than we currently can using react-navigation.

[hssrrw]

@ovy9086 Views get detached on the native side while it doesn't effect the react tree and its components. React works the same way as if the views existed. This is actually the magic the library brings to us 😊 I guess the goal is to reduce memory consumption while keeping react components fully active.

If you just want to unmount a component, you don't need the Screens.

[kmagiera]

Thanks @hssrrw for responding. This is a great answer!

@ovy9086 as mentioned if you want your components to unmount you can use navigation events in react and conditionally render the content of screen (e.g. if screen is active you render screen component and if not you render null). Note that both in native Android and iOS the way navigation screen work is very similar. That is the views on screens down the hierarchy are kept in memory and their state is preserved.

[chirag04]

@kmagiera - I couldn't tell if react-native-screens supports brownfield integration into existing native navigation setup. Possibly a wrong thread, but is that one more benefit of using this library or maybe in future?

[kmagiera]

It all depends what type of navigation solution brownfield app uses. The typical setup is that brownfield uses already native navigation containers for displaying RN screens. In such a case the app won't benefit from using screens. One example when it would still make sense is if your RN code renders view containers (e.g. tabviews) on any of the screens launched via native navigator. In that case rn-screens-controller tabview should perform better than pure RN View based solutions.