5 ms·

Data in SwiftUI, Part 2: Views as a Function of Data

74 points by sarunw 7y ago

treyfitty 7y ago
It’s so hard to follow some nuggets. This article seems hastily written for the sake of pushing content.
sleepinseattle 7y ago
The article is just demonstrating storing application state directly in views. Which you can do in any UI framework and works fine for small apps, but quickly falls over if the state affects multiple views. That’s the whole point of the various Model-View-* patterns, and doesn’t become less relevant just because the UI framework offers reactivity or data-binding.
- ajconway 7y ago
  If the state affects multiple views, the views should be a function of that state. The point of reactive UI is to not deal with events that affect data that affect presentation. Instead, you construct "presentation" every time the data changes, and the framework makes sure to reflect that in an optimal way.
  - sleepinseattle 7y ago
    What is this if not an event? Button(action: { self.isPlaying.toggle() } They just happen to be handling it entirely within their view component instead of making it a function on some controller/ViewModel/whatever object that then goes and updates the bool. Each framework then has its own code gen or library or runtime magic that makes that bool change get reflected in other views.
  - mpweiher 7y ago
    Aka: a View in MVC. (Not to be confused with what Apple, for example, calls MVC, which is more like MVP).
jmull 7y ago
I read this article and part 1. IMO, it's not very well done and you should look elsewhere to learn about SwiftUI.
charliemil4 7y ago
Hacking with Swift has been a life saver for me; I'm still in UIKit land (only because MacCatalyst didn't like SwiftUI to begin with) -- but these guys are amazing. They get you to the point where you can actually read Apple's documentation... https://www.hackingwithswift.com/quick-start/swiftui https://www.hackingwithswift.com/quick-start/swiftui
- cephaslr 7y ago
  Thank you! I had thought I was the only one who couldn't read Apple's extremely sparse documentation pages with no examples, surely they were sufficient for REAL programmers somewhere who were not me. (Come on Apple, you can't include an example of calling a Button on your documentation page? https://developer.apple.com/documentation/swiftui/button https://developer.apple.com/documentation/swiftui/button) Hacking with Swift is impressive in how much ground it covers.
  - oefrha 7y ago
    I learned from the official SwiftUI tutorials: https://developer.apple.com/tutorials/swiftui/tutorials https://developer.apple.com/tutorials/swiftui/tutorials
  - orf 7y ago
    Apple’s documentation is terrible from a usability standpoint. The design looks great, but it’s absolutely useless and incredibly confusing when used as a guide during learning.
dreamer7 7y ago
Is it correct to say that SwiftUI seems to be inspired by or similar to React architecture?
- ericlewis 7y ago
  More like Elm.
  - jamil7 7y ago
    In what way is it more like Elm? Elm has a single global update function and model that must be passed a message in order to change state. SwiftUI view state can be mutated directly and it enforces no other architecture choices there, you can use whatever you like.
- tebbers 7y ago
  I believe so (speaking as a React developer for the last few years). I'm sure a few people at Apple have looked longingly at React Native and the concepts there.
- 5cott0 7y ago
  It does appear somewhat similar to React but the functional reactive programming influence is much more prevalent. https://github.com/CombineCommunity/rxswift-to-combine-cheatsheet https://github.com/CombineCommunity/rxswift-to-combine-cheat...
tayistay 7y ago
I've been probably jumping the gun on using SwiftUI in my app. It shows some promise conceptually, but I've encountered some severe pain points. - UI that is more stateful (like text fields, which have a selection range, etc.) aren't well supported. Say you want a button to insert text at the insertion point in a text field. You'll need to drop down to UIKit/AppKit for that. - Slow compile times due to the static typing of the view hierarchy. - Error messages that have little to do with where the problem is (you learn to read the tea leaves). - Gotchas e.g. a view can't have more than 10 children, and the error has little to do with that. - Declarative syntax is confusing, adds complexity to the language, and makes the error messages even worse. I still haven't figured out when I can and can't use normal syntax. - Poor performance for simple UIs. It's all built on top of AppKit/UIKit and chooses very heavy weight widgets for things like lists. You have to be careful about what gets regenerated, which is funny for displaying ~100 simple things on a screen. One of the biggest positives though is to finally be rid of autolayout, which was just utterly awful.
- NobodyNada 7y ago
  - Bugs. There’s so many weird bugs in SwiftUI, and the framework is so opaque and poorly-documented that it takes hours of trial and error to find an ugly workaround. That being said, hopefully these issues will get better with time. Swift 5.2 includes a new diagnostics architecture [0] that is supposed to greatly improve SwiftUI error messages. The 10-subviews limitation will be removed once we have variadic generics; a Swift Evolution proposal is currently being drafted [1] and is expected to land in Swift 6. [0]: https://swift.org/blog/new-diagnostic-arch-overview/ https://swift.org/blog/new-diagnostic-arch-overview/ [1]: https://github.com/technicated/swift-evolution/blob/variadic-generics/proposals/XXXX-variadic-generics.md https://github.com/technicated/swift-evolution/blob/variadic...
  - tayistay 7y ago
    How could I forget the bugs? We've failed at doing some simple things (like tooltips on styled buttons on macOS). An Apple engineer [0] said the nested generics were used for SwiftUI because it makes diffing view hierarchies easy and makes identities stable, eliminating a class of bugs caused by changing view hierarchies during interactions or animations. But does potential dynamism actually cause problems in practice? (I haven't used other reactive UI toolkits.) It seems to me that most of the pain in using SwiftUI stems from the heavy reliance on generics. Hopefully it's worth it. [0]: https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/13 https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/...
