Adds the feature to use percentage as a value unit.

You can use the function YGPx(float) and YGPercent(float) for convenience.

I did some benchmarks:

Without Percentage Feature - Release x86:

Stack with flex: median: 0.000000 ms, stddev: 0.146683 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.490101 ms
Huge nested layout: median: 23.000000 ms, stddev: 0.928291 ms

Stack with flex: median: 0.000000 ms, stddev: 0.170587 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.143384 ms
Nested flex: median: 0.000000 ms, stddev: 0.477791 ms
Huge nested layout: median: 22.000000 ms, stddev: 2.129779 ms


With Percentage Feature - Release x86:

Stack with flex: median: 0.000000 ms, stddev: 0.132951 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.136525 ms
Nested flex: median: 0.000000 ms, stddev: 0.489570 ms
Huge nested layout: median: 21.000000 ms, stddev: 1.390476 ms

Stack with flex: median: 0.000000 ms, stddev: 0.146969 ms
Align stretch in undefined axis: median: 0.000000 ms, stddev: 0.129271 ms
Nested flex: median: 0.000000 ms, stddev: 0.481787 ms
Huge nested layout: median: 21.000000 ms, stddev: 1.695898 ms

It is slightly faster, as I was able to reduce the calls to isnan().

• As mentioned in the title, this PR adds Javascript support to Yoga. Two different builds are included in this PR thanks to nbind, which conveniently allow to target both Node.js' native addons and browser environments via asmjs with approximately the same codebase. That should solve #215.

• All tests successfully pass on both codepaths. You can run yarn test:all inside the javascript directory to test it.

• Because of a bug in nbind, the following PR needs to be merged and a new version released before this one can be safely merged as well.

• I had to use double types instead of float in the C++ bindings because of an Emscripten bug where symbols aren't correctly exported when using floats.

• There's some tweaks to do before this PR is 100% ready to merge, but I wanted to have your opinion first. What do you think of this?

To do:

• [x] Ensure that Travis run
• [x] Add missing functions
• [x] Check measurement functions
• [x] Recursive frees
• [x] Make a decision about the memory management

The C# wrapper project has been changed to a NETStandard (1.1) PCL allowing it to be consumed by any project targeting .NET4.5 or greater including .NETCore and UWP projects... The C# wrapper uses P/Invoke to call into the Native Yoga DLL...

The "Yoga" C++ project has been updated to support ARM builds...

Added the ability to generate nuget packages for the C# wrapper that supports copying the native DLLs to the target output directory.

This supersedes #309 and #305.

This is still a work-in-progress.

TODO

• [x] Create Xcode project that builds an iOS framework
• [x] Fix failing tests on Xcode
• [x] Make pod lib lint pass and make sure YogaKit can be included using CocoaPods
• [ ] Add pod lib lint to .travis.yml
• [x] Migrate to travis osx image with Xcode 8.2

FOLLOW-UP

• [ ] Make YogaKitSample use framework built by new Xcode project.
• [ ] Make Travis to upload prebuilt versions of the framework. More here
• [ ] Upgrade github/jekyll docs about installation using Cocoapods/Carthage

What I've done

Here is what I've done so far:

• I created a framework target in the Xcode project to support Carthage
• I renamed the prefix from YG to YK to support custom enums
• I modified the enums.py generator to add a generation of Objective-C enums
  • I removed enums which were not used in the Objective-C bridge
  • I made sure not to generate the Count items
  • I renamed LTR and RTL to LeftToRight and RightToLeft :-) we don't mind being verbose if it makes identifiers clearer
• I transformed the style setters into properties and added the getter methods
• I renamed the swift names to drop the prefix, which is not Swift style.

For example, here are what the Objective-C and Swift sample code look like:

Objective-C

- (void)viewDidLoad
{
    UIView *root = self.view;
    root.backgroundColor = [UIColor redColor];
    [root yk_setUsesYoga:YES];
    [root yk_setWidth:self.view.bounds.size.width];
    [root yk_setHeight:self.view.bounds.size.height];
    [root yk_setAlignItems:YKAlignCenter];
    [root yk_setJustifyContent:YKJustifyCenter];

    UIView *child1 = [UIView new];
    child1.backgroundColor = [UIColor blueColor];
    [child1 yk_setUsesYoga:YES];
    [child1 yk_setWidth:100];
    [child1 yk_setHeight:100];

    UIView *child2 = [UIView new];
    child2.backgroundColor = [UIColor greenColor];
    child2.frame = (CGRect) {
        .size = {
            .width = 200,
            .height = 100,
        }
    };

    UIView *child3 = [UIView new];
    child3.backgroundColor = [UIColor yellowColor];
    child3.frame = (CGRect) {
        .size = {
            .width = 100,
            .height = 100,
        }
    };

    [child2 addSubview:child3];
    [root addSubview:child1];
    [root addSubview:child2];
    [root yk_applyLayout];
}

