Introduce Decorate element

[kyleve]

This PR introduces the Decorate element, which lets you put a decoration element above or below a content element, and position it depending on insets, corner, or custom. This is useful for drawing backgrounds behind components, drawing badges on elements, etc.

[kylebshr]

Looks good for the most part, not sure about the Layout question 🤔 we should add some snapshot tests too!

[watt]

This is useful for rendering tap or selection states which should overflow the natural bounds of the Element, similar to a shadow.

Is anyone using an element like this now?

I think in most elements I've seen where the tap target is larger than its visible affordance, it lays out the background normally, and then adjusts the tap target in the backing control. This seems to invert that idea, making the layout size match the tap target, and then taking the background out of layout. I'd like to see how this is expected to be used.

[kyleve]

Redoing this ontop of LayoutWriter from #187, ignore commits until I update docs etc.

[kyleve]

This should be good for another review pass.

[watt]

I don't know if it makes sense to take a closure here. Most Blueprint & SwiftUI containers that take a closure do it to support builders that accumulate multiple children (like stacks) or that have parameters (like GeometryReader). SwiftUI secondary views don't use builder closures either.

[kyleve]

I like the closure since it gives you an immediate scope to set things up, but I'll remove for consistency for now.

[kyleve]

I think I'll keep it on the Element extension though since it makes the code read a bit more nicely, eg:

        .thingy()
        .decorate(layering: .below, position: .inset(5)) {
            Box(backgroundColor: .init(white: 0.0, alpha: 0.1), cornerStyle: .rounded(radius: 17))
        }

[watt]

Instead of Corner & Position, can you add an Alignment type? I culled it from the alignment guides stuff because it was unused, but it looks like this:

public struct Alignment: Equatable {
    static let center = Alignment(horizontal: .center, vertical: .center)
    static let leading = Alignment(horizontal: .leading, vertical: .center)
    static let trailing = Alignment(horizontal: .trailing, vertical: .center)

    static let top = Alignment(horizontal: .center, vertical: .top)
    static let bottom = Alignment(horizontal: .center, vertical: .bottom)

    static let topLeading = Alignment(horizontal: .leading, vertical: .top)
    static let topTrailing = Alignment(horizontal: .trailing, vertical: .top)

    static let bottomLeading = Alignment(horizontal: .leading, vertical: .bottom)
    static let bottomTrailing = Alignment(horizontal: .trailing, vertical: .bottom)

    var horizontal: HorizontalAlignment
    var vertical: VerticalAlignment
}

You'll lose the custom frame case, but I think that can be done with a size constraint.

[kyleve]

I'm not sure this is worth it to lose the custom frame case – providing an "escape hatch" for people still seems valuable so we're not on the hook for implementing every needed case within this type.

[kyleve]

What about replacing Corner with Alignment; seems about the same but added functionality for centering on a given side?

[kyleve]

Actually, I think to do this "right" it's gonna take unifying some types between alignment guides, the aligned type, and this. Let's go ahead and merge this as is, and then I can follow up with that in another PR

[watt]

Hmm, this is really the main sticking point for me in this PR. If we use Alignment it's almost exactly the same as SwiftUI's secondary views, but if we invent new types for this it moves us further away.

I guess I would be OK merging as-is as long as we follow up before we do another release? Alternatively, I could make a PR onto this branch with suggested changes, seeing as how I've worked with alignments already, I have a pretty good idea of the changes involved.

What about replacing Corner with Alignment; seems about the same but added functionality for centering on a given side?

It's not. The static cases have similar names, but alignments are opaque — resolving them gives you an x/y position in the coordinate space of the parent.

providing an "escape hatch" for people still seems valuable

I think the custom frame escape hatch is still achievable using Alignment if you wrap your content in .constrainedSize().

[kyleve]

Got it – this makes sense. I'll do another PR into this one to separate the changes. I plan on keeping the outer positioning though; and will replace corner with alignment.

[kyleve]

So something I don't quite understand looking at the existing alignments defined in Alignments.swift – is each of them provide a different edge – eg leading provides 0, center provides the center, and trailing provides the width – but in the case of eg the Aligned element, I need to ensure the contained wrapped element just buts up against the current edge – but this edge depends on the Alignment – but since the alignments are now just types, I can't switch over them easily... I think I'd run into the same issue here... Maybe this would be better to discuss tomorrow in 1:1? I feel like we're missing something to make this work everywhere, or I'm missing something obvious

[watt]

Can we expose this with background and overlay modifiers instead (maybe renaming the latter to disambiguate from the Overlay element)?

[kyleve]

I went with this because of potential confusion – eg background sounds like I'm giving a background to my current element, and overlay is confused with Overlay as you mention.

[watt]

This looks really close to an implementation of #49, with just a few API tweaks!

[kyleve]

I'm going ahead and land this, we can update with the alignments later.