Preview: Introduce reactNativeComponent #616
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Creating a new native component is a pain - you have to write native
code, manually export the properties you want to use in JS, then copy those
props in JS in
validAttributes
and make sure you specify differs fornon-scalar props, otherwise changes won't be sent to native.
This diff adds native code to automatically export
nativePropTypes
, andconsumes those in a new helper
requireNativeComponent
. Right now the actualtypes aren't used in JS, but I changed the logic to default to using
deepDiffer
for objects without an explicit differ specified (this should bemuch safer in general - we've had a few bugs related to bad diff configuration).
The only disadvantage to always using
deepDiffer
forObjects
is perf, sorequireNativeComponent
has an option to provide optimized differ functions,which is demonstrated in
ScrollView.js
.The native export is done similarly to the way we figure out property setters,
but with class methods (prefixed with
getViewPropDef_
) that simply returndictionary literals with the type info.
This also sets the stage for potentially doing JS-side type checking, which
would give us better errors with more context and useful stack traces.
Finally, this gives us the ability to warn or throw when requiring unsupported
native views.
cc @ide - this is a preview of an internal diff that's under review.
Test Plan:
SliderIOS still works, sticky headers stick properly (they break if
diffing breaks), other apps/interactions seems fine.