Commit Graph

4 Commits

Author SHA1 Message Date
Adam Gleitman 8d11cb4b9c Add Dynamic Type support for iOS (Paper and Fabric) (#35017)
Summary:
This adds Dynamic Type support in iOS as described [here](https://github.com/react-native-community/discussions-and-proposals/issues/519).

`Text` elements have a new prop, `dynamicTypeRamp`, that allows users to specify which font ramp a particular `Text` element should take on as the OS's accessibility setting for text size. The different types line up with different values of `UIFontTextStyle`. If not specified, we default to the current behavior.

~~For the moment, this change is only for Paper. I tried applying a corresponding change to Fabric by adding an additional field to [`facebook::react::TextAttributes`](https://github.com/facebook/react-native/blob/main/ReactCommon/react/renderer/attributedstring/TextAttributes.h) and changing [`RCTEffectiveFontSizeMultiplierFromTextAttributes`](https://github.com/facebook/react-native/blob/afb124dcf0cdf0db525acc7cfd2cea2742c64068/ReactCommon/react/renderer/textlayoutmanager/platform/ios/RCTAttributedTextUtils.mm#L79-L84) to use that new field, but in the process I discovered that this function doesn't seem to ever get called, hence [this bug](https://github.com/facebook/react-native/issues/34990).~~

## Changelog

[iOS] [Added] - Dynamic Type support

Pull Request resolved: https://github.com/facebook/react-native/pull/35017

Test Plan:
Validated with a test page in RNTester. Screenshots follow:

A) Default text size
B) Largest non-accessibility text size
C) Largest accessibility text size, split across two screenshots due to size

| A | B | C |
|-|-|-|
| ![Simulator Screen Shot - iPad (9th generation) - 2022-10-18 at 16 17 08](https://user-images.githubusercontent.com/717674/196562746-c8bbf53d-3c70-4e55-8600-0cfed8aacf5d.png) | ![Simulator Screen Shot - iPad (9th generation) - 2022-10-18 at 16 17 55](https://user-images.githubusercontent.com/717674/196563051-68bb0e34-c573-47ed-8c19-58ae45a7ce2b.png) | ![Simulator Screen Shot - iPad (9th generation) - 2022-10-18 at 16 18 33](https://user-images.githubusercontent.com/717674/196563185-61ede5ee-e79e-4af5-84a7-8f1e230a25f8.png) |
||| ![Simulator Screen Shot - iPad (9th generation) - 2022-10-18 at 16 18 42](https://user-images.githubusercontent.com/717674/196563208-2242efa2-5f24-466d-80f5-eb57a7678a67.png) |

Reviewed By: sammy-SC

Differential Revision: D40779346

Pulled By: NickGerleman

fbshipit-source-id: efc7a8e9810a93afc82c5def97af15a2e8453d90

# Conflicts:
#	packages/rn-tester/Podfile.lock
2022-11-22 11:27:55 +00:00
Nick Gerleman 5d26ceaa23 Fixup TS Organization (#35169)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35169

This reorganizes typing structure a bit.

`Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported.

We also run into files around the renderer which are [currently overwritten](https://github.com/facebook/react-native/commits/e286da25fc83324363486eb668806aca179f74b3/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script.

Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping.

This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`).

Changelog:
[General][Fixed] - Fixup TS Organization

Reviewed By: cipolleschi

Differential Revision: D40932319

fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128
2022-11-02 14:58:37 -07:00
Aelita e0a495899d Sync new changes in @types/react-native (TextProps, TouchableWithoutFeedbackProps) (#34794)
Summary:
Sync the changes in `types/react-native` https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62394 to here as required by lunaleaps

## Changelog
[Internal] [Added] - Sync new changes in `types/react-native`

Pull Request resolved: https://github.com/facebook/react-native/pull/34794

Test Plan: Tested in `types/__typetests__/index.tsx`

Reviewed By: cortinico

Differential Revision: D39846101

Pulled By: cortinico

fbshipit-source-id: cebe62aa97f764d9a10c8371936870c515fb9be3
2022-10-03 08:01:20 -07:00
Nick Gerleman 8cdc9e7f04 Place TypeScript Declarations Alongside Source Files
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.

I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.

The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.

Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files

Reviewed By: lunaleaps, rshest

Differential Revision: D39796598

fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
2022-09-26 12:09:45 -07:00