Memoize theme creation for iOS, macOS, android

[lyzhan7]

Platforms Impacted

• iOS
• macOS
• win32 (Office)
• windows
• android

Description of changes

There was a suggestion in PR #2483 to memoize the method creating the default theme to prevent the method from creating a new theme object every time it's called. This PR is just making the same change for the iOS, macOS, and android themes.

Verification

CI/automated tests should pass. No visual changes.

Pull request checklist

This PR has considered (when applicable):

• Automated Tests
• Documentation and examples
• Keyboard Accessibility
• Voiceover
• Internationalization and Right-to-left Layouts

[Saadnajmi]

Looks good to me, I'd make sure that fluent tester still responds to light/dark OS changes properly if you haven't. Or High Contrast

[lyzhan7]

Looks good to me, I'd make sure that fluent tester still responds to light/dark OS changes properly if you haven't. Or High Contrast

Ooh thanks for bringing that up, I checked that iOS light/dark mode still looks right to me (looked at the shadows test page) - but actually think macOS might not work since that method doesn't have the appearance as a parameter to the method. If a memoized method doesn't take in any arguments then I think it will only ever be created once? Checking macOS now

[lyzhan7]

Double checked and confirmed that switching appearances in macOS is broken with this change, going to mark as a draft until I come up with a fix. Thinking I'll move the existing calls to getting the appearance up the call stack so that we pass the appearance through the method parameters.

Also this seems like something the PR checks should be able to catch, will also look into add more dark mode tests or maybe make a work item for this

[Saadnajmi]

Double checked and confirmed that switching appearances in macOS is broken with this change, going to mark as a draft until I come up with a fix. Thinking I'll move the existing calls to getting the appearance up the call stack so that we pass the appearance through the method parameters.

Also this seems like something the PR checks should be able to catch, will also look into add more dark mode tests or maybe make a work item for this

Oh yeah, we set up the macOS theme (and others) to call theme.invalidate() whenever the OS appearance changed, forcing a recreation of the theme object. You should be able to see that logic in createAppleTheme.macos.ts.

[lyzhan7]

1. Updated macOS to get the mode when the theme is first created, and pass that object down to the creation of shadows/colors

   • Note - not really sure what mode vs. appearance refers to, but appearance is generally used as the name for the return value from getColorScheme() and mode is generally used as the name of the return value from getCurrentAppearance())
   • Confirmed that this gets macOS light/dark mode working after the memoize change

2. I'm thinking of making the equivalent change for iOS/Android. I have the changes done locally, but wanted to get the macOS changes looked at first.

   • My understanding of the different platforms is that macOS supports light, dark, high contrast, and dynamic, while ios/android only support light/dark (for now). Does it make sense to be passing down an AppearanceOptions object in iOS/android the way macOS is now set up? Right now in some of the iOS/android code I think we've assumed that if the appearance isn't light, it's dark. In order to make the equivalent change for macOS on iOS/android there will be a couple places where we can potentially have an appearance that doesn't make sense (high contrast) - I can add the error handling for this but just wanted to check this is still the right approach to take.
   • For reference, here are some of the relevant types related to appearance:

// defined by react native
ColorSchemeName = 'light' | 'dark' | null | undefined;

// defined in theme-types
AppearanceOptions = 'light' | 'dark' | 'highContrast';
ThemeOptions[‘appearance’] = AppearanceOptions | ‘dynamic’;

3. (Kind of related to 2) For iOS dark elevated colors, I wonder if we would we add that as an option to the AppearanceOptions interface? We'll run into a similar issue with other platforms where we could be setting a theme that doesn't exist on platform
4. I'm thinking of removing appleShadows.macOS.ts/fallbackAppleShadows.ts altogether, and calling createMacOSShadowAliasTokens directly from AppleTheme.macOS.ts
5. I actually don't think we have any dark mode tests (just doing a search for "dark" in *.test.tsx files - nothing comes up) right now - I'm hoping I can add a simple test that fails when the wrong token values are used for dark mode, for more thorough testing will make a work item for this

[lyzhan7]

For 2, 4, and 5 above will follow up in a later PR