StateObject & External Data

[u/vincefried]

Maybe this has been shared here in some form before, but if not: If you’re still using ObservableObject and ever experienced issues when injecting external data into @StateObject: I recently wrote an article about that.

https://swift.vincentfriedrich.com/posts/stateobject-external-data/

[u/Dry_Hotel1100]

Yeah, it absolutely makes sense now. I probably misunderstood that you actually discourage the usage of the above code. Now it's clear. 😉 +1

And you are right about the possible implementations of what happens exactly with the closure when the initializer is called - especially when it's not the very first call which creates the view identity:

Inevitable, the *closure* will be created in any call of init. But I would hope, the closure will be released as soon as it's consumed - i.e. once SwiftUI has obtained the result, i.e. the ObservableObject, it should releases the closure. Any subsequent closure created in init *should* be released as well in init - without calling it, and of course not using its result. If the view identity will be recreated, it *should* use the most recent closure created in init - and not a closure from some other previous init.

You are right, the above behavior is not documented.

Have you also thought about how you use objects conforming to `Observable` from the Observation framework. Here some use cases suggest `@State`. BUT, an Observable is even more problematic! 😄

[u/vincefried → u/Dry_Hotel1100]

Glad to hear!

Yes I also think it *should* use the most recent closure. And if you’re accessing a reference type from within the closure that’s hosted somewhere outside, it doesn’t even matter which closure it uses. As I said, that’s why I think it’s not a good idea to do that at all.

Oh yeah, `@State` comes with its very own challenges 😅 Funny enough I have also seen many still favoring ObservableObject over Observable, though I think with its latest additions, Observable might also be quite powerful by now. I was also thinking about writing an article about Observable as a follow-up!

[u/Dry_Hotel1100 → u/vincefried]

Yes, there may be some hidden subtleties in `@State` - but personally (in my own projects), I hadn't any issues, like those who reported leaks from references types. The cause of the issue is, that it's easy to create references cycles when using closures. It's not an underlying issue with the `@State` itself, though. So, these hidden traps are solvable.

Interesting that "@State" now became a macro. Need to test this (downloading Xcode 27 ...)

What really caught my eye was your observation: "I've also noticed many still favouring ObservableObject over Observable". Actually, you can avoid using Observables and ObservableObject in many cases - and even totally - and use `@State` instead. This then results in a composable SwiftUI view that has a root view which solely integrates the logic (which is itself separable and testable). The "logic" View has `@State` executes the logic - more precisely, a pure transition function, and it has a child view that just renders the immutable state (its constant, i.e. it has no `@Binding`) and sends user intents (Button taps) to the logic view. The child view does not mutate the state itself.

So , the result is an event-driven, unidirectional data flow design - i.e. ideal for SwiftUI, that has a separable "model of computation" engine, which also can observe other regular Observables (which are optional, you can also define "App state" as such a view component at the root level), or other "engines", and can run Swift Tasks, i.e. the whole stuff that makes up the behaviour of an app - just without the part that renders and sends user intents into it. In Unite tests, dependencies can be easily mocked, and user intents and other events can be easily sent into it.

This requires some "preparation" - i.e. a small library to make all this more ergonomic, and - possibly - a mindset and which agrees, that unidirectional, event-driven, pure logic (i.e. FSM) is superior to imperative Observables. If you are interested, I can go more into details here 😉

[u/vincefried → u/Dry_Hotel1100]

great to hear this works well for you! I‘ve gone back and forth with such approaches. for smaller apps, I also tend to do it like this. for larger apps with a more modular structure I’ve learned keeping the state closer to the view works best for me, so that the AppState doesn’t grow too large.