You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Onfirst render, thecomponentpropsarethosedeclaredintherenderfunction. After the View is pressed `_onSubmit` calls `setNativeProps` with updated prop values.
420
420
The resulting component can be represented as such:
@@ -437,7 +437,7 @@ Note that all prop values set in the render function are unchanged even though `
437
437
438
438
The fact that React Native stores some internal state of each component that isn’t explicitly declared in last render is what Fabric intends to fix.
439
439
440
-
### Moving `setNativeProps` to state
440
+
#### Moving `setNativeProps` to state
441
441
442
442
Taking those caveats into account, a proper migration would look like this:
443
443
@@ -588,7 +588,7 @@ Note:
588
588
- The command definition is co-located with the native component. This is an encouraged pattern
589
589
- Ensure you have included your command name in `supportedCommands` array
@@ -614,7 +614,7 @@ class MyComponent extends React.Component<Props> {
614
614
}
615
615
```
616
616
617
-
### Updating Native implementation
617
+
#### Updating Native implementation
618
618
619
619
In the example the code-generated `Commands` will dispatch `moveToRegion` call to the native component’s view manager. In addition to writing the JS interface, you’ll need to update your native implementation signatures to match the dispatched method call. See the mapping for [Android argument types](https://facebook.github.io/react-native/docs/native-modules-android#argument-types) and[iOS argument types](https://facebook.github.io/react-native/docs/native-modules-ios#argument-types) for reference.
0 commit comments