@qalandarov@elizablock I can definitely see why that’s surprising! Thanks for the report. The explanation: without the dot you have an infinitely recursive view. Swift’s implicit self means that’s:
ZStack {
Button(…)
self.animation(…)
}
It’s nesting infinite ContentViews within itself
The SwiftUI Previews team is hiring! We get to provide the preview experience for Xcode and Swift Playgrounds. We love sitting at the intersection of tools, languages, frameworks, and the system.
If this sounds interesting, please apply or DM! https://t.co/W2KstSot5O
@dasdom I certainly appreciate the frustration when something breaks, but could you please file a bug? Seeding helps find things we may have missed, and if we broke something for you it likely impacts others as well.
Yes, I do usually stand at my desk at the office. In general it’s a bit higher than the one in SOTU, so my wrists aren’t in as much danger as it would seem. I appreciate the concern though!
@rhysmorgan@johnsundell It even supports embedded interactive links, all from one line of code in your Text initializer. For localization check out the automatic pluralization and gender agreement attribute too!
@leogdion@mecid@CameronBardell @simrandotdev It’s difficult to be specific given the abstract question, but you should really be able to call async functions without wrapping anything in Futures. For example, use .task { } to execute async work when a view appears, or Task { } to do so in a callback (async { } in Seed 1)
Looking forward to talking with many of you at #WWDC this year! Of course there’s lots of great stuff in the sessions, and although we’re not together in person I hope to see you in the digital lounge
@mpweiher@tammofreese@steipete The part that’s conceptual and not just an optimization is that body must always return the same structure. It’s a compile error for two branches to return different view types. That it’s code building the description is a huge convenience, but it’s just as static as XML
@mpweiher@tammofreese@steipete I agree with your statement. I’m just saying that SwiftUI isn’t a fundamentally unstable model, because the type system brings the same stability you’d have if your view hierarchy description was instead provided in XML
@mpweiher@tammofreese@steipete There are a great many differences between SwiftUI and react, but the fact that SwiftUI doesn’t do a tree diff and guarantees a stable view hierarchy is a major one. It shares more lineage in that regard with things like WebObjects which used XML for hierarchy description
@mpweiher@tammofreese@steipete I obviously see there is a jump in that video, I’m just saying you’re reading too much into it. The design of SwiftUI guarantees a stable view hierarchy without tree diffing. Certainly there can be other bugs, but it’s not the specific deep architectural issue you’re describing
@mpweiher@tammofreese@steipete There is no tree diff in SwiftUI to determine the shape of the resulting UIView/CALayer hierarchy. That’s statically encoded in the type system by the return type of your body method. SwiftUI doesn’t need to diff to determine structure
@mpweiher@tammofreese@steipete The fact that the view hierarchy is encoded in the ‘some View’ return type means the resulting shape of the hierarchy can’t change. It’s not just an optimization that initWithFrame isn’t called again when inputs change, it’s 100% guaranteed it won’t need to be
@mpweiher@tammofreese@steipete It’s conceptually the same as if UIKit had a setNeedsUpdate that triggered an updateView, and you’d put all your property updates in there. Similar to setNeedsLayout/layoutSubviews. It’s basically just enforcing that you actually build all your layout and update code that way
@mpweiher@tammofreese@steipete SwiftUI’s view hierarchy is fundamentally stable. The type system encodes the hierarchy, and it will not change as inputs change except where conditional differences are specified explicitly by the developer. The “rebuilding” SwiftUI does mostly just updates view properties