Summary:
Found and removed duplicates of the word "the" in comments.
## Changelog
[Internal] [Removed] – Removed duplicates of the word "the" in comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/34807
Test Plan: Not applicable.
Reviewed By: yungsters, cipolleschi
Differential Revision: D39880587
fbshipit-source-id: b7277aa70604902929903c31ab69d4c532f2667a
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
Summary:
Added a null check to native.value in Switch to fix regression from RN 66 -> stuck operation in mViewCommandOperations list in Android Release on initial layout of a screen with Switch component. If approved, please incorporate this fix into an RN 66 release.
## Changelog
[Android][Fixed] - Added a null check to native.value in Switch to fix https://github.com/facebook/react-native/issues/32594
Pull Request resolved: https://github.com/facebook/react-native/pull/32602
Test Plan: To reproduce, put a log in UIViewOperationQueue in dispatchViewUpdates you can see that the RetryableMountingException is no longer thrown for a screen with the Switch component on Android Release. As a result, mViewCommandOperations no longer has a stuck operation on initial layout.
Reviewed By: charlesbdudley
Differential Revision: D34397788
Pulled By: lunaleaps
fbshipit-source-id: 1cee3516fb987942dfa50ad1f2d11c965a947f05
Summary:
Changelog:
[Internal] - Replace `useImperativeHandle` usage with new `useMergeRef` which will keep both the forwarded and internal ref handle up to date (in case the instance ever changes). That being said, this change was not motivated in fear of a stale ref but more an intention to show that `useImperativeHandle`'s use case is more about creating a selective API and `useMergeRef` is better suited for publishing ref updates.
Reviewed By: yungsters
Differential Revision: D28950632
fbshipit-source-id: 594afda02693545aab77f24566180c338b58bb8b
Summary:
Since moving Switch to a function component it is no longer possible to get the native switch ref. This adds forwardRef so it is possible again.
## Changelog
[General] [Fixed] - Fix Switch ref forwarding
Pull Request resolved: https://github.com/facebook/react-native/pull/31629
Test Plan: Tested the change in an app using react-native-gesture-handler, which tries to set a ref on Switch. Also made sure flow still passes.
Reviewed By: TheSavior
Differential Revision: D28839605
Pulled By: lunaleaps
fbshipit-source-id: 1fee86145caeabb60c0010bb9062dddca419f7ca
Summary:
Changelog:
[Internal] - Update Switch to allow injected implementations
## General understanding of the component
The main flow of Switch is pretty straightforward, basically passing the props to the respective native component which uses the platform switch views on Android / iOS
The interesting parts of Switch is the fact that it's a controlled component -- meaning that this component sees the JS value prop as the source of truth about the state of this component and any time the native value of the switch is out of sync with the JS value prop, we send a command `setNativeValue` to keep those in sync.
The problems I ran into:
* Keeping native and JS in sync
* Switch skips animation occassionally on iOS simulator
## How we keep native and JS in sync
By construction, the native value of the component should be the same as JS value. Then, we know the native value has changed whenever the callback `handleChange` has been fired.
**Before**
In the handleChange callback, we'd set an [instance variable `lastNativeValue` with the updated value](https://fburl.com/diffusion/nangxzoh) and force update. Then, in `componentDidUpdate`, we'd send the native commands if we determine that `lastNativeValue` and the `value` prop were out of sync.
**After**
For our modern implementation, we store the value of the switch as reported by `handleChange` and check it against the `props.value` of the switch. If they are out of sync then we will update the native switch via the switch command.
**Why is `native` an object?**
We need to run the `useLayoutEffect` every time `handleChange` is called independent of the value of the switch.
**Why not move the logic of dispatching commands to `handleChange`?**?
This would change behavior from old implementation where we would call `onChange` handlers and then re-render. Additionally, the logic to run the native commands were on `componentDidUpdate` which would've run when any prop changed. We can simplify this down to caring only when `props.value` updates.
## Unsolved, existing issue: Switches skip animation occasionally
* This occurs both in the modern and old versions of Switch and I've only seen this on iOS simulators. It occurs most frequently in the "events" example where two switches' values are synced and most often the first transition after we navigate to the example surface. I have not been able to reproduce this behavior on device.
* Something must be triggering a re-render in the middle of native's animation..
{F564595576}
Reviewed By: nadiia, kacieb
Differential Revision: D27381306
fbshipit-source-id: 06d13c6fe1ff181443f4b8dd27fb1ac65e071962
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
Our Babel plugin that strips irrelevant platform-specific code does not currently know how to deal with early return statements.
This minor change to a couple call sites enables the output bundle for Android to omit code specific to iOS.
Changelog:
[Internal]
Reviewed By: ejanzer
Differential Revision: D24139922
fbshipit-source-id: 467c0c38dd45679b889a8a94d85f73fd969e5b36
Summary:
Fixes https://github.com/MLH-Fellowship/react-native/issues/60
The PR is part of an effort to update the code comments to match the current documentation on the React Native website. The project is a part of the MLH Fellowship program and involves the automatic generation of the website docs from code comments and flow types as the end result.
To learn more about the project you can visit the project wiki:
- [Project Details](https://github.com/MLH-Fellowship/0.4.x-projects/wiki/React-Native-Flowtype-API-Docs-Generator)
- [RN Docs Standards](https://github.com/MLH-Fellowship/react-native/wiki/RN-Docs-standards)
Link to the documentation(the source of truth):
- [switch.md](https://github.com/MLH-Fellowship/react-native-website/blob/master/docs/switch.md)
## Changes
* Update the title and prop description from docs.
* Remove unnecessary `*` from the code comments.
* Add Snack player example specified in the docs to the code comments as JSDoc.
* Add `type` annotation to parse supported datatype by the prop.
* Add `platform` annotation to specify platforms supported by a prop.
* Add `default` annotation to parse default value of prop.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/29546
Test Plan:
All changes are made to the code comments and thus there is no need for testing.
Reviewed by jevakallio
Reviewed By: cpojer
Differential Revision: D22921438
Pulled By: motiz88
fbshipit-source-id: eaab1e04252c15d7d3dd18a2b162fa97a4478dd6
Summary:
Currently the schema only allows to exclude a single platform (iOS OR Android). There are cases where we need to exclude multiple. This change converts the previous `excludePlatform` string property into an `excludePlatforms` array.
Changelog:
[Internal][Changed] - Added support to exclude multiple platforms in Codegen.
Reviewed By: sammy-SC
Differential Revision: D21426950
fbshipit-source-id: eff36ffa207109274794b4b300bf6313f8286161
Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.
Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet
Reviewed By: TheSavior
Differential Revision: D21076969
fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab
Summary:
Fabric doesn't support setNativeProps, so we are using view commands instead.
Changelog: [Internal]
Reviewed By: JoshuaGross, TheSavior
Differential Revision: D17736672
fbshipit-source-id: bb0eee9330c01751829172bbc03bfd12b1e24cad
Summary:
`accessibilityRole` communicates the purpose of a component to the user of assistive technology. It needs to have the correct value for it to be fully utilized.
Switch component has `accessibilityRole` of a `button` instead of `switch` on default. Change the component default role to `switch`.
## Changelog
[General] [Fixed] - Change default `accessibilityRole` of Switch component from `button` to `switch`
Pull Request resolved: https://github.com/facebook/react-native/pull/26899
Test Plan:
- All unit test passed
- On Switch component, it's supposed to have `switch` like element type on both platform. (`XCUIElementTypeSwitch` on iOS)
fix [https://github.com/facebook/react-native/issues/26873](https://github.com/facebook/react-native/issues/26873)
Reviewed By: yungsters
Differential Revision: D18002755
Pulled By: mdvacca
fbshipit-source-id: 60446f94b23f8355f954805fb4dc08c89d08e492
Summary: Fabric doesn't support setNativeProps, so we have to use commands instead to set the value of the native component.
Reviewed By: JoshuaGross
Differential Revision: D17736274
fbshipit-source-id: 18c47365926c3c2cfc3551f4b5b6cc72e4162367
Summary:
In this diff we integrate the Switch component on Android in Fabric. Since the component has a custom measure function, we need to write some C++ to call the measure method in Java.
The component isn't fully functional yet (setNativeProps isn't supported in Fabric) and has some problems with measuring itself. I will fix the component in the next diffs in this stack.
Reviewed By: JoshuaGross
Differential Revision: D17571258
fbshipit-source-id: be4e201495b9b197ddec44ee3484357bfb6225a8
Summary:
We need to migrate to HostComponent instead of the exported type from codegenNativeComponent which is the same type
Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent
Reviewed By: rickhanlonii
Differential Revision: D17563307
fbshipit-source-id: 01c8fea8c67b33bed42ae28ffb8c132be87b9a7a
Summary:
We need to migrate to HostComponent, this is the first batch.
Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent
Reviewed By: rickhanlonii
Differential Revision: D17562879
fbshipit-source-id: ce1993b64a79cede3598c89ddff0dadf07fde92f
Summary: This diff migrates `ReactSwtichManager` to use the generated `ReactSwtichManagerDelegate` for setting its properties.
Reviewed By: TheSavior
Differential Revision: D17395067
fbshipit-source-id: 1489c5d08cef860030ecbd23ef19bd8de1328d71
Summary:
We used to generate the documentation for the website but moved the docs to another repo.
There is some work on the docs to be able to ingest info from this repo in order to go back to generating API information. The current thinking is we will generate this JSON file and the website repo will pull it in to generate the docs.
I plan to make the script run on CI and fail if the generated file isn't updated, in a follow up PR.
Reviewed By: zackargyle
Differential Revision: D17183936
fbshipit-source-id: 99ce3fa5d7becc0ef20df5d439b175eedbe546f3
Summary:
In Windows, if you clicked on a Switch component to toggle it, you could see it "shimmy" back and forth once before settling. The native Switch ends up toggling three times every time it's invoked.
`Switch.js` prevents the native switch from toggling to the new value by explicitly setting the switch to `this.props.value` when it receives an `onChange` event. The re-setting of the value wasn't fast enough to prevent the `Switch` from starting to toggle, causing the visual shimmy.
The solution is taken from `TextInput`. `TextInput.js` stores `_lastNativeText` when it receives an `onChange` event. In `componentDidUpdate`, it puts `this.props.text` back on the native textbox if the value of `this.props.text` isn't the same as `_lastNativeText`, which is how it ensures that it is a controlled component. Porting this to the `Switch` results in only one toggle happening per invoke, removing the shimmy, while preserving the controlled component behavior.
This bug is not visible on Android or iOS, only Windows, however the code causing the bug was in `Switch.js` and it seems reasonable to avoid changing the value of the native switch excessively.
## Changelog
[General] [Fixed] - Fix excessive toggles on the Switch component
Pull Request resolved: https://github.com/facebook/react-native/pull/26496
Test Plan: Used RNTester on Android and iOS to test the Switch component and made sure that all scenarios behave as expected visually. Also ensured through the debugger that the value of the native switch is only being changed once, instead of three times.
Reviewed By: TheSavior
Differential Revision: D17468905
Pulled By: JoshuaGross
fbshipit-source-id: 92bf511510306968c3573ee4eed6df009850fd77
Summary:
Need to add explicit type annotations in these areas to unblock types-first architecture for Flow. These are locations the codemod could not automatically handle.
I'll call out areas I need a close eye on in the comments.
Reviewed By: panagosg7
Differential Revision: D16659053
fbshipit-source-id: 167dd2abe093019b128676426374c1c62cf71e7f
Summary:
`WithDefault` appears not to be required to be prefixed with `?` because it's option value per se.
Fixed tests, removed `?` where needed, updated snapshots and review them. Added mechanism fro throwing error when `?WithDefault` found. Add tests for it.
Reviewed By: rubennorte
Differential Revision: D16048463
fbshipit-source-id: f55ed7454aacf0b8c42944a9b5c1037ad1b360fe
Summary:
It appears that `(e: BubblingEvent<T>) = mixed` exists only in given context and it's pointless to keep in this way. It could be simplified to `BubblingEventHandler<T>` without any negative consequences and that's the motivation of this diff.
The only tradeoff of this decision is leaving an opportunity to declare Bubbling/Direct event in the top of the file bc then analysing the code becomes much more difficult. However, it's not used anywhere so it's not a problem now and probably any time.
Also, changes the names to `DirectEventHandler` and `BubblingEventHandler` which are more related to current state. The names were updated in many places in code.
Reviewed By: rubennorte
Differential Revision: D16054571
fbshipit-source-id: 741d075eb46b80bac8eb73a6b30fc0b448cb3902
Summary: These files are no longer needed since all files codegen'd use flow types as the source 🎉
Reviewed By: cpojer
Differential Revision: D15961378
fbshipit-source-id: 510a298b2e97cd78a9a3648cbaa239e8134daa75
Summary: The schema for these view commands is lifted wholesale from the schema for TurboModules: P67239314
Reviewed By: rickhanlonii
Differential Revision: D15943109
fbshipit-source-id: a0ccd4e47067b62970218df6a32527c15868c4a5
Summary:
This diff removes an option from the codegen and replaces it with two new options
Removes:
- `isDeprecatedPaperComponentNameRCT`
Adds:
- `paperComponentName`: a better version of the removed option that allows more than just adding RCT
- `paperComponentNameDeprecated`: a new option that allows migrating native code to a new name
```
// Use for components with no current paper rename in progress
// Does not check for new name
paperComponentName?: string,
// Use for components currently being renamed in paper
// Will use new name if it is available and fallback to this name
paperComponentNameDeprecated?: string,
```
For example, Slider uses `paperComponentName: 'RCTSlider'` because it has a different name in fabric but is not currently being migrated to a new name. Because of other work in progress, we don't want to use UIManager check if we don't need to
Reviewed By: shergin
Differential Revision: D15857629
fbshipit-source-id: ca0d3b7dc4a75e00d136ae1f5c84f7423960399d
Summary: This diff turns on codegen for Slider and Switch
Reviewed By: TheSavior
Differential Revision: D15738544
fbshipit-source-id: a0dfb5b05fd62f28fc3865855986e49598dd5e19
Summary:
Adds a generated view config for iOS Switch
Note: this required some refactoring because the SwitchNativeComponent file included both iOS and android componets, so I broke them out into:
- AndroidSwitchNativeComponent (not generated)
- SwitchNativeComponent (generated)
The schema that we're using is for the iOS version so that's the config that's generated here
Reviewed By: cpojer
Differential Revision: D15495402
fbshipit-source-id: 07b3bc9c780cbf8f6cbf66e976e15981cefcadfa
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
There's a bug in the OSS Switch component where the track color value is reset to the default value when the switch is toggled. It looks like the Java class resets the track color value in `setOn` (which fires in a press event): https://fburl.com/vmugfzja but these values aren't actually initialized from JS - in Switch.js we only pass through the current track color: https://fburl.com/vytekd0o.
The React component already has an API for defining both true/false track colors. However, we should also make sure not to reset these values for people using the old API of `tintColor`/`onTintColor`, so I'm changing it to only reset the value when both of those props are null.
Reviewed By: mdvacca
Differential Revision: D14035007
fbshipit-source-id: 12d968076bd47d54deedbfc15b12ff3cd77e2fd0
Summary: This is the first step in organizing React Native slightly differently. This doesn't set up a "monorepo" structure for the GitHub repo yet, it merely moves a few files around and I slightly updated the package.json file for the codegen project.
Reviewed By: rickhanlonii, TheSavior
Differential Revision: D13974180
fbshipit-source-id: f53375f3b6618ef12658064cb1fc690ef1f95299
Summary:
Refactoring the codegen buck target from being used just for testing to a way that can be depended on for the real fabric target to replace the existing component code.
After this change, we can build a target for react native to use the codegen to create the native files for Switch. A follow up diff will be necessary to hook this up and actually replace the native files for switch.
Reviewed By: mdvacca
Differential Revision: D13662363
fbshipit-source-id: 599dd9ed9ca24ffb5c5784396f4bee7457d94d6d
Summary: On Android, `Switch` does not currently read its role as a "button". This fixes that and makes it consistent with iOS.
Reviewed By: sahrens
Differential Revision: D13136253
fbshipit-source-id: 0de5d54772d204168138cb2af7815cc458f72682
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary: Moving out the requireNativeComponent call into a new file. We want this long term for all of our view managers to support codegen of the native side and so we can move the viewConfigs into JS.
Reviewed By: yungsters
Differential Revision: D9191214
fbshipit-source-id: d0bddbb50bb1cf6b5a727d72faf834b007ad9440
David
Tim Yung
Vic
Nick Gerleman
jonathanmos
fabriziobertoglio1987
Andres Suarez
Luna Wei
Janic Duplessis
Micha Reiser
Tim Yung
Aniket Kumar
João Vieira
Zack Argyle
Jesse Katsumata
Eli White
Samuel Susla
Oleksandr Melnykov
Matias Alvin
Ruriko Araki
Logan Daniels
Michał Osadnik
Rick Hanlon
James Ide
Emily Janzer
Christoph Nakazawa
Radek Czemerys
Héctor Ramos