What is wrong with the following test code ? When I enter a character into the field, the didSet goes into a recursive loop. If the inout + & are removed, the code functions as expected with didSet being triggered for each keystroke. Similarly, if I remove the #Published, but leave the inout and & the didSet recursion does not occur.
Why am I trying to do this? I have a form field type (a 4 char hex field) that requires common processing which is then re-encoded back to a base structure. Thus, the intent, is to abstract all the common code into a function that was triggered after each var had been set in the ModelView zone. This code is just a minimal example to reproduce the issue.
It looks like merely taking the address of an #published var triggers the associated didSet. An interpretation of this would be that using inout always re-writes the target var even if no change is made.
class A: ObservableObject
{
#Published var publishedVar = "abc" {
didSet {
print("didSet Triggered")
doNothing(commonText: &publishedVar)
}
}
private func doNothing(commonText: inout String)
{
}
}
struct ContentView: View {
#ObservedObject var a = A()
var body: some View {
TextField("dummy", text: $a.publishedVar)
}
}
In case it is relevant this is being run on Mac running Catlina as a Mac App (not IOS, or emulators). Xcode Version 12.4 (12D4e)
OK, I've tried done reading on sink and tried to follow the advice (updated class A below) and now I find that it is recursing within the doNothing function. Looks like I am missing something basic 8-(
class A: ObservableObject
{
var cancellable: AnyCancellable?
#Published var publishedVar: String = "def"
private func doNothing(commonText: inout String)
{
print("In doNothing \(commonText)")
}
init()
{
cancellable = $publishedVar.sink { value in
self.doNothing(commonText: &self.publishedVar)
print("saw sink \(value)")
}
}
}
The recursion will occur because of the inout argument to doNothing. Each time it is called it will set the result back to publishedVar.
Please also note, that $publishedVar.sink will be activated on willSet, not didSet, and so is not interchangeable with your original code.
If you want to be notified when a Published variable changes you shouldn’t be using didSet instead you should use combine and observe the variable.
I.E
$publishedVar.sink {
print("didSet Triggered")
doNothing(commonText: &publishedVar)
}...
Related
I have a lazy property in a struct and every time I access it, it mutates the struct.
var numbers = [1,2,3]
struct MyStruct {
lazy var items = numbers
}
class MyClass {
var myStructPropery: MyStruct = MyStruct() {
didSet {
print(myStructPropery)
}
}
}
var myClass = MyClass()
myClass.myStructPropery.items
myClass.myStructPropery.items
myClass.myStructPropery.items
Result:
Print (didSet) will be called every time.
The ideal behaviour should be first time mutation only (since that's how lazy variables behave). Is this a bug in Swift or am I doing something wrong?
What you are seeing is is that the observed property items has notified its observer that it has been mutated because it was accessed, and a lazy variable is by definition mutating since it will be set at a later time. Therefore didSet gets called to handle this.
The lazy variable is actually only set once even though it signals that it has mutated and the property myStructPropery is only mutated once when the variable is first set but is the same instance after that.
Here is how we can verify this, first change the lazy var declaration so it's more like how we usually declare such a variable
lazy var items: [Int] = { numbers }()
and then add a print statement
lazy var items: [Int] = {
print("inside lazy")
return numbers
}()
If we now run the test code
var myClass = MyClass()
myClass.myStructProperty.items
myClass.myStructProperty.items
myClass.myStructProperty.items
we see that "inside lazy" only prints once. To verify that the property myStructProperty isn't changed we can make the struct conform to Equatable and perform a simple check inside didSet
didSet {
if oldValue != myStructProperty {
print(myStructProperty)
}
}
Now running the test we see that the print inside didSet is never executed so myStructProperty is never changed.
I have no idea if this behaviour is a bug but personally it feels like it might be complicate for the property observer to stop observing a lazy property once it was accessed or for a lazy var to not be defined as mutating once it is set.
I started debugging this with following set up -
var numbers = [1,2,3]
struct MyStruct {
lazy var items = numbers
}
class MyClass {
var myStructPropery: MyStruct = MyStruct() {
didSet {
// Changed this to make sure we are not invoking getter here
print("myStructPropery setter called")
}
}
}
let myClass = MyClass()
myClass.myStructPropery.items
myClass.myStructPropery.items
myClass.myStructPropery.items
I can reproduce the problem on Xcode 12.5 using Swift 5.4.
Attempt 1 : Turn var numbers into let numbers - Does NOT work.
let numbers = [1,2,3]
Attempt 2 : Assign the value inline without using an extra variable - Does NOT work.
struct MyStruct {
lazy var items = [1,2,3]
}
Attempt 3 : Assign the value inline using the full blown getter syntax - Does NOT work.
struct MyStruct {
lazy var items: [Int] = {
return [1,2,3]
}()
}
At this point, we are out of options to try. Even though we can clearly see that return [1,2,3] in the last attempt is executed exactly once, the MyClass.myStructPropery.modify is called repeatedly on access to items.
Maybe Swift Forums is a better place to discuss this.
Currently I have the code below which I'm trying to use as a navigation switch so I can navigate through different views without using the crappy NavigationLinks and otherwise. I'm by default a WebDev, so I've been having a mountain of issues transferring my knowledge over to Swift, the syntax feels completely dissimilar to any code I've written before. Anyways, here's the code;
import Foundation
import Combine
import SwiftUI
class ViewRouter: ObservableObject {
let objectWillChange: PassthroughSubject<ViewRouter,Never>
#Published var currentPage: String = "page1" {
didSet {
objectWillChange.send(self)
}
}
init(currentPage: String) {
self.currentPage = currentPage
}
}
As you can see, it's really simple, and I just use the object to switch values and display different views on another file, the only errors which prevent me from building it is the fact that the initializer is saying "Return from initializer without initializing all stored properties", even though the only variable is the currentPage variable which is defined. I know it's saying that objectWillChange is not defined by the message, but objectWillChange doesn't have any value to be assigned. Any help would be appreciated.
You just declare objectWillChange, but don't initialise it.
Simply change the declaration from
let objectWillChange: PassthroughSubject<ViewRouter,Never>
to
let objectWillChange = PassthroughSubject<ViewRouter,Never>()
However, using a PassthroughSubject shouldn't be necessary. currentPage is already #Published, so you can simply subscribe to its publisher. What you are trying to achieve using a PassthroughSubject and didSet is already defined by the swiftUI property wrappers, ObservableObject and Published.
class ViewRouter: ObservableObject {
#Published var currentPage: String
init(currentPage: String) {
self.currentPage = currentPage
}
}
Then you can simply do
let router = ViewRouter(currentPage: "a")
router.$currentPage.sink { page in print(page) }
router.currentPage = "b" // the above subscription prints `"b"`
I have a class, a “clock face” with regular updates; it should display an array of metrics that change over time.
Because I’d like the clock to also be displayed in a widget, I’ve found that I had to put the class into a framework (perhaps there’s another way, but I’m too far down the road now). This appears to have caused a problem with SwiftUI and observable objects.
In my View I have:
#ObservedObject var clockFace: myClock
In the clock face I have:
class myClock: ObservableObject, Identifiable {
var id: Int
#Publish public var metric:[metricObject] = []
....
// at some point the array is mutated and the display updates
}
I don’t know if Identifiable is needed but it’s doesn’t make any difference to the outcome. The public is demanded by the compiler, but it’s always been like that anyway.
With these lines I get a runtime error as the app starts:
objc[31175] no class for metaclass
So I took off the #Published and changed to a manual update:
public var metric:[metricObject] = [] {
didSet {
self.objectWillChange.send()`
}
}
And now I get a display and by setting a breakpoint I can see the send() is being called at regular intervals. But the display won’t update unless I add/remove from the array. I’m guessing the computed variables (which make up the bulk of the metricObject change isn’t being seen by SwiftUI. I’ve subsequently tried adding a “dummy” Int to the myClock class and setting that to a random value to trying to trigger a manual refresh via a send() on it’s didSet with no luck.
So how can I force a periodic redraw of the display?
What is MetricObject and can you make it a struct so you get Equatable for free?
When I do this with an Int it works:
class PeriodicUpdater: ObservableObject {
#Published var time = 0
var subscriptions = Set<AnyCancellable>()
init() {
Timer
.publish(every: 1, on: .main, in: .default)
.autoconnect()
.sink(receiveValue: { _ in
self.time = self.time + 1
})
.store(in: &subscriptions)
}
}
struct ContentView: View {
#ObservedObject var updater = PeriodicUpdater()
var body: some View {
Text("\(self.updater.time)")
}
}
So it's taken a while but I've finally got it working. The problem seemed to be two-fold.
I had a class defined in my framework which controls the SwiftUI file. This class is sub-classed in both the main app and the widget.
Firstly I couldn't use #Published in the main class within the framework. That seemed to cause the error:
objc[31175] no class for metaclass
So I used #JoshHomman's idea of an iVar that's periodically updated but that didn't quite work for me. With my SwiftUI file, I had:
struct FRMWRKShape: Shape {
func drawShape(in rect: CGRect) -> Path {
// draw and return a shape
}
}
struct ContentView: View {
#ObservedObject var updater = PeriodicUpdater()
var body: some View {
FRMWRKShape()
//....
FRMWRKShape() //slightly different parameters are passed in
}
}
The ContentView was executed every second as I wanted, however the FRMWRKShape code was called but not executed(?!) - except on first starting up - so the view doesn't update. When I changed to something far less D.R.Y. such as:
struct ContentView: View {
#ObservedObject var updater = PeriodicUpdater()
var body: some View {
Path { path in
// same code as was in FRMWRKShape()
}
//....
Path { path in
// same code as was in FRMWRKShape()
// but slightly different parameters
}
}
}
Magically, the View was updated as I wanted it to be. I don't know if this is expected behaviour, perhaps someone can say whether I should file a Radar....
I would like to use Combine's #Published attribute to respond to changes in a property, but it seems that it signals before the change to the property has taken place, like a willSet observer. The following code:
import Combine
class A {
#Published var foo = false
}
let a = A()
let fooSink = a.$foo.dropFirst().sink { _ in // `dropFirst()` is to ignore the initial value
print("foo is now \(a.foo)")
}
a.foo = true
outputs:
foo is now false
I'd like the sink to run after the property has changed like a didSet observer so that foo would be true at that point. Is there an alternative publisher that signals then, or a way of making #Published work like that?
There is a thread on the Swift forums for this issue. Reasons of why they made the decision to fire signals on "willSet" and not "didSet" explained by Tony_Parker
We (and SwiftUI) chose willChange because it has some advantages over
didChange:
It enables snapshotting the state of the object (since you
have access to both the old and new value, via the current value of
the property and the value you receive). This is important for
SwiftUI's performance, but has other applications.
"will" notifications are easier to coalesce at a low level, because you can
skip further notifications until some other event (e.g., a run loop
spin). Combine makes this coalescing straightforward with operators
like removeDuplicates, although I do think we need a few more grouping
operators to help with things like run loop integration.
It's easier to make the mistake of getting a half-modified object with did,
because one change is finished but another may not be done yet.
I do not intuitively understand that I'm getting willSend event instead of didSet, when I receive a value. It does not seem like a convenient solution for me. For example, what do you do, when in ViewController you receiving a "new items event" from ViewModel, and should reload your table/collection? In table view's numberOfRowsInSection and cellForRowAt methods you can't access new items with self.viewModel.item[x] because it's not set yet. In this case, you have to create a redundant state variable just for the caching of the new values within receiveValue: block.
Maybe it's good for SwiftUI inner mechanisms, but IMHO, not so obvious and convenient for other usecases.
User clayellis in the thread above proposed solution which I'm using:
Publisher+didSet.swift
extension Published.Publisher {
var didSet: AnyPublisher<Value, Never> {
self.receive(on: RunLoop.main).eraseToAnyPublisher()
}
}
Now I can use it like this and get didSet value:
self.viewModel.$items.didSet.sink { [weak self] (models) in
self?.updateData()
}.store(in: &self.subscriptions)
I'm not sure if it is stable for future Combine updates, though.
UPD: Worth to mention that it can possibly cause bugs (races) if you set value from a different thread than the main.
Original topic link: https://forums.swift.org/t/is-this-a-bug-in-published/31292/37?page=2
You can write your own custom property wrapper:
import Combine
#propertyWrapper
class DidSet<Value> {
private var val: Value
private let subject: CurrentValueSubject<Value, Never>
init(wrappedValue value: Value) {
val = value
subject = CurrentValueSubject(value)
wrappedValue = value
}
var wrappedValue: Value {
set {
val = newValue
subject.send(val)
}
get { val }
}
public var projectedValue: CurrentValueSubject<Value, Never> {
get { subject }
}
}
Further to Eluss's good explanation, I'll add some code that works. You need to create your own PassthroughSubject to make a publisher, and use the property observer didSet to send changes after the change has taken place.
import Combine
class A {
public var fooDidChange = PassthroughSubject<Void, Never>()
var foo = false { didSet { fooDidChange.send() } }
}
let a = A()
let fooSink = a.fooDidChange.sink { _ in
print("foo is now \(a.foo)")
}
a.foo = true
Before the introduction of ObservableObject SwiftUI used to work the way that you specify - it would notify you after the change has been made. The change to willChange was made intentionally and is probably caused by some optimizations, so using ObservableObjsect with #Published will always notify you before the changed by design. Of course you could decide not to use the #Published property wrapper and implement the notifications yourself in a didChange callback and send them via objectWillChange property, but this would be against the convention and might cause issues with updating views. (https://developer.apple.com/documentation/combine/observableobject/3362556-objectwillchange) and it's done automatically when used with #Published.
If you need the sink for something else than ui updates, then I would implement another publisher and not go agains the ObservableObject convention.
Another alternative is to just use a CurrentValueSubject instead of a member variable with the #Published attribute. So for example, the following:
#Published public var foo: Int = 10
would become:
public let foo: CurrentValueSubject<Int, Never> = CurrentValueSubject(10)
This obviously has some disadvantages, not least of which is that you need to access the value as object.foo.value instead of just object.foo. It does give you the behavior you're looking for, however.
I am trying to leverage SwiftUI and Combine to store user defaults for my application. Looking at suggestions in a few other posts, I have updated my code as you see below. However, I am now getting the error of "Referencing instance method 'send()' on 'Subject' requires the types 'Setup' and 'Void' be equivalent". It has been suggested that I change "Setup" to void in the PassthroughSubject, however this then gives a hard crash in the app at startup - " Fatal error: No observable object of type Setup.Type found."
I am at a bit of loss... any pointers would be welcomed.
============== DataStoreClass ============
import SwiftUI
import Foundation
import Combine
class Setup: ObservableObject {
private var notificationSubscription: AnyCancellable?
let objectWillChange = PassthroughSubject<Setup,Never>()
#UserDefault(key: "keyValueBool", defaultValue: false)
var somevalueBool: Bool {
didSet{
objectWillChange.send() // <====== Referencing instance method 'send()' on 'Subject' requires the types 'Setup' and 'Void' be equivalent
}
}
init() {
notificationSubscription = NotificationCenter.default.publisher(for: UserDefaults.didChangeNotification).sink { _ in
self.objectWillChange.send()
}
}
}
============= property wrapper ===========
import Foundation
#propertyWrapper
struct UserDefault<T> {
let key: String
let defaultValue: T
var wrappedValue: T {
get {
UserDefaults(suiteName: "group.com.my.app")!.value(forKey: key) as? T ?? defaultValue
} set {
UserDefaults(suiteName: "group.com.my.app")!.set(newValue, forKey: key)
}
}
}
The error comes from the fact that you have declared your Output type as Setup, but you are calling objectWillChange with Void.
So you have to pass self to objectWillChange:
self.objectWillChange.send(self)
Important thing to notice is that you should call objectWillChange not in didSet but in willSet:
var somevalueBool: Bool {
willSet{
objectWillChange.send(self
}
}
You never set somevalueBool, so this bit of code will not get called anyway.
Your setup should look roughly like this:
class Setup: ObservableObject {
private var notificationSubscription: AnyCancellable?
public let objectWillChange = PassthroughSubject<Setup,Never>()
#UserDefault(key: "keyValueBool", defaultValue: false)
var somevalueBool: Bool
init() {
notificationSubscription = NotificationCenter.default.publisher(for: UserDefaults.didChangeNotification).sink { _ in
self.objectWillChange.send(self)
}
}
}
The send method requires you to pass the input type of the subject, or a failure completion. So your send lines should pass the Setup;
objectWillChange.send(self)
That said, in most SwiftUI code, PassthroughSubject is <Void, Never> (such that send() does not require a parameter). It's not clear what the source of the crash you're describing is; we would need to see the code that's involved in the crash to debug that. I haven't reproduced it so far.
SwiftUI doesn't use a PassthroughSubject, it uses an ObservableObjectPublisher. I am pretty sure that that is an alias for PassthroughSubject<Void, Never> but I'm not sure. The ObservableObject protocol defines a correct objectWillChange for you so the best thing you can do is to remove your definition.
The publisher is objectWillChange and as its name suggests it should be sent in willSet and not didSet, I don't suppose that it matters much but Apple changed from didSet to willSet and my guess is that they had a good reason.