How to use LazyImageView/LazyImage in a testable way

[nikita-bor]

Hi!

In our project we've recently adopted Nuke. Really appreciate all the efforts, the framework is great! However there're two scenarios we're not sure how to implement correctly.

1. Using NukeUI components LazyImageView/LazyImage with custom network stack
2. Completely controlling LazyImageView/LazyImage in snapshot tests

Both of these scenarios are kind of covered with an ability to create custom ImagePipelines with custom DataLoaders inside. We noticed, that if we overwrite ImagePipeline.shared with our own pipeline (with custom network stack in production and some configurable mock pipeline in tests), all the NukeUI components will use it. But this overwrite triggers swift concurrency warning,

The warning makes sense, access to shared instance probably should be serialized. Perhaps there're ways to silence it from our side, but may be there's a completely different perspective to achieve what we want? Is it even intended to be able to overwrite ImagePipeline.shared instance?

Thanks for any advice!

[kean]

Hi,

Completely controlling LazyImageView/LazyImage

There is a way to change the pipeline on a per-view basic. For mocking it completely, I suggest creating a protocol, rolling out your custom mock, and using a factory method to create the views.

But this overwrite triggers swift concurrency warning,

This is now fixed in Nuke 11.5.1. Yes, the setter is designed to be public. But previously it only really supported one scenario: setting the pipeline on app launch and never touching it again.