refactor(core): Add an ActionResolver option to Dispatcher.

[tbondwilkinson]

This will enable internal usages to migrate from ActionResolver in EventContract to ActionResolver in Dispatcher.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.io application / infrastructure changes
• Other... Please describe:

[tbondwilkinson]

TESTED=TGP

[tbondwilkinson]

DIFFBASE=#55721

[AndrewKushnir]

LGTM, just left a couple minor (non-blocking) comments.

[AndrewKushnir]

Just as an idea: I was thinking if we can make the ActionResolver tree-shakable and have a special function call that would bring the ActionResolver code, for example:

new EventContract(new EventContractContainerManager(), withActionResolver())

However, if we want to enable it by default (as we have it in this PR), the function would be referenced internally within the EventContract class anyways and ActionResolver would remain non-tree-shakable.

This is not a blocker for the PR, just an idea that I wanted to share.

[tbondwilkinson]

The way this written is intentionally for dead-code-elimination with JSCompiler.

I had previously tried:

  constructor(
    containerManager: EventContractContainerManager,
    private readonly actionResolver: ActionResolver | null = new ActionResolver(),
)

But JSCompiler could not remove that, because it wasn't sure based on the callsite that passed null that it was actually unused. JSCompiler does a very good job of inferring what can be deleted when the code to be deleted is wrapped in boolean, but a much worse job when the parameter is a more complex type.

So I believe withActionResolver() would not appropriately DCE, based on my explorations. I could be misunderstanding what you're proposing though.

[AndrewKushnir]

nit:

Suggested change

	if (this.useActionResolver) {
	this.actionResolver!.resolve(eventInfo);
	}
	this.actionResolver?.resolve(eventInfo);

[tbondwilkinson]

Likewise, this is specifically for DCR - the boolean allows JSCompiler to appropriately inline the value as constant and then remove the code.

[pkozlowski-opensource]

LGTM

Reviewed-for: public-api

[rahatarmanahmed]

I assume that we expect ppl to call addA11y on the action resolver manually when using it on the dispatcher, right?

[tbondwilkinson]

I assume that we expect ppl to call addA11y on the action resolver manually when using it on the dispatcher, right?

That's correct. Here's a code sample from a future CL that updates Wiz to use ActionResolver.

    const actionResolver =
        new ActionResolver({syntheticMouseEventSupport: true});
    actionResolver.addA11yClickSupport(
        a11yClick.updateEventInfoForA11yClick,
        a11yClick.preventDefaultForA11yClick,
        a11yClick.populateClickOnlyAction);

This isn't a great API! But it's temporary. Once we refactor to get everyone onto ActionResolver in Dispatcher, we no longer need the deferred support, and it can just become a boolean, like syntheticMouseEventSupport.

[dylhunn]

reviewed-for: public-api

[tbondwilkinson]

Caretaker note: cl/633383853 must be patched into sync CL to update internal BUILD rules.

[tbondwilkinson]

@AndrewKushnir re-requested review for public-api

[AndrewKushnir]

Reviewed-for: public-api

[tbondwilkinson]

This will cause a merge conflict with #55756 so I'll wait for that

[atscott]

This PR was merged into the repository by commit f1e3ec2.