Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41628
# Changelog:
Even though `onClick` is used on Android (e.g. via Pressability), the fact of having the handler registered didn't get through to the C++ side on New Architecture, because of being filtered out via the corresponding static view config.
As the result, there was no way to know on C++ side whether the corresponding event handler is registered for the view or not. Dynamic updates to the prop also wouldn't correctly propagate to C++, which may be a problem if a view gets e.g. the handler dynamically added.
Reviewed By: javache
Differential Revision: D51551255
fbshipit-source-id: 0783f5a27c7250f83fb357173bbe5be6213277e5
Summary:
## Summary
When transpiling `react-native` with `swc` this file caused some trouble
as it mixes ESM and CJS import/export syntax. This PR addresses this by
converting CJS exports to ESM exports. As
`ReactNativeViewConfigRegistry` is synced from `react` to `react-native`
repository, it's required to make the change here. I've also aligned the
mock of `ReactNativeViewConfigRegistry` to reflect current
implementation.
Pull Request resolved: https://github.com/facebook/react-native/pull/40787
Test Plan: Sandcastle tests
Reviewed By: noahlemen
Differential Revision: D50229257
Pulled By: javache
fbshipit-source-id: 2e848a1ac434c45e219876c1042aacb42c77cb6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39704
Default to native view configs in bridged mode and to static view configs in bridgeless mode.
Remove `setRuntimeConfigProvider` calls from RNTester and from the Template.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49687252
fbshipit-source-id: 140e1c510ba3fbc153978b59c8bb4b4e35bc7571
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39534
Fetching native view configs is computationally intensive work, so if some component has both native and static VCs, we should try static first.
This diff changes the `NativeComponentRegistry` so it tries to get static view config first, and then native view config as a fallback.
This diff also removes setting `RuntimeConfigProvider` from RNTester. As it was there for the same purpose of inverting that precedence.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D49413562
fbshipit-source-id: d65776cd43eaa97d880b76385423c65e4e8744ba
Summary:
This PR adds transform-origin support for android to make it easier to review. https://github.com/facebook/react-native/pull/37606#pullrequestreview-1513082850 by javache. I'll answer feedback from javache below.
## Changelog:
[Android] [ADDED] - Transform origin
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38558
Test Plan: Run iOS RNTester app in old architecture and test transform-origin example in `TransformExample.js`.
Reviewed By: NickGerleman
Differential Revision: D48528339
Pulled By: javache
fbshipit-source-id: e255a7f364e57396dada60b2c69c724cec406f51
Summary:
This PR adds transform-origin support for iOS fabric. This PR also incorporates feedback/changes suggested by javache in the original [PR.](https://github.com/facebook/react-native/pull/37606)
## Changelog:
[IOS] [ADDED] - Fabric Transform origin
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38559
Test Plan: Run iOS RNTester app in old architecture and test transform-origin example in `TransformExample.js`.
Reviewed By: NickGerleman
Differential Revision: D48528363
Pulled By: javache
fbshipit-source-id: 347b7c5896ad19ad24278de81b0e055e4cb01016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38746
This adds a view prop which controls the layout conformance of it and its transitive children (including non-view ShadowNodes).
The implementation here is to traverse down before layout, updating any context-specific configuration.
Normally at the time of layout, unchanged child ShadowNodes are already sealed. These must be mutated already if layout results change, and we do this today via Yoga node clone callback, where Yoga clones nodes where it will do layout work (but not all of them).
We down-propagate configuration, but can terminate if we observe an already sealed node whose values match those of our current context, since any nodes under must also follow the same contexts (or any nested contexts of the sealed node). This means that calling `layoutTree()` on a mostly clean ShadowTree will cause configuration to not traverse most nodes.
`Errata` and `PointScaleFactor` (DPI) are threaded to each Node's per-node config. The same values are retained when Yoga nodes are cloned (by cloning the ShadowNode). Since these are set before the first layout, config setting should only ever dirty layout [when layout-effecting values change](https://www.internalfb.com/code/fbsource/[1c95e981c740]/xplat/yoga/yoga/YGConfig.cpp?lines=13).
The prop is prefixed with `experimental` because we are likely to make more breaking conformance fixes in the strict mode, and I'm not sure this is the final API yet. I was previously looking at a context-like component which is more challenging to implement.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: rozele, sammy-SC
Differential Revision: D47940100
fbshipit-source-id: f72e1c73f537e0312c2bba19ae8c2e882c82aced
Summary:
Fix the following error:
{F1038388240}
Calling ```setRuntimeConfigProvider``` multiple times is not always a wrong behaviour, the following could happen and before this diff App C will raise above error:
- App A has main bundle X
- App B has main bundle Y
- App C has main bundle X and bundle Y
To fix we guarantee ```setRuntimeConfigProvider``` only called once instead of raising an error.
Changelog:
[iOS][Changed] Fix setRuntimeConfigProvider called multiple times error
Reviewed By: dmytrorykun
Differential Revision: D47094267
fbshipit-source-id: c8473f4f7d639a73e0201c6d72781c01e6cf95fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37889
Changelog: [Internal] - Add plumbing/boilerplate for an iOS implementation of the gotpointercapture and lostpointercapture events
Lets try this again: The key difference between this and D44977499 (which I previously reverted) is that in propsConversions & primitives I've ommited the "capture" versions of those methods as it was causing issues. Since we're not doing any runtime checks of those raw props it isn't particularlly necessary (at least not yet) and if we ever want to we can address that when it comes up.
The original diff description follows:
This diff simply adds the boilerplate necessary to hook up the gotpointercapture and lostpointercapture events to the fabric iOS touch handler. This diff does not contain any actual implementation of their behavior as that will occur in future diffs.
Reviewed By: adanoff
Differential Revision: D46709127
fbshipit-source-id: 339dc99e14f2e72d9116bbe84edc67cb5bfaa73b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37861
Changelog: [Internal] - Back out of "Add plumbing/boilerplate for an iOS implementation of the `gotpointercapture` and `lostpointercapture` events"
Original commit changeset: c9da5691d399
Original Phabricator Diff: D44977499
This diff appears to be causing issues as reported on T155721480 related to the file `RawPropsKeyMap.cpp` which, while I haven't figured out exactly why this is occurring, confirmed that this diff is causing the issue. In order to buy myself some more time as I diagnose this I'm backing the changes out in this diff.
Reviewed By: adanoff
Differential Revision: D46691035
fbshipit-source-id: 383b46732a3fad24a50e18ab948c96ce9bfe429e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37602
Changelog: [Internal] - Add plumbing/boilerplate for an iOS implementation of the `gotpointercapture` and `lostpointercapture` events
This diff simply adds the boilerplate necessary to hook up the `gotpointercapture` and `lostpointercapture` events to the fabric iOS touch handler. This diff does not contain any actual implementation of their behavior as that will occur in future diffs.
Reviewed By: yungsters
Differential Revision: D44977499
fbshipit-source-id: c9da5691d399f612f1980c7692c4ca62877901a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37539
AFAICT this was added in https://github.com/facebook/react-native/pull/24359 to support accessibility, however per [the spec](https://www.w3.org/TR/uievents/#event-type-click) the click event is supposed to bubble up.
This change updates the necessary configs so that `click` is treated as a bubbling event and not as a direct-dispatch event.
Changelog: [Android] [Breaking] - W3CPointerEvents: change click event from direct to bubbling
Reviewed By: yungsters
Differential Revision: D45745906
fbshipit-source-id: 2649375b322037fe7ab20b800daae150640dbede
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37305
### Stack
ARIA roles in React Native are implemented on top of `accessibilityRole`. This is lossy because there are many more ARIA roles than `accessibilityRole`. This is especially true for RN on desktop where `accessibilityRole` was designed around accessibility APIs only available on mobile.
This series of changes aims to change this implementation to instead pass the ARIA role to native, alongside any existing `accessibilityRole`. This gives the platform more control in exactly how to map an ARIA role to native behavior.
As an example, this would allow mapping any ARIA role to [`AutomationControlType`](https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.peers.automationcontroltype?view=windowsdesktop-7.0&viewFallbackFrom=dotnet-uwp-10.0) on Windows without needing to fork to add new options to `accessibilityRole`.
It also allows greater implementation flexibility for other platforms down the line, but for now, iOS and Android behave the same as before (though with their implementation living in native).
### Diff
This syncs the Fabric representations of Roles to the current state of the world in JS, and adds usage to the view configs.
1. `Role` enum for the View `role` prop (ARIA role)
2. Sync enums and conversions to JS `AccessibilityRole`
1. This parsing is done for `TextAttributes` only. `View` uses the string directly
2. Add ARIA roles, and parse those to their enum form.
3. Move enums from attributedstring primitves to accessibility primitives
3. Add to viewconfig to allow it to be passed
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D45431372
fbshipit-source-id: 0150538345bbb6cb4d9426c4eebd0f67c2a33f3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36615
Changelog: [Internal] - Add plumbing/boilerplate for an iOS implementation of the `click` event
This diff simply adds the boilerplate necessary to hook up a click event to the fabric iOS touch handler. This diff does not contain any actual implementation of the click's behavior as that will occur in future diffs.
Reviewed By: necolas
Differential Revision: D43129366
fbshipit-source-id: 71488b893c789d21c833533471745275062c0730
Summary:
## Changelog:
[Internal] -
While merging a Contributor PR in D43816768, I got curious whether such things as detecting/fixing typos could be automated.
There is a tool called [typos](https://github.com/crate-ci/typos), which, as it turns out, works very well on source code files.
The amount of false positives was minimal, most of the suggestions were valid ones.
And the total amount of typos found and fixed was **more than 300**, which is... quite a bit :)
### Methodology
* Run `typos` separately on `ReactCommon`, `Libraries`, `React`, `ReactAndroid` and `scripts` folders inside `packages/react-native`, e.g.:
```
$ typos -w --config ~/tmp/_typos.toml ~/fbsource/xplat/js/react-native-github/packages/react-native/ReactAndroid
```
Contents of the `_typos.toml` config file:
```
[default.extend-words]
collapsable = "collapsable"
NDK = "NDK"
inout = "inout"
```
(yeah, it really didn't like the "collapsable" word, for some reason ;))
* Inspect all the changes manually and revert false positives (as mentioned, their amount was minimal)
Note that most of the changes are inside things like comments and error messages, however there are a few among identifier name fixes (`typos` is actually quite smart at understanding naming conventions in code) - I kept the suggestions in cases that are local and not part of a public API. There are also misspelled file name changes in a couple of cases.
Reviewed By: NickGerleman
Differential Revision: D44172494
fbshipit-source-id: 86e27edbbb99e09135e3cdd5d7cea8ffeb8307f4
