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()
        }
    }
}

[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

[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

[sergio250]

Yeah, I understand your point from Compose’s perspective