Summary:
Compared to what was planned, I added the `overflow` value which seemed missing. I had to modify the implementation a bit for all values which are backed by a `YGValue`, but we should probably enable the pixel dimensions in Objective-C and Swift somehow later.
Closes https://github.com/facebook/yoga/pull/322
Reviewed By: cosmin1123
Differential Revision: D4391434
Pulled By: emilsjolander
fbshipit-source-id: e33f6f7b2bbaad29553100b7a5bb424496372110
Summary:
Compared to what was planned, I added the `overflow` value which seemed missing. I had to modify the implementation a bit for all values which are backed by a `YGValue`, but we should probably enable the pixel dimensions in Objective-C and Swift somehow later.
Closes https://github.com/facebook/yoga/pull/322
Reviewed By: dshahidehpour
Differential Revision: D4386906
Pulled By: emilsjolander
fbshipit-source-id: 05ac0e571ef3a8ff0be31469e449a7b23f102218
Summary:
In YogaKit, nodes are not dirtied when `sizeThatFits` of leaf nodes change. This makes it difficult to reuse views like `UILabel` when their content (text) changes. I wrote a failing test to prove it and wrote a fix by caching the latest value of `sizeThatFits` in `YGNodeBridge` and checking for changes in `YGAttachNodesFromViewHierachy` (renamed to `YGUpdateNodesFromViewHierachy` to make it clear it's not simply reattaching nodes anymore). When a new size is detected, I call `YGNodeMarkDirty` on the leaf node.
**Unfortunately**, this makes another test fail for no logical reason (`testThatViewNotIncludedInFirstLayoutPassAreIncludedInSecond`). Either there's something I don't understand or I've un-advertedly unearthed a bug in the C implementation, but in what case would setting a node dirty make the layout return a different size?
Closes https://github.com/facebook/yoga/pull/308
Reviewed By: emilsjolander
Differential Revision: D4378826
Pulled By: dshahidehpour
fbshipit-source-id: cd0640bc863debb9e434370739416e3e33e57a08
Summary:
When a non-leaf node becomes a leaf node, `YGAttachNodesFromViewHierachy` calls `YGNodeSetMeasureFunc` before `YGRemoveAllChildren`, which causes a crash because that node has children. Fixed by swapping the order of the calls and have a unit-test to make sure it works.
Closes https://github.com/facebook/yoga/pull/320
Differential Revision: D4383905
Pulled By: dshahidehpour
fbshipit-source-id: 4872b1e819f178adaaa66b1f1c233390d3ec3be9
Summary: We need this for scrollviews, bring on the overflow!
Reviewed By: emilsjolander
Differential Revision: D4376759
fbshipit-source-id: a427432da5e8679dbf9fdbfe4250707e727368f4
Summary:
There is a bug currently where we don't traverse the entire tree to detect view hierarchy changes.
Currently, if you had a hierachy like this:
```
container = UIView
container.subviews = @[subview1, subview2];
subview1.subviews = @[sub11, sub12, sub13];
subview2.subviews = @[sub21, sub22, sub23];
```
and then modified via:
```
subview2.subviews = @[newView1, newView2, newView3];
```
our algorithm wouldn't identify that we had new views that needed their layout calculated, and would cause a crash later on.
Reviewed By: emilsjolander
Differential Revision: D4357662
fbshipit-source-id: 2f61f213c5f1a62948a653f3b1fa3d874c5075f7
Summary: While building some views with YogaKit, I found an interesting problem. If you are apply `yg_` properties to a view which is constructed of subclassed views (that don't use Yoga.) we still treat view (and it's subviews) like they are using YogaKit. This fixes that behavior.
Reviewed By: emilsjolander
Differential Revision: D4348344
fbshipit-source-id: 37b8648918529f55afea1d1883a03af398aac849
Summary: I kept wrongly typing this function which is a good sign that the name is inconsistent.
Reviewed By: gkassabli
Differential Revision: D4333480
fbshipit-source-id: 17058f18fa9e26b3e02f7a1651f7295cae59acad
Summary: This renames the core C api to use the new Yoga branding.
Differential Revision: D4259190
fbshipit-source-id: 26c8b356ca464d4304f5f9dc4192bff10cea2dc9
