7f1ed6848f
Summary: During transforming raw prop (`rawProps[<prop>]`) to typed props (`MyProps.<prop>`) we can face three different cases: * `rawProps` collection has proper serialized value for the key. In this case, we have to set a new value of the typed prop converting value using `fromDynamic`. * `rawProps` collection does not have value for the key. In this case, we have to copy a value from source prop (`sourceValue`). * `rawProps` collection has `null` value for the key. This is the special case which means that the prop was removed from the particular component instance and we have to reset it to some *default* value (which is *not* the same as `sourceValue`). Now the default value of the `defaultValue` (sic!) argument is a default value of the type of the value (which may be different from logical default value). We didn't handle the last case previously and this caused crashes (and unexpected behavior) because `fromDynamic` often cannot handle `null` value. And yes, all this mean that we also have to update all `convertRawProp` call sites where logical default values are not equal to type-specific default values. This is a potential error-prone place, especially because now we have to specify logical default values in two places (in a prop declaration and in a parameterized constructor). And seems there is no way to avoid that without performance loss (because both of those places are basically constructors). My hope is that codegen (where default values are also defined in JavaScript) will help with it eventually. Reviewed By: fkgozali Differential Revision: D8247652 fbshipit-source-id: 2cbe65f5f5cccd7a0d34aaa19e385aacebfe8cb1 |
||
|---|---|---|
| .. | ||
| cxxreact | ||
| fabric | ||
| jschelpers | ||
| jsinspector | ||
| microprofiler | ||
| privatedata | ||
| yoga | ||