Breaking changes after update from 4.2.0

[denandreychuk]

We had our own internal implementation of SwiftUI wrapper before it was officially supported by Lottie. Due to the introduction of SynchronouslyBlockingCurrentThread, we use that API in specific use-cases where we don't want to provide placeholders and where blocking would be more beneficial for the UX in that context.

Now that Lottie offers first-party support, we want to start a soft-migration, but it still requires some specific usage of DotLottieFile.SynchronouslyBlockingCurrentThread.named, which eventually throws a shouldn't be called on the main thread exception.

This can be overcome with a private queue sync dispatch, but I'm not sure about potential regressions across the code base. I'd prefer not to introduce these changes due to the high risk involved.

I wonder if it's necessary to throw an exception. Perhaps a simple warning or a note would suffice. We plan to remove use of SynchronouslyBlockingCurrentThread, but later in the development cycle.

wdyt?

[calda]

If you wish to ignore this specific assertion I'd suggest setting LottieLogger.shared equal to a custom implementation that ignores some / all of the LottieLogger.shared.assert calls.

[denandreychuk]

Oh, sounds good. Thank you!

[farfromrefug]

@calda how would you switch LottieLogger.shared ? i tried to extend LottieLogger but it is a final class

[denandreychuk]

LottieLogger.shared = LottieLogger(assert: { condition, message, file, line in })

[farfromrefug]

@denandreychuk awesome thanks clearly i am not good enough at swift :D