Actually, we’ve been playing with SwiftUI and some...

# compose

[sergio250]

Actually, we’ve been playing with SwiftUI and some snapshot testing and that nesting syntax is what’s using under the hood:

struct ContentView: View {
    var body: some View {
        Spacer().padding()
    }
}

Is transformed into

▿ _ModifiedContent<Spacer, _PaddingLayout>
  ▿ content: Spacer
    - minLength: Optional<CGFloat>.none
  ▿ modifier: _PaddingLayout
    ▿ edges: Set
      - rawValue: 15
    - insets: Optional<EdgeInsets>.none

[sergio250]

You can even create the same composable Padding component:

struct Padding<Content>: View where Content : View {
    let content: Content

    init(content: () -> Content) {
        self.content = content()
    }

    var body: some View {
        content.padding()
    }
}

struct ContentView: View {
    var body: some View {
        Padding{
            Spacer()
        }
    }
}

[Ruckus]

Sure, but what gets used under the hood and what the user has to type are two very different things.

[sergio250]

The thing is that SwiftUI really let’s you write it the way you want, see the example above ☝️
Anyways I’m not sure the Padding { … } syntax is any more readable than view.padding(), it’s more explicit in that what we are doing is changing a view’s properties, not creating any more views. I guess that’s just a matter of taste, though

[Ruckus]

it’s more explicit in that what we are doing is changing a view’s properties, not creating any more views

That's only true if padding is a property of every view. If instead you have padding be a separate composable that creates padding around whatever you put in it (as I believe it is done in Compose), it's just the opposite.

[sergio250]

That’s actually knowing what’s under the hood. I meant it in a generic way, every view system I know (from HTML to Android’s and iOS’ views) uses padding as a property and not as a building block so it’s Compose the one changing the semantics of padding in favor of composition, not the other way around

[Ruckus]

For sure, but my point is that Compose's different semantics aren't just implementation details, they are a new way of thinking, and the default representation should encourage that. One of the big driving factors of Compose is that the compositions are immutable, so a method that looks like "changing properties" could (should?) be considered logically wrong.

[Ruckus]

Granted, I could be way off in my assumptions about Compose, so take my comments with a huge grain of salt 🙂

[sergio250]

Yeah, I understand your point from Compose’s perspective