SwiftUI Style .foo() wrappers

[kyleve]

This PR implements SwiftUI-style wrappers which I think improve the succinctness and readability of Blueprint code.

The main file to check out for updates/examples to written consumer code is ViewController.swift.

SwiftUI-Style .foo() methods for wrapping types

Before this change, if you wanted to have a scroll view, which wrapped a box, which wrapped an inset, which wrapped a constrained size, which wrapped a label (and so on), the code would look something like this:

ScrollView(.fittingHeight) (
   wrapping: Box(
        backgroundColor .lightGrey,
       wrapping: Inset(
          uniformInset: 10.0,
          wrapping: ConstrainedSize(
             height: .atLeast(20.0),
             wrapping: Label(
                text: "Hello, world!"
             )
         )
      )
   )
)

Which obviously is pretty verbose... It's nice that from the shape of the code you see what's going on, but it's pretty hard to follow in practice, especially if these inner statements get broken up into intermediary variables.

After this change, to write this code, this becomes like the following, similar to SwiftUI:

Label(text: "Hello, World!")
   .constrainedTo(height: .atLeast(20.0))
   .inset(by: 20.0)
   .box(background: .lightGrey)
   .scrollable(.fittingHeight)

[kylebshr]

1) SwiftUI methods

I really like this, and actually added similar functions in a side project over the weekend for some custom "view modifiers". I think it's both easier to read and write - I often start out with a base element like a label, and in the current form it's clunky to repeatedly wrap it in elements, and often "obscures" the real UI.

2) Stack improvements

StackChild: I think this makes sense, having named static methods instead of having to read the docs for grow/shrink priority every time seems great (jokes aside, the names are way more readable and beginner friendly).

Operators: I'm not a huge fan of custom operators for UI, since they're not very discoverable, lead to divergence in code style (since it doesn't make sense to remove the functions) and it just doesn't "feel right" to me. Not a super strong opinion here though :)

[kyleve]

@kylebshr re operators: generally agree, but I think there's a time and place for them, eg common operations like this. As long as you can do everything without operators that you can do with them, I feel it's fine.

[kyleve]

@kyleve: TODO: Split Stack changes out into a new PR

• TODO: Split Stack changes out into a new PR

[kyleve]

I've removed the stack changes from this PR

[kylebshr]

LGTM after comments!

[kylebshr]

Haha, didn’t realize the init had a default, I don’t like it there for the same reason but I’ll let you decide!

…

On May 5, 2020, at 8:05 PM, Kyle Van Essen ***@***.***> wrote:  @kyleve commented on this pull request. In BlueprintUI/Sources/Layout/Aligned.swift: > @@ -111,3 +111,23 @@ public struct Aligned: Element { } } } + +public extension Element { + /// Wraps the element in an `Aligned` element with the provided parameters. + /// + /// - parameters: + /// - vertically: The vertical alignment. Defaults to `.centered`. + /// - horizontally: The horizontal alignment. Defaults to `.centered`. + /// + func aligned( + vertically: Aligned.VerticalAlignment = .center, Eh, what the hell, removing the default — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[mattfaluotico]

Popping in for a comment on Stack Improvements, even though this is merged. IMO you get a bit more clarity about what is being added when the Element proceeds the stacking traits.

Was dabbling and added a similar StackChild, with the flex traits using function builders (like this PR adds)

so you could get:

Row {
    Label(text: "A truly great label")
        .growPriority(1)
}

I like @kyleve's use of fixed a lot!

Row {
    Label(text: "A truly great label")
        .fixed
    Spacer()
    Label(text: "Another great label")    
}