Feature: Adds new method to extensionRegistry for appendCondition & appendConditions

[warrenbuckley]

Description

Adds two new methods to extensionRegistry to allow developers to append new conditions to an existing extension.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Motivation and context

Its not possible to update an extension such as Workspace Entity Action with a new condition. The current approach requires you to overwrite the extension. Which involves setting the same manifest meta properties and reimplementing an API to perform the same action as the core implementation of the button.

Scenario:
I want to show/hide the Save and Publish button based on a new condition and keep the existing functionality of the button without overhead of trying to overwrite the extension and keeping it in sync with the core implemetation.

How to test?

• Read over the PR
• Read the associated tests
• Run the tests - ensure it passes

Usage

// Add a condition with a specific config to Section2
const workspaceCondition:WorkspaceAliasConditionConfig = {
	alias: 'Umb.Condition.WorkspaceAlias',
	match: 'Umb.Workspace.Document'
};
extensionRegistry.addCondition('Umb.Test.Section.2', workspaceCondition);

const conditions:Array<UmbConditionConfigBase> = [
	{
		alias: 'Umb.Test.Condition.Valid'
	},
	{
		alias: 'Umb.Condition.WorkspaceAlias',
		match: 'Umb.Workspace.Document'
	} as WorkspaceAliasConditionConfig
]

extensionRegistry.addConditions('Umb.Test.Section.1', conditions);

Checklist

• If my change requires a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[warrenbuckley]

Thanks for re-running the tests for me @madsrasmussen
Now I will wait patiently until this gets reviewed or ask for any rework from me

[warrenbuckley]

Hiya @nielslyngsoe
This has been a real challenge for me today and I am looking forward to your input/feedback on this.

Adds _whenExtensionAliasIsRegistered as a promise so that we basically wait until the manifest is registered so late extensions will work as well.

This seems to work with my hack in an entrypoint file to hack with and the console logs the extension with the updated condition/s but its the tests I am struggling to get to work.

Warning

As this code is heavily worked from me trying to Google, read RXJS docs and talking with Copilot I am not fully in confident in this approach so please be gentle with me 🙈

[warrenbuckley]

Needing to take a break from this test that is failing to demonstrate late loaded extension.
Unsure if its my code or just my test implemtation at this point.

Could do with some cleverer people than me from HQ to give me some input/thoughts
@nielslyngsoe @madsrasmussen or @iOvergaard & others...

 🚧 Browser logs:
      About to go KABOOM..

 ❌ Prepend Conditions > allows conditions to be prepended when an extension is loaded later on
      Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
        at createTimeoutError (node_modules/@web/test-runner-mocha/dist/autorun.js:1:191490)
        at ds._timeoutError (node_modules/@web/test-runner-mocha/dist/autorun.js:1:195723)
        at node_modules/@web/test-runner-mocha/dist/autorun.js:1:193804

[nielslyngsoe]

Hi @warrenbuckley you should not be needing to prepend or append. It will give the same result. Currently the system spins up all conditions, the order means nothing. :-)

[warrenbuckley]

@nielslyngsoe I thought order would be important with last in winning surely?

• Condition A - ✅
• Condition B - ❌
• Condition C - ❌

For me I would have thought that the last one setting permitted to false I accept the extension to be loaded so it overrides the previous ones before it.

Or with this way it would prevent the extension as last one is false

• Condition A - ❌
• Condition B - ✅
• Condition C - ❌

or perhaps this I would expect condition C to then make the extension appear

• Condition A - ❌
• Condition B - ❌
• Condition C - ✅

So can you confirm how it works please @nielslyngsoe

Then happy to amend this PR once I fully grasp how conditions work.

Warning

Niels now confirmed that ALL must pass for it to be loaded in as an extension so the order is not important so the prepend stuff is not needed. If any one condition returns false then it won't load

• Condition A - ✅
• Condition B - ✅
• Condition C - ✅

[nielslyngsoe]

@warrenbuckley It works in the way that all the listed conditions has to be valid for the extension to be shown. Therefore the order doesn't matter. :-)

[nielslyngsoe]

Hi @warrenbuckley

I have refactored your code and written a few extra tests. I'm happy with the solution now.

Notice I went away for the Async approach as it turned out that appended conditions, would be appended late, like two JS cycles, from when a extension manifest got registered.

In other words, a late coming manifest, would be broadcasted and utilized by all subscribers, for then 2 cycles later to get the additional conditions appended. This was a unnecessary round trip, so I refactored so the additional conditions get appended before the manifest goes into the Extension Registry.

I will wait for the v15/dev branch to get up to date with v.14 before we merge. As you can see there is too many changes as part of this PR right now.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[nielslyngsoe]

I'm happy now :-)

[warrenbuckley]

WHOOP WHOOP 🎉
Off to read the rework you done and see what I could have done better

[warrenbuckley]

Just so I am clear, this is for V15 only @nielslyngsoe ?