Summary:
Migrates `CodegenTypes` and its transitive dependencies to Flow strict to unblock this mode in Native Modules and Native Components.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D25540629
fbshipit-source-id: 7bed2ee58af7a789b50932734c7a86cf1719e2c5
Summary:
This new type will be valid in Flow strict mode and can be used by native modules and components to replace `Object`, with the same semantics.
This unblocks the migration of the most modules in the React Native package to Flow strict.
Changelog: [Internal] Add UnsafeObject type compatible with Flow strict mode to use in native modules and components
Reviewed By: RSNara
Differential Revision: D25540631
fbshipit-source-id: 60b80bbc84a53aecc747e3a1799cdf551e1859cd
Summary: I realized my previous diff was incomplete. Adding parsing and generation code for Double for props, commands, and events.
Reviewed By: rickhanlonii
Differential Revision: D16823540
fbshipit-source-id: fbed9897bb84b789c502cf4153e81060590152b8
Summary:
returning type of Bubbling and Direct Event should be always void of Promise (if async). Other situations shouldn't be permitted.
Reformated all cases when it the function wasn't void.
Reviewed By: rickhanlonii
Differential Revision: D16165962
fbshipit-source-id: 7c1377c3ed4bd54a431a13e5bcda4f7ec0adf4dc
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:
This diff adds a way for the codegen to handle view configs with non-standard top event names by adding a `paperTopLevelNameDeprecated` field to events in the schema.
## The problem
The problem this is solving is that Android host components build their own options for event settings in the view config. So instead of enforcing `onChange` to use the top level event name `topChange` like iOS does, Android can use `change` or `forbarChange` or anything the person adding the component wanted at the time:
```
// Expected
topChange: {
registrationName: 'onChange',
},
// Android
bringBackStargateYouCowards: {
registrationName: 'onChange',
},
```
This is possible because of the way Android builds these settings
```
// On iOS, notice that there's no option to change the top level name:
RCT_EXPORT_VIEW_PROPERTY(onChange, RCTDirectEventBlock);
// On Android, you provide the top level event name
Override
public Map getExportedCustomDirectEventTypeConstants() {
return MapBuilder.of(
"bringBackStargateYouCowards",
MapBuilder.of("registrationName", "onChange"));
}
```
Since the codegen does not allow us to specify the top level event name (similar to iOS), we don't have a way to customize the names to support android
## The solution
To fix this, we're adding an extra option the event flow types:
```
onBubblingChange: (event: BubblingEvent<Event, 'customBubblingName'>) => void,
onDirectChange: (event: DirectEvent<Event, 'customDirectName'>) => void,
```
These will register **both** top level names in the view config:
```
{
directEventTypes: {
// Notice the same registration name is configured for different top level events
topChange: {
registrationName: 'onChange',
},
bringBackStargateYouCowards: {
registrationName: 'onChange',
},
}
}
```
This means when either `topChange` or `bringBackStargateYouCowards` fires it will call the onChange listener. **This gives us the flexibility to rename the native event name without breaking backwards compatibility.** Old apps will work when `bringBackStargateYouCowards` is fired, and new apps with an update will work when `topChange` fires.
Note: only the correct name will be generated for Fabric so technically we don't even really need to migrate the paper names and this prop can be deleted when paper is gone.
Reviewed By: cpojer
Differential Revision: D16042065
fbshipit-source-id: 40d076b43ffbbfc6c65c3c19de481d922a2add62
Summary:
view config RCTStickerViewNativeComponent
had to get one view config in before I left London lol
Reviewed By: rickhanlonii
Differential Revision: D15825774
fbshipit-source-id: 846d9ee1d15f6ec64d88a1af7b72fd863ae10afc
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
Summary:
This diff initializes the codegen flow parser using a proposal for some new syntaxes in flow file to handle missing information like:
- Float vs Int32
- Bubbling Events vs Direct Events
- Default props
- Codegen options
- Specifying the component name
For a deep dive on the proposal see: https://fb.quip.com/kPYJAjCHxlgO
Note: there are still some todos to follow up with:
- Array props
- Enum props
- Object event arguments
Note also: the parser code is a little rough, I didn't want spend too much time cleaning it up before we agreed on the format
[General][Added] Add codegen flow parser
Reviewed By: cpojer
Differential Revision: D15417733
fbshipit-source-id: dd80887c0b2ac46fdc3da203214775facd204e28
Andres Suarez
Rubén Norte
Eli White
Joshua Gross
Michał Osadnik
Rick Hanlon
Luna Wei