ViewHandler mapper extension methods won't reliably fire if mapper methods are replaced

[PureWeen]

#4714 (comment)

If you write the following code

global::Microsoft.Maui.Handlers.ViewHandler.ViewMapper.AppendToMapping("BackgroundColor",
	(handler, view) =>
	{

	});

global::Microsoft.Maui.Handlers.ViewHandler.ViewMapper.AppendToMapping("Background",
	(handler, view) =>
	{

	});

These will not fire for Entry because the EntryHandler replaces the MapBackground mapping on its mapper which means the call never reaches ViewHandler. This also means if we end up adding mappings to for inherited views later on it will cause the users code to stop firing if they had attached to a base class previously

[bakerhillpins]

@PureWeen
Rather than write up a separate issue and link back to this I though it might be prudent to add to this issue since the end result is variability in Mapper function resolution. I've been trying to author a control that inherits and overrides the Microsoft.Maui.Controls.Label and found that it's not behaving as I'd expect with regard to the mapper and overriding.

For example: If I use the PropertyMapper constructor that takes a collection of IPropertyMappers:

	public PropertyMapper(params IPropertyMapper[] chained)

the order of the chained Mappers (arguments in the constructor) can effect which handler gets called when both mappers override the same key. This is due to the fact that the first handler short circuits the algo.

		else if (Chained is not null)
		{
			foreach (var ch in Chained)
			{
				var returnValue = ch.GetProperty(key);
				if (returnValue != null)
					return returnValue;
			}
		}

The Chained search algo above is duplicated in both the PropertyMapper.GetProperty(string key) and the PropertyMapper<TVirtualView, TViewHandler>.Add(string key, Action<TViewHandler, TVirtualView> action) methods. The Add method actually wraps up the inserted handler with this logic. It would seem that this duplication is unnecessary?

The indexer on the PropertyMapper<TVirtualView, TViewHandler> class also wraps up the stored handler in an empty delegate. If this extra delegate is necessary then the action returned from the GetProperty(key) call on the line above should be null checked as GetProperty can return null.

I.e. => action.Invoke(h, v)); should be: => action?.Invoke(h, v));

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Hi @PureWeen. We have added the "s/try-latest-version" label to this issue, which indicates that we'd like you to try and reproduce this issue on the latest available public version. This can happen because we think that this issue was fixed in a version that has just been released, or the information provided by you indicates that you might be working with an older version.

You can install the latest version by installing the latest Visual Studio (Preview) with the .NET MAUI workload installed. If the issue still persists, please let us know with any additional details and ideally a reproduction project provided through a GitHub repository.

This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[Zhanglirong-Winnie]

Verified this issue with Visual Studio Enterprise 17.9.0 Preview 2. Not repro this issue.