feature: add enableRootSiblings parameter

[greedbell]

if there are more than one AppContainer in your project, root-siblings is not needed to be added to all AppContainers, so enableRootSiblings is needed.

default value: true

usage:

iOS

RCTRootView.appProperties = @{enableRootSiblings: @(NO)}

Android

AppRegistry.runApplication("appKey", {enableRootSiblings: false});

[sunnylqm]

I don't understand what is this for? You mean sometimes within one project, there might be several rootviews and not every instances need root siblings, which is injected by default? But what would be affected? In what scenario will you import this module but have to disable it? And if we indeed need a switch flag, I think we should try to figure out a way to let users to invoke it on js side. The native rootviews usually know little about js business logic, so why should it care about whether to enable the root siblings or not?

[greedbell]

You're right. I could not find a method to solve this question on js side

[sunnylqm]

Again what could be wrong without this option?

For js solution, I was thinking about an hoc like this

// withRootSiblings
export default function withRootSiblings {

}

// App.js
class App extends Component {
}
export withRootSiblings(App)

so we can control it on js side and do not have to worry about global props passing from root component/provider like redux. What do you think? @greedbell

[greedbell]

@sunnylqm Have a look at https://github.com/facebook/react-native/blob/master/Libraries/ReactNative/AppContainer.js#L97-L120, If do it like yours, Wrapper will be in the innerView, I don not known what unexpected question will happen.

[sunnylqm]

Since there is no magic with setWrapperComponentProvider -- just plain js wrapper component, so actually I mean we can deprecate the usage of this undocumented(may be changed or removed anytime) api. Use an hoc has two advantages:

1. No need to worry about the private api change(which happened before)
2. We can decide to use it or not on js side.
3. We can use the hoc anywhere reasonable, for example, on a root App component under some Provider, so no need to handle redux store anymore.
4. And we still do not insert any code into users' jsx, keep the compatibility and simplicity of this module.

My question is: What is the purpose of your pr? What issue are you trying to solve? @greedbell

[greedbell]

@sunnylqm my problem is there are more than one AppContainer in my project, and root-siblings is not needed to be added to all the AppContainer.

Your idea is good. can solve my problem too.