Josh Shaffer

[Josh Shaffer @joshshaffer]

Come check out SOTU with us! So much exciting stuff to talk about.

[Josh Shaffer @joshshaffer]

@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

[Kevin Cathey @kbcathey]

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

[Josh Shaffer @joshshaffer]

@ChristianSelig @zmknox It most definitely didn’t come off as you promoting anything! I was just surprised I never thought to try it.

[Josh Shaffer @joshshaffer]

@twostraws @jacobx Thanks for joining Paul! That was really fun. Hope you enjoyed it!

[Josh Shaffer @joshshaffer]

@dasdom Thanks! If you reply with the bug report number I’ll check in on it

[Josh Shaffer @joshshaffer]

@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.

[Josh Shaffer @joshshaffer]

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!

[Josh Shaffer @joshshaffer]

@_mchristensen Weird, that’s distracting? Do you only keep 20 in your fridge?

[Josh Shaffer @joshshaffer]

@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!

[Josh Shaffer @joshshaffer]

@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)

[Josh Shaffer @joshshaffer]

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

[Josh Shaffer @joshshaffer]

@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

[Josh Shaffer @joshshaffer]

@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

[Josh Shaffer @joshshaffer]

@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

[Josh Shaffer @joshshaffer]

@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

[Josh Shaffer @joshshaffer]

@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

[Josh Shaffer @joshshaffer]

@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

[Josh Shaffer @joshshaffer]

@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

[Josh Shaffer @joshshaffer]

@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