Mvvmcross: Support of converter chaining with fluent binding

[bspinner]

There's no support of converter chaining with fluent binding.

I'm going to implement it (edit: ouch). First idea that came to mind (all parameters left out for clarity; they should stay the same):

set.Bind().WithConversion().WithConversion();

First obvious problem: how to handle fallback values? Normally one could do

set.Bind().WithConversion().WithFallback()

Will it be sufficient to accept only one fallback per binding, so one converter fails we'll use that general fallback value OR do we need support for something like this:

set.Bind().WithConversion().WithFallback().WithConversion().WithConversion().WithFallback()?

edit: just reread the docs. According to them, one general WithFallback should be sufficient?

And: anyone having a distaste for/completely against this? why?

[MKuckert]

+1

[Cheesebaron]

As I said on Slack, I think it is an interesting proposition. Although, I don't see a lot of use for it. I don't mind a PR for this.

Maybe first think of what kind of situations this would be useful in. Usually I use ValueConverters to convert to a platform specific value, rest is simply up to the ViewModel.

So I guess I am a bit skeptic, but not against it.

[PelleRavn]

+1
I agree that there isn't much cases where it would be needed. But I have though about it a few times, where it would have been nice to have. So, can't argue against the possibility to do it, in rare cases.

[bspinner]

Indeed, it'll be rarely needed (therefore it's not implemented yet, I guess). Depends a bit on code style, too (e.g. I've never needed ValueCombiners like If and And and try to avoid them).

One could argue that by enabling converter chaining new people using Mvx could be more easily blundered into misusing converters for logic that should be in viewmodels...? Hmhm.

[azchohfi]

+1 to this!
Imagine, for example, a string format converter chained to a ToUpper converter. I would use this. Many times I had to make a custom converter specific for only one use case.

[bspinner]

One thing I don't like about this: it's breaking the current fluent-syntax.
Though one can call all fluent methods multiple times, all of them don't add anything up or similar, but overwrite everything the previous call would have done.

For example Bind().To().To() won't lead to a double binding, instead the first To()-call won't have any effect. Same with For(), WithFallback() etc. So a method like WithConverter*s* may be wise instead of changing the behaviour of WithConverter...

@lothrop Any ideas on this?

[MKuckert]

Or add an AndWithConversion method...
Maybe the binding should not be changed at all and a ChainedConverter with the specified behavior should be written instead.

[bspinner]

AndWithConversion would allow only one additional Converter, not "infinite", as long we're trying to not break the syntax.

[lothrop]

I've had a project where the ViewModel just contained legacy models and I had to do a lot of adaptions when binding. It's not optimal since you'll have to implement this logic for each platform.

I like multiple WithConversion() instead of a WithConversions(params). Any idea how this would work with declarative bindings?

[bspinner]

@lothrop By "declarative bindings" you mean those like in android? Should be possible already:
https://stackoverflow.com/questions/18019042/is-chaining-converters-possible-in-mvvmcross

[cfin-mt]

Has this been implemented yet? I just tried it and it built fine but did not seem to apply the converters correctly.

[bspinner]

@cfin-mt Nope, sorry. Back then I solved it with a proper property in the viewmodel and went on with other stuff.
By now I'm skeptic whether we should implement this at all.

[nickrandolph]

@bspinner any further thoughts on whether we should continue work on this?

[bspinner]

At this point of time I'd say we can scrap this idea.
Haven't needed it since back then.

Worst case could be people starting using this in cases where a better prepared property would have been the better choice.

So: close this. :)

[nickrandolph]

If someone wants to take charge of this feature we can reopen this issue - closing for now.

[Oleh-Kosiakov]

Just though it won't be bad idea in case if we need to use some built-in value converters like "Visibility".
For example for toggling visibility of two items on the view, something like:

bs.Bind(inetConnectedIcon).For(v => v.Visibility).To(vm => vm.IsConnected).WithConvervsion("Visibility");
bs.Bind(inetDisconnectedIcon).For(v => v.Visibility).To(vm => vm.IsConnected).WithConversion("BoolInverter).WithOneMoreConvervsion("Visibility");