surprising behavior of `supported`/`notSupported` when platform has fallback

[lobsterkatie]

Steps to Reproduce

1. Add an option to the main config/options page
2. Set the supported flag to ['javascript']
3. Build the docs
4. Go to the RN version of the options page

Expected Result

To not see the option, since RN isn't in the list of supported platforms.

Actual Result

I do see the option.

Additional Info

The reason this is happening is the logic used to decide whether or not to show a PlatformSection element (ConfigKey is just a wrapper around PlatformSection).

https://github.com/getsentry/sentry-docs/blob/ccb0eaa8bc7070b25916c568475b9a487e07de9e/src/components/platformSection.tsx#L29-L53

The isSupported() function correctly says that RN doesn't support the option. But because of getPlatformsWithFallback(), javascript is also checked, and because it does have the option, that option ends up showing up on the RN page.

There are lots of circumstances where this is exactly the correct behavior, so we may end up closing this with an "As Designed" label, but it's nonetheless surprising. Guides falling back to their platform is very intuitive. One platform falling back to another is much less so. I don't totally have an answer here, but wanted to raise it as a point of discussion for if and when we ever get a docs engineer.

[imatwawana]

Do you know if the workaround here is that we'd have to use the notSupported flag as well? This behaviour doesn't make a lot of sense to me either.

[lobsterkatie]

Do you know if the workaround here is that we'd have to use the notSupported flag as well?

Yup, that's exactly what we have to do, almost like RN were actually javascript.react-native.

[mydea]

@chargome do you know if this issue is still relevant or possibly already fixed/no longer relevant?

[chargome]

@mydea I don't think this can be issue anymore since the RN platform is completely seperated from js – couldn't reproduce it anymore!