5cott0 7y ago
SwiftUI is not ready just as Swift itself wasn't ready for production apps until 3.0 (maybe 2 if your team was particularly fond of constant refactoring). Stick with RxSwift MVVM/MVP if you want reactive functional programming.
- pier25 7y ago
  Sadly SwiftUI is a beta like Swift was back then. Another pain point IMO is the uncertainty of not knowing Apple's plans and timelines. For example, why did Apple take so long to release ABI stability for Swift? When will ObjC be finally deprecated? Is SwiftUI going to replace UIKit and Cocoa? If yes, when will that happen? Is it worth it to invest serious dev time into a new macOS Cocoa product if SwiftUI or even Catalyst will be the de facto option in, say, 3 years? iOS devs seem to be happy rewriting their products every year after WWDC and chasing after Apple's decisions which doesn't really seem a sustainable business model.
- kitsunesoba 7y ago
  As a counterpoint, if your app hasn’t moved to a reactive functional setup already, it may be worth holding off and waiting for SwiftUI and Combine to mature, because architectural libraries are pervasive and can be incredibly difficult to remove or migrate away from.
  - 5cott0 7y ago
    RxSwift is just an implementation of Rx (Observable pattern) and doesn't really qualify as an architectural library and MVVM/MVP with proper separation of concerns should not be difficult to refactor to use another data binding pattern. I overheard someone once say they used NotificationCenter as the data binding mechanism in an MVVM app. Big Yikes.
huyegn 7y ago
As someone who has done frontend dev on the web, I find SwiftUI refreshingly good. Using SwiftUI is the first time ui programming on iOS has clicked for me. For anyone getting into this, I suggest you take a look at apple's very well done tutorial series before using other sources: https://developer.apple.com/tutorials/swiftui/tutorials https://developer.apple.com/tutorials/swiftui/tutorials I spent about 3 days to go through the entire series and the time investment was well worth it.

74 points by sarunw 7y ago

It’s so hard to follow some nuggets. This article seems hastily written for the sake of pushing content.

The article is just demonstrating storing application state directly in views. Which you can do in any UI framework and works fine for small apps, but quickly falls over if the state affects multiple views. That’s the whole point of the various Model-View-* patterns, and doesn’t become less relevant just because the UI framework offers reactivity or data-binding.

ajconway 7y ago
If the state affects multiple views, the views should be a function of that state. The point of reactive UI is to not deal with events that affect data that affect presentation. Instead, you construct "presentation" every time the data changes, and the framework makes sure to reflect that in an optimal way.
- sleepinseattle 7y ago
  What is this if not an event? Button(action: { self.isPlaying.toggle() } They just happen to be handling it entirely within their view component instead of making it a function on some controller/ViewModel/whatever object that then goes and updates the bool. Each framework then has its own code gen or library or runtime magic that makes that bool change get reflected in other views.
- mpweiher 7y ago
  Aka: a View in MVC. (Not to be confused with what Apple, for example, calls MVC, which is more like MVP).

jmull 7y ago

I read this article and part 1. IMO, it's not very well done and you should look elsewhere to learn about SwiftUI.

charliemil4 7y ago

Hacking with Swift has been a life saver for me; I'm still in UIKit land (only because MacCatalyst didn't like SwiftUI to begin with) -- but these guys are amazing. They get you to the point where you can actually read Apple's documentation... https://www.hackingwithswift.com/quick-start/swiftui https://www.hackingwithswift.com/quick-start/swiftui

