1. 13
  1.  

  2. 1

    The intention of this defaults-heavy API is to make rapid development of simple apps both easy and correct. Look at that list example - looks great! In both cases. On the web with resets, no two implementations of that pattern are going to look the same.

    Yes, these defaults will bamboozle sometimes. The framework should provide a contextual way to disable them in a subtree when you are doing something specific, like NoDefaults {Custom(); Weird(); Layout() }

    1. 1

      I have not used SwiftUI much, but a number of points in this article seem incorrect to me:

      I’m very much blown away with how far people are willing to go to achieve really slick looking DSL. I mean, SwiftUI could’ve been: … but instead, they decided to get rid of those annoying commas between elements.

      It’s not just commas. Things like conditionals are not expressions in Swift. Function builders exist to make DSLs less painful.

      Some things are probably just plain mistakes (very funny though). E.g. NavigationView takes its properties not from its constructor or via modifiers, but instead from the properties of its first child. WHY?

      That’s how navigation controllers work in iOS. Navigation controllers are containers that, ideally, show the title of the current view controller being presented. I could see this being surprising if you’re not used to iOS and UINavigationController, but I believe the way it works is both expected (by most) and correct.

      This will surround Text with a padding of… I don’t know! Nobody knows, exactly. SwiftUI decides what that padding will be, according to some internal logic.

      Standard margins and padding are not new concepts in SwiftUI. Apple intentionally makes things opaque because they want you going through their systems and APIs, not hardcoding values that may change in future OS releases or on different devices.

      Another example of “smart” (or “magic”) behavior. A button might look black if you add it to a list: … but blue if you change listStyle (not Button style! you don’t need to touch Button at all!):

      I agree this is a bit strange, but the framework is ensuring the correct outcome. In a list, the expectation is that the cell is tappable and the text should not indicate interactivity. Headers, however, are not tappable, and thus showing the button with a color is necessary.