Swift

    override func viewDidLoad() {
        let root = view!
        root.backgroundColor = .red
        root.usesYoga = true
        root.layoutWidth = view.bounds.size.width
        root.layoutHeight = view.bounds.size.height
        root.layoutAlignItems = .center
        root.layoutJustifyContent = .center
      
        let child1 = UIView()
        child1.backgroundColor = .blue
        child1.usesYoga = true
        child1.layoutWidth = 100
        child1.layoutHeight = 100
      
        let child2 = UIView()
        child2.backgroundColor = .green
        child2.frame = CGRect(origin: .zero, size: CGSize(width: 200, height: 100))
      
        let child3 = UIView()
        child3.backgroundColor = .yellow
        child3.frame = CGRect(origin: .zero, size: CGSize(width: 100, height: 100))
      
        child2.addSubview(child3)
        root.addSubview(child1)
        root.addSubview(child2)
        root.applyLayout()
    }

Here's what I'd still like to do, but not sure on how best to achieve:

YKEdge based style values

I have purposefully left the style values which depend on an YKEdge alone because I'd like to improve them to be properties, but I'm undecided on how to. Here are my two solutions:

Normalization

We could create yk_positionLeft, yk_positionRight, etc... properties. The pro is that it's simple and efficient, but it's a bit messy.

Sub-types

