Modifying state during view update, this will cause undefined behavior.

[denandreychuk]

if animationSource.animation !== view.animation {
  view.loadAnimation(animationSource)
  animationDidLoad?(animationSource)
}

animationDidLoad?(animationSource) cause runtime warning when modifying @State of parent view in callback

[calda]

Using DispatchQueue.main.async in your callback before modifying the state of the view should avoid the runtime warning, right?

[denandreychuk]

Yeap, DispatchQueue.main.async fixes the issue. But this is something that you expect from the Lottie itself as it creates a lot of boilerplate code on a caller side.

[calda]

I chatted with @miguel-jimenez-0529 and we think it makes sense to wrap the internal animationDidLoad?(animationSource) call with a DispatchQueue.main.async.

Would you be interested in posting a PR with this change, and a comment explaining why the dispatch queue async is necessary?

[denandreychuk]

@calda The more I think, the more I have doubts about DispatchQueue.main.async as it creates async context outside of SwiftUI lifecycle. I tested the case when we rapidly change @State of parent view to swap different animations and animationDidLoad sometimes calls after onDisappear, which is not correct behavior as it should be tied to the view lifecycle

[calda]

Do we need to use an .onChange modifier somehow then?

[denandreychuk]

I'm still not sure what's the correct way to solve it, cause still testing how updateUIView ties into lifecycle, but my initial thought was to use task(:id) which triggers to Equtable changes