From AnyObserver to RxCocoa.Binding

[kasyanov-ms]

PR makes a binding implementation similar to UIImageView extension
The basic usage is:

viewModel
    .imageUrl
    .drive(imageView.kf.rx.image(placeholder: placeholder))
    .disposedBy(disposeBag)

But there is still one design issue. Since we cannot bind Observable<URL> to Binding<Resource>, the current workaround is Binding<URL?> return type. The other choices:

• Return Binding<Resource?>. The same element type as in the current version. The drawback is repeating map { $0 as Resource? } typecasting
• Separate Resource and URL bindings. Code duplicating

[rxswiftcommunity]

	Warnings
⚠️	It looks like code was changed without adding anything to the Changelog. If this is a trivial PR that doesn't need a changelog, add #trivial to the PR title or body.

Thanks a lot for contributing @kasyanov-ms! I've invited you to join the
RxSwiftCommunity GitHub organization – no pressure to accept! If you'd like
more information on what this means, check out our contributor guidelines
and feel free to reach out with any questions.

Generated by 🚫 dangerJS

[kasyanov-ms]

If PR is Ok, I'll update the changelog and examples

[freak4pc]

Thanks @kasyanov-ms. What's the up-side of switching from AnyObserver to Binder in this case? Especially given the fact Binder is just a wrapper for AnyObserver?

[kasyanov-ms]

Hello. AnyObserver keeps a strong reference to our UIImageView. I've made a simple project. The top image is binding to AnyObserver, we cannot deallocate it. The bottom one is from the fork, it works as it should be.

[freak4pc]

This is really interesting. I would imagine the [base] capture group would make sure to properly keep a safe reference, but I think the issue is base refers to Kingfisher and not its associated ImageView.

Anyways, looks good to me! Thank you.

[freak4pc]

Thanks for your contribution, and welcome to RxSwiftCommunity!

[kasyanov-ms]

I think the issue is base refers to Kingfisher and not its associated ImageView

Yeap, it was possible to achieve the same with weak base.base, but the solution becomes a little bit dirty