cephaslr 7y ago
Thank you! I had thought I was the only one who couldn't read Apple's extremely sparse documentation pages with no examples, surely they were sufficient for REAL programmers somewhere who were not me. (Come on Apple, you can't include an example of calling a Button on your documentation page? https://developer.apple.com/documentation/swiftui/button https://developer.apple.com/documentation/swiftui/button) Hacking with Swift is impressive in how much ground it covers.
- oefrha 7y ago
  I learned from the official SwiftUI tutorials: https://developer.apple.com/tutorials/swiftui/tutorials https://developer.apple.com/tutorials/swiftui/tutorials
- orf 7y ago
  Apple’s documentation is terrible from a usability standpoint. The design looks great, but it’s absolutely useless and incredibly confusing when used as a guide during learning.

dreamer7 7y ago

Is it correct to say that SwiftUI seems to be inspired by or similar to React architecture?

ericlewis 7y ago
More like Elm.
- jamil7 7y ago
  In what way is it more like Elm? Elm has a single global update function and model that must be passed a message in order to change state. SwiftUI view state can be mutated directly and it enforces no other architecture choices there, you can use whatever you like.
tebbers 7y ago
I believe so (speaking as a React developer for the last few years). I'm sure a few people at Apple have looked longingly at React Native and the concepts there.
5cott0 7y ago
It does appear somewhat similar to React but the functional reactive programming influence is much more prevalent. https://github.com/CombineCommunity/rxswift-to-combine-cheatsheet https://github.com/CombineCommunity/rxswift-to-combine-cheat...

tayistay 7y ago

I've been probably jumping the gun on using SwiftUI in my app. It shows some promise conceptually, but I've encountered some severe pain points. - UI that is more stateful (like text fields, which have a selection range, etc.) aren't well supported. Say you want a button to insert text at the insertion point in a text field. You'll need to drop down to UIKit/AppKit for that. - Slow compile times due to the static typing of the view hierarchy. - Error messages that have little to do with where the problem is (you learn to read the tea leaves). - Gotchas e.g. a view can't have more than 10 children, and the error has little to do with that. - Declarative syntax is confusing, adds complexity to the language, and makes the error messages even worse. I still haven't figured out when I can and can't use normal syntax. - Poor performance for simple UIs. It's all built on top of AppKit/UIKit and chooses very heavy weight widgets for things like lists. You have to be careful about what gets regenerated, which is funny for displaying ~100 simple things on a screen. One of the biggest positives though is to finally be rid of autolayout, which was just utterly awful.

NobodyNada 7y ago
- Bugs. There’s so many weird bugs in SwiftUI, and the framework is so opaque and poorly-documented that it takes hours of trial and error to find an ugly workaround. That being said, hopefully these issues will get better with time. Swift 5.2 includes a new diagnostics architecture [0] that is supposed to greatly improve SwiftUI error messages. The 10-subviews limitation will be removed once we have variadic generics; a Swift Evolution proposal is currently being drafted [1] and is expected to land in Swift 6. [0]: https://swift.org/blog/new-diagnostic-arch-overview/ https://swift.org/blog/new-diagnostic-arch-overview/ [1]: https://github.com/technicated/swift-evolution/blob/variadic-generics/proposals/XXXX-variadic-generics.md https://github.com/technicated/swift-evolution/blob/variadic...
- tayistay 7y ago
  How could I forget the bugs? We've failed at doing some simple things (like tooltips on styled buttons on macOS). An Apple engineer [0] said the nested generics were used for SwiftUI because it makes diffing view hierarchies easy and makes identities stable, eliminating a class of bugs caused by changing view hierarchies during interactions or animations. But does potential dynamism actually cause problems in practice? (I haven't used other reactive UI toolkits.) It seems to me that most of the pain in using SwiftUI stems from the heavy reliance on generics. Hopefully it's worth it. [0]: https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/13 https://forums.swift.org/t/why-is-swiftuis-view-a-pat/28029/...

5cott0 7y ago

SwiftUI is not ready just as Swift itself wasn't ready for production apps until 3.0 (maybe 2 if your team was particularly fond of constant refactoring). Stick with RxSwift MVVM/MVP if you want reactive functional programming.

pier25 7y ago
Sadly SwiftUI is a beta like Swift was back then. Another pain point IMO is the uncertainty of not knowing Apple's plans and timelines. For example, why did Apple take so long to release ABI stability for Swift? When will ObjC be finally deprecated? Is SwiftUI going to replace UIKit and Cocoa? If yes, when will that happen? Is it worth it to invest serious dev time into a new macOS Cocoa product if SwiftUI or even Catalyst will be the de facto option in, say, 3 years? iOS devs seem to be happy rewriting their products every year after WWDC and chasing after Apple's decisions which doesn't really seem a sustainable business model.
kitsunesoba 7y ago
As a counterpoint, if your app hasn’t moved to a reactive functional setup already, it may be worth holding off and waiting for SwiftUI and Combine to mature, because architectural libraries are pervasive and can be incredibly difficult to remove or migrate away from.
- 5cott0 7y ago
  RxSwift is just an implementation of Rx (Observable pattern) and doesn't really qualify as an architectural library and MVVM/MVP with proper separation of concerns should not be difficult to refactor to use another data binding pattern. I overheard someone once say they used NotificationCenter as the data binding mechanism in an MVVM app. Big Yikes.

huyegn 7y ago

As someone who has done frontend dev on the web, I find SwiftUI refreshingly good. Using SwiftUI is the first time ui programming on iOS has clicked for me. For anyone getting into this, I suggest you take a look at apple's very well done tutorial series before using other sources: https://developer.apple.com/tutorials/swiftui/tutorials https://developer.apple.com/tutorials/swiftui/tutorials I spent about 3 days to go through the entire series and the time investment was well worth it.