-
Notifications
You must be signed in to change notification settings - Fork 2.8k
V16: Context Api can unprovide Contexts #19113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
# Conflicts: # src/Umbraco.Web.UI.Client/src/packages/core/workspace/components/workspace-split-view/workspace-split-view-variant-selector.element.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the Context API to support unproviding contexts and aligns type definitions by using UmbContextMinimal. Key changes include updating callback types to allow undefined instances, refactoring event target handling in the context consumer, and adjusting generics and type casts across multiple context‐related files.
Reviewed Changes
Copilot reviewed 265 out of 267 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/Umbraco.Web.UI.Client/src/libs/context-api/consume/context-request.event.ts | Updated UmbContextCallback to allow undefined, which supports unproviding functionality. |
| src/Umbraco.Web.UI.Client/src/libs/context-api/consume/context-consumer.ts | Added a getHostElement method, refactored event listener handling, and introduced a new property for current event targets. |
| src/Umbraco.Web.UI.Client/src/libs/context-api/consume/context-consumer.test.ts | Modified tests to align with updated type signatures and ensure callbacks are only invoked once. |
| src/Umbraco.Web.UI.Client/src/libs/context-api/consume/context-consumer.controller.ts | Updated generics to extend UmbContextMinimal for consistency. |
| src/Umbraco.Web.UI.Client/src/libs/class-api/context-base.class.ts | Simplified generics by removing redundant parameters and introduced a type cast using “as any”. |
| Other files (installer, preview, backoffice, app, and example contexts) | Updated type parameters and introduced optional chaining to improve runtime safety. |
Files not reviewed (2)
- src/Umbraco.Web.UI.Client/package-lock.json: Language not supported
- src/Umbraco.Web.UI.Client/package.json: Language not supported
Makes the Context APi able to un-provide a context.
Important
This brings a Breaking Change to all Context Consumptions (
this.consumeContext()), which may be simple for you to fix, but can also be complex so please read this guide to make sure your Context Consumptions and the code relying on it is handled correctly.This feature is needed to support that a context can be removed again, previously once you got a reference to a Context you would keep that until a new one comes ahead and replaces it. With this feature it can be removed again.
This means that consumeContext can now return undefined, and will do so in many cases. Like when your element is disconnected, this also means that your consumption will now be triggered when your element is disconnected to then stop the relation going on with the Context.
In order to make your code follow nicely along with this change, you will have to ensure your implements of context consumptions handles if the context comes back as
undefined. As demonstrated in this example:Notice the
?before.getValue(). In the above casethis.valuewill be set toundefined, once the context is no longer available.Context consumptions with observations, should then be implemented in this way:
Again notice the
?before.unique. In the above case,uniquewill get the value ofundefinedin the observation callback once the context is no longer available. This means the whole chain will be able to react to the Context now begin gone. Leaving the unique property as undefined.Can I choose to back out when the context is unprovided?
Yes, but to use the example above this is not ideal.
See the following case:
In this case, the Observation will not be stopped and neither will the effects of the observation be reversed. In this case
_uniquewill still have the value despite the context not present any longer.