https://discord.umbraco.com logo
Powered by
Bit confused about Consuming Contexts vs newing Re...
# package-development
m
Bit confused about Consuming Contexts vs newing repositories...
After much head scratching got to a point where using the 
this.#workspace!.propertyViewGuard.addRule({...})
I have a property hidden for one root node over another based on it's documentType ( ps contentType... why do we still have this naming duality in Umbraco?? ) (it's a coming feature for one branch of the business over another) https://cdn.discordapp.com/attachments/1496617979620622376/1496618782146429241/visibility-guards.element.ts?ex=69ea8a5b&is=69e938db&hm=4bf0b994134a6136bda0acc984747785f83c80c98e46400150b61144b7a365bd&
Hopefully I've stumbled on a reasonable way to do this, any sense checking or education greatly appreciated.. So my real quandry was why I've ended up with
Copy code
import { UMB_DOCUMENT_WORKSPACE_CONTEXT, type UmbDocumentWorkspaceContext, UmbDocumentItemRepository } from "@umbraco-cms/backoffice/document";
this.#details = new UmbDocumentItemRepository(this);
and not some how consuming 
UMB_DOCUMENT_ITEM_REPOSITORY_ALIAS
?? like I have done with
Copy code
import { UMB_ANCESTORS_ENTITY_CONTEXT, type UmbAncestorsEntityContext } from "@umbraco-cms/backoffice/entity";
 this.consumeContext(UMB_ANCESTORS_ENTITY_CONTEXT, (context) => {
     this.#log("DEBUG: Ancestors Context Captured");
     this.#ancestors = context;
     this.#checkInitialization();
 });
j
You can consume repositories, because they also happen to be registered as contexts, but I don't think we ever really used that feature. The idea was that you could request something generic like 
UMB_ITEM_REPOSITORY
and the system would know where you are and hand you the relevant one - document, media, member, etc. However, simply new'ing up the repository you need when you need it is all you need. They are backed by singleton stores so you won't store duplicate data in memory or anything like that.
5 Views
PreviousNext
Powered by