Optional app.json component parameter to specify supported platforms for component
sveinar opened this issue · 8 comments
Proposal
In a shared test app between iOS and Android, it would be great if the app.json config schema would support an optional parameter like supportedPlatforms, which would be an array of supported platforms to display the component for.
If omitted, default, all platforms are supported and the component should be rendered for every platform. If e.g. set to to be an array of a single entry, like "android", then only show this particular component on the Android platform.
Example
"appKey": "MyAndroidPage",
"displayName": "Android tab",
"supportedPlatforms": [ "android" ],
Alternatives
None.
Implementation Details
If defined, use this parameter to hide components when the current running platform is not part of the provided array.
Additional Context
No response
Code of Conduct
- I agree to follow this project's Code of Conduct
Alternatively (additionally?) it would be nice to allow the different platforms to align on the same keys. As far as I can tell, the appKey property is used to initialize the component through various reflection-based means, but that means (implies?) that the different platforms can't share keys.
TL;DR: I have a scenario I want on all of my platforms, but I don't want N separate entries 😁
TL;DR: I have a scenario I want on all of my platforms, but I don't want N separate entries 😁
The appKey is just the key you use to register a React app, typically via AppRegistry.registerComponent. In the case of Android, iOS and macOS, we also support using said appKey to find a corresponding native class with the right interface. This particular special case happens at runtime though. None of this should prevent you from reusing the key for multiple platforms. You don't have to create separate entries if you don't want to. Is this not working as intended? What issues are you seeing?
It's entirely possible (and from your comment, highly probable!) that the issue here is on our end. @sveinar, let's take a look at our integration pattern and see if we should be doing something different now that we've combined our test apps (previously, we had separate apps for each platform, but they were recently merged into one)
Very possibly and it would be epic if the support already exists. Hoping that it is possible to resolve (via reflection) perhaps "Auth" to e.g. com.company.auth.AuthFragment for instance on Android..and on iOS, I guess the NSClassFromString("Auth") would resolve to the equivalent Auth controller right?
Very possibly and it would be epic if the support already exists. Hoping that it is possible to resolve (via reflection) perhaps "Auth" to e.g. com.company.auth.AuthFragment for instance on Android..and on iOS, I guess the NSClassFromString("Auth") would resolve to the equivalent Auth controller right?
Yes, this is how it's always been, since the very first release. You just need to make sure that your classes are appropriately named and/or exported (if you have a Swift class, you can decide what the Obj-C name is).
@sveinar, @evancharlton: Is this still needed?
Yes, but it can live on our backlog until we get around to taking action on it.
Feel free to resolve this :)
Thanks, I'll close this for now. Let me know if you want to reopen it.