We want to be able to measure API parity against RN core, and catch cases where new APIs are added. Since most JS is shared, this generally means we are missing support on the native side for a new API. Internal turbomodules with type-checking are underway, but ViewManagers native APIs are currently not validated against JS. This can also cause regressions as APIs change (such as Fabric related refactoring moving more towards VM commands).
We want to eventually guarantee ViewManagers implement the full JS interface by type-checking native against codegen'd interfaces from core. We're not quite there yet, and not all interfaces in core are moved to code-gen'able interfaces. Core does have ViewConfig's for many common views, which provide a runtime description of the ViewManager interfaces (including properties, some level of commands, events).
These ViewConfigs are currently compared to supported properties supported by Native view managers, but we will only redbox in cases where native has extra properties compared to JS, and not the other way around, due to overlap of Android + iOS props. We can do that comparison ourselves to list properties that may be in core, but not in RNW, and blacklist any known properties we don't want to support. Quick example of reversing the existing detection (note that some props we erroneously don't claim to support in Native).
Some ViewConfigs in core are hand-rolled, but ViewManagers hooked into codeGenNativeComponent have generated ViewConfigs when using babel-plugin-inline-view-configs which we already have hooked up to Playground.
We should be able to check completeness of properties and some commands against:
Hand-rolled ViewConfigs
View
Image
ScrollView
TextInput (with some finagling to check against RCTSingleLineTextInput)
Codegen'd ViewConfigs
ActivityIndicator
DatePicker
MaskedView
Picker
PullToRefresh
SafeAreaView
SegmentedControl
Slider
Switch
May have a dependence on MSRN JS integration tests work.
Supersedes #4915
We want to be able to measure API parity against RN core, and catch cases where new APIs are added. Since most JS is shared, this generally means we are missing support on the native side for a new API. Internal turbomodules with type-checking are underway, but ViewManagers native APIs are currently not validated against JS. This can also cause regressions as APIs change (such as Fabric related refactoring moving more towards VM commands).
We want to eventually guarantee ViewManagers implement the full JS interface by type-checking native against codegen'd interfaces from core. We're not quite there yet, and not all interfaces in core are moved to code-gen'able interfaces. Core does have ViewConfig's for many common views, which provide a runtime description of the ViewManager interfaces (including properties, some level of commands, events).
These ViewConfigs are currently compared to supported properties supported by Native view managers, but we will only redbox in cases where native has extra properties compared to JS, and not the other way around, due to overlap of Android + iOS props. We can do that comparison ourselves to list properties that may be in core, but not in RNW, and blacklist any known properties we don't want to support. Quick example of reversing the existing detection (note that some props we erroneously don't claim to support in Native).
Some ViewConfigs in core are hand-rolled, but ViewManagers hooked into
codeGenNativeComponent
have generated ViewConfigs when usingbabel-plugin-inline-view-configs
which we already have hooked up to Playground.We should be able to check completeness of properties and some commands against: Hand-rolled ViewConfigs
View
Image
ScrollView
TextInput
(with some finagling to check againstRCTSingleLineTextInput
)Codegen'd ViewConfigs
ActivityIndicator
DatePicker
MaskedView
Picker
PullToRefresh
SafeAreaView
SegmentedControl
Slider
Switch
May have a dependence on MSRN JS integration tests work.