A store holds data throughout the session. It is used to create reactivity across different parts.
This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
A store is the link between a Resource and a Repository. A store is mainly taken from a Context API. In other words, we have to Consume the Context (Store) to get the Store.
Generally, a Store will hold one or more State Objects, with each Subject made available for Observation via Observables.
In this example, we created an ArrayState, A State which is specific to Arrays. This holds the data for one or more Observables to convey to outsiders.
This example shows how to use the store:
Here we added a method that returns an Observable that is specific to the requested product.
An example implementation using this method:
Create many Observables
A Store must hold different Observables, some exceptionally general and others highly specific, all in perspective of the types of observers we aim to accommodate.
This example gives some inspiration to how fine-grained this can become:
An observer of an Observable will only be triggered if the specific part of that data has changed. With this we can make a high-performance application, only triggering the parts that need to update when data is changed.
Ensure unique data
For incoming data to replace existing data, we need to clarify what makes an entry of the array unique. In the examples of this guide, each product has an id
. We have clarified this to the State by giving it the little method (product) => product.id
as part of its creation:
Communicate across different boundaries with the Context API
This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
The Context API enables receiving APIs. Depending on where your code is executed from, it affects which and what instances of APIs can be received.
The Context API enables an element or a controller to receive an API provided via any ascending element. In other words, it can receive APIs provided via a parent element or parent of a parent element, and so forth.
The Context API enables connections between Elements and APIs. DOM structure defines the context of which an API is exposed for. APIs are provided via an element and can then be consumed by any decending element.
There are different ways to consume a Context API. The most straightforward implementation is done on an Umbraco Element with a Context Token.
All Umbraco Context APIs have a Context Token which can be imported and used for consumption, for example:
The above example takes place in an Umbraco Element or Umbraco Controller.
The above examples utilize an Umbraco Controller to hook into an element's life cycle. This Controller is named UmbContextConsumerController
.
If you need to consume a Context API from a non-controller host, then look at the UmbContextConsumer
.
A Context Token is a context identifier and is generally a string matched with a type. In this way, users of the token can be sure to get the right type of context.
For additions to Contexts, we can use the API Aliases to identify the additional API. Using the same Context Alias for additional APIs will ensure that such API must be present with the first encounter of that Context Alias. Otherwise, a request will be rejected. In other words, if the addition is not part of the nearest matching Context, the request will be rejected.
Using API Alias only provides value when two or more APIs should share the same Context. This is needed for Context Extensions that are provided along with other Contexts.
The Token declared above can be used to provide an additional Context API at the same Element as another Context API is provided at. Below is an example of how the two APIs are made available.
This is no different than using two different Context Aliases. But it has an important effect on what happens if one of them is not provided. This is demonstrated in the example below:
The consumption of the Additional API will never happen as the token uses the same Context Alias as MY_API_TOKEN
. This means that any request containing this Context Alias will be stopped at the first API it encounters. To ensure addition to a specific context, do it locally at the nearest API that uses the same Context Alias.
This is only relevant if you are going to make multiple context API for the same context. Discriminator only gives value for consumption of Context APIs that have a varying interface. The backoffice uses this for the different types of Workspace Contexts.
In some cases, it is needed to have different APIs for the same context. For example, the Workspace Contexts.
If someone wants the workspace name, they might not care about the specific API of the Workspace Context. These implementations can use a standard Context Token with a type of generic Workspace Context.
The features related to Publishing in the Document Workspace Context do not require a new Context. However, we should not accidentally retrieve the workspace context of a parent workspace when in a Workspace. Therefore, we need to provide a workspace context in each workspace, and the one we retrieve is the one we will be using. Since Publishing is not part of the generic Workspace Context, check if the context is a Document Workspace Context and recast it accordingly.
To avoid each implementation taking care of this, Context Tokens can be extended with a Type Discriminator. This will discard the given API if it does not meet the necessary requirements. When it is the desired type, the API will be converted to the appropriate type.
This example shows how to create a discriminator Context Token that will discard the API if it is not a Publishable Context:
Context Token Example:
Implementation of Context Token Example:
This allows implementers to request a publishable context without needing to know the Type or how to identify the context.
In detail, the Context API will search for the first API that matches the alias My.Context.Token
, and not look further. If the API meets the type discriminator, it will be returned, otherwise the consumer will never reply.
You can provide a Context API from an Umbraco Element or Umbraco Controller:
Or with a Controller using a 'host' reference to Controller Host (Umbraco Element/Controller):
Make reactivity with Umbraco States
This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
Umbraco States enables you to create Observables based on a State. The Observables can then be observed, and when a change to the State occurs, all observers of Observables will be triggered.
Umbraco comes with a State type for the most common types of data:
Array State
Boolean State
Class State
Number State
Object State
String State
The Umbraco Element or Controllers comes with the ability to observe an Observable.
While observing all changes will result in the callback being executed.
The example below creates a State and then turns the whole state into an Observable, which then can be observed.
The value of a state can be changed via the setValue
method. This replaces the current data with new data.
The following example shows how to change the value of the state to hold item2
and item3
. As the example extends the example from above, it means that item1
is no longer part of the value of this state.
Observe part of a state
With the asObservablePart
method, you can set up an Observable that provides a transformed outcome, based on the State.
In the above example, the asObservablePart
mapping function will be executed every time there is a change to the State. If the result of the method is different than before it will trigger an update to its observers.
Learn how to work with data or request the data when extending the backoffice.
This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
Repositories are used for talking to the server by requesting data and getting notified about updates.
Context APIs work with “local/runtime” data and enables receiving APIs.
A store holds data throughout the session. It is used to create reactivity across different parts.
A reactive container holding data, when data is changed all its Observables will be notified.
This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
A repository is the Backoffices entry point to request data and get notified about updates. Each domain should register their own repository in the Backoffice.
With a repository we can have different data sources depending on the state of the app. It can be from a server, an offline database, a store, a Signal-R connection, etc. That means that the consumer will not have to be concerned how to access the data, add or remove items from a collection of items, etc. This means we get a loose connection between the consumer and the data-storing procedures hiding all complex implementation.
A repository has to be instanced in the context where it is used. It should take a host element as part of the constructor, so any contexts consumed in the repository (notifications, modals, etc.) get rendered in the correct DOM context.
A repository can be called directly from an element, but will often be instantiated in a context, like the Workspace Context.