Summary:
I'm trying to fix some bugs I introduced in my latest PR, but while writing the Unit Tests for them, I saw a really weird behaviour. The following exact piece of code WORKS inside a Yoga C++ unit test, but fails from a Objective-C unit test. I had me completely confused and blocked me in my progression. Any ideas?
```
TEST(YogaTest, stupid_test) {
const YGNodeRef node = YGNodeNew();
YGNodeStyleSetPosition(node, YGEdgeLeft, 1);
ASSERT_FLOAT_EQ(1, YGNodeStyleGetPosition(node, YGEdgeLeft).value);
ASSERT_EQ(YGUnitPixel, YGNodeStyleGetPosition(node, YGEdgeLeft).unit);
YGNodeFree(node);
}
```
```
- (void)testPositionalPropertiesWork
{
YGNodeRef node = YGNodeNew();
YGNodeStyleSetPosition(node, YGEdgeLeft, 1);
XCTAssertEqual(1, YGNodeStyleGetPosition(node, YGEdgeLeft).value);
XCTAssertEqual(YGUnitPixel, YGNodeStyleGetPosition(node, YGEdgeLeft).unit);
YGNodeFree(node);
}
```
Closes https://github.com/facebook/yoga/pull/328
Reviewed By: dshahidehpour
Differential Revision: D4421504
Pulled By: emilsjolander
fbshipit-source-id: f59379edf70aee87a77cd1ad2986313cdfe71b94
Summary:
Simple fix on a possible copy paste error. The test actually passes the same way by coincidence.
Closes https://github.com/facebook/yoga/pull/338
Reviewed By: dshahidehpour
Differential Revision: D4415019
Pulled By: emilsjolander
fbshipit-source-id: 823c3efc821db14b70d9dfe99ef87d1d7ebb75d0
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
