Support store.send(action, animated: true)?

[notcome]

I have one feature request for UIKit animation interoperability. Can we add something like store.send(action, animated: true) to enable/disable UIKit animation for state changes?

For implementation, I suppose we could have a task local value

enum UIAnimationLocals {
    @TaskLocal static var animated = false
}

and wrap the action sending code to a value override:

UIAnimationLocals.$animated.withValue(true) {
  store.send(.launchButtonDidTap)
}

If my understanding is correct, we could obtain the correct UIAnimationLocals.animated inside the observe block.

---

This would be very useful for interacting with UIKit code. For instance, for the StackNavigationController, we could use this to decide if we should push a view controller with (from a button tapping) or without (from a universal link) animation.

While what I just described could be added outside the library, we would lose interoperability with things like the future StackNavigationController. On the other hand, specifying an action to be animated or not is a good and universally accepted abstraction, whereas introducing a fully fledged animation specification system would be an overkill and hard to be introduced into existing codebase.

[mbrandonw]

Hi @notcome, I believe for UIKit there is something simpler. You can disable all animations for a lexical scope by doing something like this:

UIView.performWithoutAnimation {
  store.send(…)
}

[notcome]

I did some experiments with this and ran into two issues. First, this option could still be overridden by things like navigationController.setViewControllers(vcs, animated: true). We need to know if we are inside a no animation block regardless, and I believe there is no public API for that?

But the next issue is more serious. Inside an observe callback, we are in a new task enqueued to the main actor, right? That means we are out of the scope of a performWithoutAnimation, which is why I originally proposed the use of a task local value. I wasn't sure about this so I just did some experiment to double check this.

[mbrandonw]

We need to know if we are inside a no animation block regardless, and I believe there is no public API for that?

You can check that by using UIView.areAnimationsEnabled.

But the next issue is more serious. Inside an observe callback, we are in a new task enqueued to the main actor, right? That means we are out of the scope of a performWithoutAnimation, which is why I originally proposed the use of a task local value. I wasn't sure about this so I just did some experiment to double check this.

Yeah, that's true. This trick does not work well with observe.

We could technically propagate areAnimationsEnabled into the task. But also at the end of the day, observe does not play nicely with UIKit animations. The real problem is that Swift's observation tools still do not give us a way to be notified of the didSet of properties. Until then I'm not sure what we can do.

[acosmicflamingo]

I've never requested for this kind of functionality because of the following: if you are the kind of developer that cares about being very precise with your animation (like me), chances are you want complete control over how it behaves. Problem is, there are so many corner-cases beyond the scope of the TCA to handle animation in a way that would be satisfactory to this kind of developer 🙂

So to me, rather than try and integrate animation functionality to TCA for UIKit that I am pretty confident won't give me the results I want anyway, I'd rather that TCA doesn't touch animation for UIKit, and then I will handle all my animation logic within the view layer.

[acosmicflamingo]

To add, as Brandon said, Observation (or Swift concurrency for that matter) is not going to give you the perfect animations you're used to getting when you use UIKit/Combine. There's no way around it at this time (biggest culprit is this sort of thread hop that happens in some corner cases, like rotating your device), which is rather unfortunate because I do want to eventually go all-in on SwiftUI and Observation, but I would have to sacrifice the polished look I want in my apps.