Summary:
By depending on react-native, these files can't be flow strict until index.js is flow strict. By depending on the internals directly they can be flow strict as soon as their dependents are flow strict.
Changelog:
[Internal] Refactoring some core file imports to depend on internals directly
Reviewed By: zackargyle
Differential Revision: D18828324
fbshipit-source-id: 2a347c4e234a64edbb3e6f0ef6387ef1ce78badc
Summary:
Currently we generate Java ViewManager interfaces and C++ classes for iOS regardless whether the component is supported on platform or it isn't. This adds an option to exclude either iOS to Android in order to avoid this.
Changelog: In codegen it is now possible to exclude one or the other platform
Reviewed By: rickhanlonii
Differential Revision: D18217185
fbshipit-source-id: 1c569b92c92a5b991c96b0abdff6b8ed395e449f
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
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: This diff fixes the error message in the codegenNativeComponent fallback
Reviewed By: TheSavior
Differential Revision: D16579775
fbshipit-source-id: 176f81ea91e11f671407a5e5e5b000c4b83f93b2
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 updated the codegen flow types syntax replacing:
```
type Options = {
isDeprecatedPaperComponentNameRCT: true,
};
type ActivityIndicatorNativeType = CodegenNativeComponent<
'ActivityIndicatorView',
NativeProps,
Options,
>;
module.exports = ((requireNativeComponent(
'RCTActivityIndicatorView',
): any): ActivityIndicatorNativeType);
```
with:
```
export default codegenNativeComponent<NativeProps>('ActivityIndicatorView', {
isDeprecatedPaperComponentNameRCT: true,
});
```
This is from Tim's comment in the [View Config Codegen Quip](https://fb.quip.com/jR2aASHad4Se):
> What it CodegenNativeComponent were instead `NativeComponent.fromFlow<T>('…')` that returned `'...'`?
>And the Babel plugin swapped it for NativeComponent.fromSchema('...', {…}) which would both register and return '...'?
I went with `codegenNativeComponent` because it has nice parity with `requireNativeComponent`
I also didn't update the babel output here (we can update that whenever) because I think `registerGeneratedViewConfig` is more clear for what it's doing
Reviewed By: cpojer
Differential Revision: D15602077
fbshipit-source-id: 2d24dc32136ba6d31724f8c929b51417ba625a58
Eli White
Samuel Susla
Andres Suarez
Logan Daniels
Rick Hanlon