Summary:
@public
After reading about move-semantic and rvalue refs I realized that we (I) definitely overuse `auto &&` (aka universal reference) construction. Even if this is harmless, does not look good and idiomatic.
Whenever I used that from a semantical point of view I always meant "I need an alias for this" which is actually "read-only reference" which is `const auto &`.
This is also fit good to our policy where "everything is const (immutable) by default".
Hence I change that to how it should be.
Reviewed By: fkgozali
Differential Revision: D8475637
fbshipit-source-id: 0a691ededa0e798db8ffa053bff0f400913ab7b8
Summary:
Now, if `fromDynamic` is defined for some type, `fromDynamic` for `std::vector` of this type is also will be defined.
We need this for parsing `ImageSources` (a vector of `ImageSource`) type.
Reviewed By: fkgozali
Differential Revision: D8473508
fbshipit-source-id: d8dc8e3a3273f35b76c7132c553130762f768394
Summary:
* numbers in JS are doubles in native land, since there's no notion of int or int64 in JS - so simply convert numbers to int instead of assuming it's int
* the parsing of Yoga props with `'...%'` string value has a bug: it should be copying the number instead of the `%`
Reviewed By: shergin
Differential Revision: D8370873
fbshipit-source-id: 44e9e3f0530c000c963e8e9ca66e8b0a48d80bcd
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
Summary:
A few fixes:
* missing include: folly/Optional.h
* switch folly::Optional's `has_value()` to `hasValue()` for now until folly is upgraded to newer version
* fix up import for RCTTextAttributes.h
* fix up includes for "conversions.h" to use namespaced includes
Reviewed By: mmmulani
Differential Revision: D8021149
fbshipit-source-id: d3955986d3ab6b1d9b61ac1e385767893ce57e5e
Summary: Oh, my! No more `#define`s related to props conversions and debug-printing.
Reviewed By: fkgozali
Differential Revision: D7958250
fbshipit-source-id: 86950070c55f134aa3a575b9fd68fc90d865cf44
Summary:
Same as previous one.
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `core` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958243
fbshipit-source-id: 500ee420d9aa562ee3c5810ef625e06541eda8fb
Valentin Shergin
Kevin Gozali