Summary:
This is meant to show a possible route format for a persistent form of Yoga. Where previous layouts can remain intact while still taking advantage of incremental layout by reusing previous subtrees.
```c
YGNodeRef YGNodeClone(const YGNodeRef node);
```
The core of this functionality is a new API to clone an existing node. This makes a new detached node with all the same values as the previous one. Conceptually this makes the original node "frozen" from that point on. It's now immutable. (This is not yet enforced at runtime in this PR but something we should add.)
Since the original is frozen, we reuse the children set from the original node. Their parent pointers still point back to the original tree though.
The cloned node is still mutable. It can have its styles updated, and nodes can be inserted or deleted. If an insertion/deletion happens on a cloned node whose children were reused, it'll first shallow clone its children automatically.
As a convenience I also added an API to clear all children:
```c
void YGNodeRemoveAllChildren(const YGNodeRef node);
```
During insert/delete, or as a result of layout a set of reused children may need to be first cloned. A kind of copy-on-write. When that happens, the host may want to respond. E.g. by updating the `context` such as by cloning any wrapper objects and attaching them to the new node.
```c
typedef void (*YGNodeClonedFunc)(YGNodeRef oldNode,
YGNodeRef newNode,
YGNodeRef parent,
int childIndex);
void YGConfigSetNodeClonedFunc(YGConfigRef config,
YGNodeClonedFunc callback);
```
This PR doesn't change any existing semantics for trees that are not first cloned.
It's possible for a single node to exist in two trees at once and be used by multiple threads. Therefore it's not safe to recursively free a whole tree when you use persistence. To solve this, any user of the library has to manually manage ref counting or tracing GC. E.g. by replicating the tree structure in a wrapper.
In a follow up we could consider moving ref counting into Yoga.
Closes https://github.com/facebook/yoga/pull/636
Reviewed By: emilsjolander
Differential Revision: D5941921
Pulled By: sebmarkbage
fbshipit-source-id: c8e93421824c112d09c4773bed4e3141b6491ccf
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Cxx module code swallows c++ exception details with sarcastic comment let native developer figure it out.
Now instead of swallowing it, we print as much information as we can for different exception types.
Still not ideal but way more informative.
Have a crash in your c++ module and try to figure it out without this change.
Closes https://github.com/facebook/react-native/pull/16193
Differential Revision: D6040038
Pulled By: javache
fbshipit-source-id: 3fbe838383ca13395e21f74c9549474f6329cfeb
Summary:
This fixes shrinking of elements which are in a non stretch alignment
Fixes#633
Closes https://github.com/facebook/yoga/pull/634
Differential Revision: D5874862
Pulled By: emilsjolander
fbshipit-source-id: 1426aa6b60f6ba42c2be702e6f24cea935ab7acb
Summary:
**Breaking Change Notes**
To adapt to the breaking change, app developers that are consuming React Native through CocoaPods must update their Podfile to refer to yoga with a lowercase "y". In other words:
pod 'Yoga', :path => '../node_modules/react-native/ReactCommon/yoga'
Must be changed to (note the lowercase "y"):
pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'
**Symptom**
If you consume React Native as a CocoaPod and consume a third-party React Native module not as a CocoaPod, you will receive a `nonportable-include-path` warning in Xcode >= 8.3.
**Details**
Xcode 8.3 introduced -Wnonportable-include-path which triggers if you import a header using different casing than the path to the header on disk. This triggers when consuming React Native as a CocoaPod from a library that isn't a CocoaPod. React Native imports Yoga using paths like this:
#import <yoga/Yoga.h>
Which means Yoga's headers are expected to be located in a directory called "yoga" with a lowercase "y". However, when React Native is a CocoaPod the Yoga headers for non-CocoaPods end up in the directory "$(BUILT_PRODUCTS_DIR)/Yoga".
To fix this such that Yoga's headers end up in "$(BUILT_PRODUCTS_DIR)/yoga" (note the lowercase "y"), I've changed Yoga's podspec name to have a lowercase "y".
**Test Plan**
Created a test app where React Native is consumed as a CocoaPod. Added the react-native-maps library to the project and configured it to not be consumed through CocoaPods. Verified that the app compiles properly without the `nonportable-include-path` warnings.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/15527
Differential Revision: D5706338
Pulled By: javache
fbshipit-source-id: 090daa2c3ebb1c66bd467e78a1e91791dbb06651
Summary:
This PR fixes a declaration mismatch for `YGNodeCanUseCachedMeasurement` where the last argument is declared non `const` in `.h` and `const` in `.c`.
Additionally it uses explicit `float` for fraction calculation do avoid usage of `double` assignment.
Closes https://github.com/facebook/yoga/pull/607
Differential Revision: D5677931
Pulled By: emilsjolander
fbshipit-source-id: 502da957089e4439ed956987ff8dec10bd033ba3
Summary:
== Before ==
- Aspect ratio would do its best to fit within it's parent constraints
- Aspect ratio would prioritize `alignItems: stretch` over other sizing properties.
== After ==
- Aspect ratio is allowed to make a node grow past its parent constraints. This matches many other aspects of flexbox where parent constraints are not treated as hard constraints but rather as suggestions.
- Aspect ratio only takes `alignItems: stretch` into account if no other size definition is defined. This matches the interaction of other properties with `alignItems: stretch`.
== Updating your code ==
**You probably don't need to do anything** but in case something does break in your product it should be as easy as adding `{width: '100%', height: '100%', flexShrink: 1}` to the style declaring the `aspectRatio`.
Reviewed By: gkassabli
Differential Revision: D5639187
fbshipit-source-id: 603e8fcc3373f0b7f2461da2dad1625ab59dcb19
Dan Caspi
Dan Zimmerman
Chandra Patni
Alex Dvornikov
Georgiy Kassabli
Pritesh Nandgaonkar
Sebastian Markbage
Sergei Dryganets
Scott Yost
Paco Estevez Garcia
Marko Novakovic
Jia Li
Mingwei Pan
Emil Sjolander
Lukas Wöhrl
Michał Gregorczyk
Pieter De Baets
Michael Lee
Marc Horowitz
Pieter De Baets
Adam Comella
Lukas Wöhrl
Scott Wolchok
Ben Nham