
Data in SwiftUI, Part 2: Views as a Function of Data - sarunw
https://sarunw.com/posts/data-in-swiftui-2/
======
tayistay
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.

~~~
hombre_fatal
Also, your can't yet derive all of your views from state like you can in React
or Elm because it doesn't expose all state to you.

For example, <NavigationView> \+ <NavigationLink> doesn't update a History
state object that you can control, push, or pop.

~~~
ollysb
As an Elm dev jumping into swift a couple of weeks ago I decided to just do
the nav myself. I have an enum for Page and switch over that in the view. It
seems far more obvious to use than the built in nav which doesn’t actually do
an awful lot for you but takes away control(I did try the isActive approach
but it seemed far more fiddly than using a Page enum).

------
charliemil4
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
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
I learned from the official SwiftUI tutorials:
[https://developer.apple.com/tutorials/swiftui/tutorials](https://developer.apple.com/tutorials/swiftui/tutorials)

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

------
jmull
I read this article and part 1.

IMO, it's not very well done and you should look elsewhere to learn about
SwiftUI.

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

------
5cott0
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.

~~~
kitsunesoba
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
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
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.

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

~~~
ericlewis
More like Elm.

~~~
jamil7
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.

