https://kotlinlang.org logo
Channels
Powered by
s

sergio250

06/05/2019, 3:42 PM
Actually, we’ve been playing with SwiftUI and some snapshot testing and that nesting syntax is what’s using under the hood:
Copy code
struct ContentView: View {
    var body: some View {
        Spacer().padding()
    }
}
Is transformed into
Copy code
▿ _ModifiedContent<Spacer, _PaddingLayout>
  ▿ content: Spacer
    - minLength: Optional<CGFloat>.none
  ▿ modifier: _PaddingLayout
    ▿ edges: Set
      - rawValue: 15
    - insets: Optional<EdgeInsets>.none
You can even create the same composable 
Padding
component:
Copy code
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()
        }
    }
}
r

Ruckus

06/05/2019, 4:36 PM
Sure, but what gets used under the hood and what the user has to type are two very different things.
s

sergio250

06/05/2019, 4:42 PM
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
👍 1
r

Ruckus

06/05/2019, 4:50 PM
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.
s

sergio250

06/05/2019, 4:53 PM
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
r

Ruckus

06/05/2019, 4:59 PM
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.
👍 1
Granted, I could be way off in my assumptions about Compose, so take my comments with a huge grain of salt 🙂
s

sergio250

06/05/2019, 5:02 PM
Yeah, I understand your point from Compose’s perspective
2 Views
Powered by