Or we could go through sub-types with left, `right, etc.. properties:

@interface YKPosition
@property (nonatomic) CGFloat left;
@property (nonatomic) CGFloat top;
@property (nonatomic) CGFloat right;
@property (nonatomic) CGFloat bottom;
@property (nonatomic) CGFloat start;
@property (nonatomic) CGFloat end;
@property (nonatomic) CGFloat horizontal;
@property (nonatomic) CGFloat vertical;
@property (nonatomic) CGFloat all;
@end

Getting and setting such a property would look like this:

view.yk_position.left = 20;

This would be the cleanest solution. But it forces us to initialise three extra objects per view. We could however restrict this solution to Swift and use a struct, which would reduce the performance cost.

Prefix in Swift

I removed the yk_ prefix in Swift because its an anti-pattern and replaced it with layout. The first question is: would it be better if it were yoga instead?

Whatever it is, I think we still need some kind of prefix to make sure there is no ambiguity that values like width and height are for layout calculations and not values of UIView derived from frame. But I'm not 100% happy of the solution. Like for the edge values, how about a sub-type?

let root = view!
root.backgroundColor = .red
root.yoga.usesYoga = true
root.yoga.width = view.bounds.size.width
root.yoga.height = view.bounds.size.height
root.yoga.alignItems = .center
root.yoga.justifyContent = .center

Report

• [x] I have searched existing issues and this is not a duplicate

☝️ However, this is very similar to this other issue. Could it be possible to fix these kind of errors in a bit more structural way? 🤔

Issues and Steps to Reproduce

We've got this in our PodFile:

pod 'React', :path => 'node_modules/react-native', :subspecs => [
  'Core',
  'CxxBridge',
  'DevSupport',
  'RCTText',
  'RCTNetwork',
  'RCTWebSocket',
  'RCTImage',
  'RCTAnimation',
]
pod 'yoga', :path => 'node_modules/react-native/ReactCommon/yoga'

Prior to ReactNative 0.53 this worked. After upgrading to the latest it doesn't.

Expected Behavior

A successful build

Actual Behavior

This error:

In my team's usage of css-layout, we've found it to behave differently than what is described in the W3C spec for flexbox. We've made some changes to make the implementation more closely conform to the W3C spec and to clearly define where its behavior differs from the spec.

The primary goals of this change are:

• Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/) and a clear articulation of the areas where it deviates from the spec.
• Support for flex-shrink.
• Conformance with layout effects of "overflow: hidden".

Specifically, here are the limitations of this implementation as compared to the W3C flexbox standard (this is also documented in Layout.js):

• Display property is always assumed to be 'flex' except for Text nodes, which are assumed to be 'inline-flex'.
• The 'zIndex' property (or any form of z ordering) is not supported. Nodes are stacked in document order.
• The 'order' property is not supported. The order of flex items is always defined by document order.
• The 'visibility' property is always assumed to be 'visible'. Values of 'collapse' and 'hidden' are not supported.
• The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The rarely-used 'wrap-reverse' is not supported.
• Rather than allowing arbitrary combinations of flexGrow, flexShrink and flexBasis, this algorithm supports only the three most common combinations:
  • flex: 0 is equivalent to flex: 0 0 auto
  • flex: n (where n is a positive value) is equivalent to flex: n 0 0
  • flex: -1 (or any negative value) is equivalent to flex: 0 1 auto
• Margins cannot be specified as 'auto'. They must be specified in terms of pixel values, and the default value is 0.
• The 'baseline' value is not supported for alignItems and alignSelf properties.
• Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be specified as pixel values, not as percentages.
• There is no support for calculation of dimensions based on intrinsic aspect ratios (e.g. images).
• There is no support for forced breaks.
• It does not support vertical inline directions (top-to-bottom or bottom-to-top text).

And here is how the implementation deviates from the standard (this is also documented in Layout.js):

• Section 4.5 of the spec indicates that all flex items have a default minimum main size. For text blocks, for example, this is the width of the widest word. Calculating the minimum width is expensive, so we forego it and assume a default minimum main size of 0.
• Min/Max sizes in the main axis are not honored when resolving flexible lengths.
• The spec indicates that the default value for 'flexDirection' is 'row', but the algorithm below assumes a default of 'column'.

Report

• [x] I have searched existing issues and this is not a duplicate

In the drafts of box alignment level 3, there's the properties row-gap and column-gap that allow the user to specify the gaps between rows and columns.

It is a draft, so it might be premature to implement now. Do we want to support this now? (I can take a shot at it if I get time!)

Added an experimental feature to allow to use only rounded values. See #184. It's not a perfect solution and definitely can be further improved. I'm looking forward to your ideas.

Even so I know there are some opinions against margin: 0 auto it's still part of the spec: https://www.w3.org/TR/css-flexbox-1/#auto-margins and pretty usefull if you have to position via justify-content.

This PR adds an implementation for that.

It adds an additonal YGUnitAuto and margins got YGNodeStyleSetMarginAuto functions as well.

I know this is currently by design, but it would be great if we could hide / show nodes. Any roadmap on this? Maybe we can have a chat and I can implement this?

Updated the C# bindings to build using the new simplified .NET SDK tooling. The C# projection now builds for .NET Standard 2.0 (to support Unity, .NET Framework, UWP, and modern .NET) and .NET 6.0 for iOS (to have the native calls correctly support calling into a statically-linked library).

The native changes were needed to get the C# tests passing on Windows x64 (tested locally).

This PR does not update any build, test, or package scripts. I can either add that to this PR or follow up with another PR.

Today, the source of truth for Yoga’s source code is inside of Meta. Yoga is projected out of our monorepo, into GitHub.

Working in a monorepo with product code can have a lot of advantages. Changes are validated against the test coverage of real products, and it’s easy to make API changes which span library and product code. Engineers at Meta, including most on the React Native team, use the tooling built for the monorepo as well.

For its advantages, this structure creates issues in OSS projects that affect both React Native and Yoga. PRs are duplicated into internal “diffs” and we have two sets of code reviews, with a lack of transparency, and an increase in complexity in merging and getting sign off for changes made OSS first. It also means that the “easy” way to develop a change is one that is non-transparent, showing up in OSS once the commit happens.

Yoga has a relatively small, testable, API surface. As such we get a good amount of coverage from the tests, and don’t often have these sort of breaking changes the monorepo setup helps with. The divide instead creates barriers in contribution, and the need for duplication of resources between OSS and external builds.

This issue tracks a goal of moving Yoga to be “GitHub first”, where the source of truth and contribution becomes GitHub, and code is then synced from GitHub to fbsource, instead of the other way around. This will require a good amount of technical changes internally, but also creates changes to the workflow of reviewers (and limits the pool of those able to execute on changes). I think the risks are still likely worth it though.

Summary: This sets the C++ standard to C++ 17 in the working builds and Apple. GTest will stop supporting C++ 11 soon, so we need to update. C++ 14 is more embeddable, but C++ 17 support and usage should be relatively common now and the language version adds quite a bit.

Changelog: [Internal]

Differential Revision: D42285391

Fixes #850

https://github.com/facebook/yoga/issues/850 describes a conformance issue where positioning of an absolute child using percentages is not calculated against the correct box size.

This takes the fix for that in https://github.com/facebook/yoga/pull/1028, regenerates tests, and fixes tests so that the experimental feature can be enabled. Goal is to run this as an experiment internally to see if we can enable by default.

Changelog: [Internal]

• [x] I have searched existing issues and this is not a duplicate

Request

Provide, and clearly document an easy way to run yoga's test suite on Apple Silicon macs.

Context

• Apple Silicon macs are a popular platform. Especially for mobile developers who make up much of Yoga's audience.
• It is very difficult to work with and/or contribute to Yoga without being able to run the tests.
• This will likely require bypassing Buck as Buck does not currently run on Apple Silicon macs. The testing setup is based on gtest, so it should relatively straightforward to set it up so that it works in standalone manner. Unfortunately I lack the experience with the C/C++ build tool ecosystem to do this myself.

Alternatives

• Fix Buck to work on Apple Silicon. There is a partial PR here: https://github.com/facebook/buck/pull/2684