Genesis Foundation Store

foundation-store leverages the DI container to provide a preformat, decoupled and testable way to manage application state that adheres to our best practices. Using foundation-store is completely optional, as you may decide that your application doesn't warrant a store, or that you would prefer to use a store you are more familiar with. The system is flexible, so you can use whatever you like to handle application level state management, but you should be mindful of degrading performance.

Background

Client apps today manage application state in different ways. These apps might leverage common third party stores likes Redux, or use none at all, peppering @attr and @observable properties in different classes, and at various levels of DOM hierarchy. With the latter business logic might start creeping into our components, every component becomes smart instead of being dumb, providing shared access to data becomes difficult, tests require lots of mocks, things get hard to refactor etc. We should aim to lift state where possible, and it makes sense to do so.

We need to remember that although our components will be used in Genesis applications, they may also be used in isolation in third party client applications.

Migration

Hopefully you're keen to try foundation-store, and have used solutions like Redux in the past. If so you may find the following "Solution X" to foundation-store terminology migration guide beneficial.

Redux

• Action. Translates to a standard CustomEvent. These event types are defined in a store's EventDetailMap. Here's the StoreRootEventDetailMap for example.
• Dispatch. Use the component's $emit method in conjunction with the EventEmitter mixin to strongly type it with store event maps.
• Action Creator. Create the CustomEvent.detail however and whenever you like. When you're ready, emit the event and detail pairing as per an EventDetailMap via the component's $emit api, which in turn creates and sends the CustomEvent.
• Reducer. Use the store's createListener method to create a synchronous event listener which you can commit values to the store from. These listeners only receive events, so new values may come from CustomEvent.detail payloads, and / or reading from the store itself which these handlers are members of.
• Effect. Use the store's createAsyncListener method to create an async event listener which can run Side Effects. Similar to the Reducer context above, however you should NOT commit values to the store in these, but instead emit outcome events, ie. success / failure, which can be handled by synchronous listeners.
• Slice. A store fragment. A part of the store with a specific purpose, domain model.
• Selector. A simple getter on a store fragment.

Setup

Create a root store.ts file somewhere, for example ./store/store.ts. This will be the root store for the application, which may consist for other store fragments. Each fragment could be considered as a domain, with a single purpose. This setup allows us to isolate data and provide the component trees access to only the data they really need to function.

Example root store: (insert see examples link)

1import {CustomEventMap, EventListenerMap, registerEmitter} from '@genesislcap/foundation-events';
2import {
3  AbstractStoreRoot,
4  StoreRoot,
5  StoreRootEventDetailMap,
6  registerStore,
7} from '@genesislcap/foundation-store';
8import {observable, volatile} from '@microsoft/fast-element';
9import {DesignSystem} from './designSystem';
10import {Position} from './position';
11import {Trades} from './trades';
12
13/**
14 * 1: Define any store custom event details for more complex payloads.
15 * See https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/detail
16 */
17export interface StoreZooEventDetail {
18  zoo: Animal[];
19  location: string;
20}
21
22/**
23 * 2: Define store event to event detail map.
24 * For the root store this should be a union of StoreRootEventDetailMap.
25 */
26export type StoreEventDetailMap = StoreRootEventDetailMap & {
27  'store-foo': void;
28  'store-bar': boolean;
29  'store-zoo': StoreZooEventDetail; // < details with more than one property
30  'store-zoo-animals': Animal[];
31}
32
33/**
34 * 3: Extend built in event maps so that addEventListener/removeEventListener are aware of our events for code completion
35 */
36declare global {
37  interface HTMLElementEventMap extends CustomEventMap<StoreEventDetailMap> {}
38}
39
40/**
41 * 4: Define internal event to event detail map.
42 */
43type InternalEventDetailMap = {
44  'store-zoo-success': SomeResponse;
45  'store-zoo-error': Error;
46}
47
48/**
49 * 5: Define entire readonly store made up of store fragments and or additional properties.
50 */
51export interface Store extends StoreRoot {
52  /**
53   * Store properties
54   */
55  readonly prop1: number;
56  readonly prop2: number;
57  readonly someToggle: boolean;
58  readonly derivedData: number;
59  readonly volatileDerivedData: number;
60  /**
61   * Store fragments
62   */
63  readonly designSystem: DesignSystem;
64  readonly notifications: Notifications;
65  readonly positions: Positions;
66  readonly trades: Trades;
67  /**
68   * Store event handlers
69   */
70  onFooEvent(event: CustomEvent<void>): void;
71  onBarEvent(event: CustomEvent<boolean>): void;
72  onZooEvent(event: CustomEvent<StoreZooEventDetail>): void;
73}
74
75/**
76 * 6: Define the default implementation
77 */
78class DefaultStore extends AbstractStoreRoot<Store, StoreEventDetailMap, InternalEventDetailMap> implements Store {
79  /**
80   * Store properties
81   */
82  @observable prop1: number = 10;
83  @observable prop2: number = 20;
84  @observable someToggle: boolean = true;
85
86  constructor(
87    /**
88     * 7: Inject any store fragments
89     */
90    @DesignSystem readonly designSystem: DesignSystem,
91    @Notifications readonly notifications: Notifications,
92    @Positions readonly positions: Positions,
93    @Trades readonly trades: Trades,
94  ) {
95    super(...arguments);
96
97    /**
98     * 8: Listeners not on the public interface can be created anonymously if you prefer
99     */
100    this.createListener<SomeResponse>('store-zoo-succes', (detail) => {
101      const {prop1, prop2, ...rest} = detail;
102      this.commit.prop1 = prop1;
103      this.commit.prop2 = prop2;
104    });
105    this.createErrorListener('store-zoo');
106  }
107
108  /**
109   * 8: Define your event listeners as per the interface. Please ensure you do so using arrow functions to aid binding.
110   * These handlers can be async if you would like to do some async work in them. We suggest you don't commit store
111   * mutations in async functions, instead raise an event which you can handle synchronously and commit from there so
112   * things are tracked correctly.
113   */
114  onFooEvent = this.createListener('store-foo', detail => {...});
115  onBarEvent = this.createListener<boolean>('store-bar', detail => this.commit.someToggle = detail); // < commit values to the store synchronously
116  onZooEvent = this.createAsyncListener<StoreZooEventDetail>('store-zoo', async (detail) =>
117    this.invokeAsyncAPI(
118      async () => this.someAsyncTask(detail), // < likely an injected service,
119      'store-zoo-error',
120      'store-zoo-success'
121    )
122  );
123
124  /**
125   * 9: Create getters for common derived data needs, similar to selectors in the Redux sense. These however do not
126   * need any special code as they are computing based on properties that are already observable. Derivied data with
127   * branching code paths needs to be marked as volatile.
128   */
129
130  get derivedData(): number {
131    return this.prop1 * this.prop2;
132  }
133
134  @volatile
135  get volatileDerivedData() {
136    return this.someToggle ? this.prop1 * this.prop2 : this.prop1 + this.prop2;
137  }
138}
139
140/**
141 * 10: Register the store which defines the DI key using the interface
142 */
143export const Store = registerStore<Store>(DefaultStore, 'RootStore');

Your root store is now ready to be injected into your application. Hopefully the above gives you a good idea of general store setup. The example might look a bit verbose, but in reality you can write a small store fragment in 20+ lines of code. For example:

1import {CustomEventMap} from '@genesislcap/foundation-events';
2import {AbstractStore, Store, registerStore} from '@genesislcap/foundation-store';
3import {observable} from '@microsoft/fast-element';
4
5export type TradeEntryUIEventDetailMap = { 'trade-entry-ui-open': boolean }
6
7declare global {
8  interface HTMLElementEventMap extends CustomEventMap<TradeEntryUIEventDetailMap> {}
9}
10
11export interface TradeEntryUI extends Store {
12  readonly isOpen: boolean;
13  onOpen(event: CustomEvent<boolean>): void;
14}
15
16class DefaultTradeEntryUI extends AbstractStore<TradeEntryUI, TradeEntryUIEventDetailMap> implements TradeEntryUI {
17  @observable isOpen: boolean;
18  onOpen = this.createListener<boolean>('trade-entry-ui-open', detail => this.commit.isOpen = detail);
19}
20
21export const TradeEntryUI = registerStore<TradeEntryUI>(DefaultTradeEntryUI, 'TradeEntryUI');

Store events

'store-connected'

In your main application class, likely ./src/main/main.ts, you need to fire a 'store-connected' event in-order to fully initialise the store.

1// ./main/main.ts
2
3type EventMap = StoreEventDetailMap & {...}; // < whatever other events you allow your custom element to emit
4
5/**
6 * MainApplication
7 * 
8 * @fires store-connected - Fires a custom 'store-connected' event after connection to connect the store.
9 * @fires store-ready - Fires a custom 'store-ready' event after connection to ready the store.
10 * @fires store-disconnected - Fires a custom 'store-disconnected' event after disconnection to unbind the store.
11 * 
12 * @public
13 */
14@customElement({ name, template, styles })
15export class MainApplication extends EventEmitter<EventMap>(FASTElement) {
16  /**
17   * @public
18   */
19  @Store store: Store; // < injected root store
20
21  /**
22   * @public
23   */
24  connectedCallback() {
25    super.connectedCallback();
26    this.addEventListeners();
27    this.readyStore();
28  }
29
30  /**
31   * @public
32   */
33  disconnectedCallback() {
34    super.disconnectedCallback();
35    this.removeEventListeners();
36    this.disconnectStore();
37  }
38
39  /**
40   * @internal
41   */
42  protected addEventListeners() {
43    this.addEventListener('store-connected', this.store.onConnected);
44  }
45
46  /**
47   * @internal
48   */
49  protected removeEventListeners() {
50    this.removeEventListener('store-connected', this.store.onConnected);
51  }
52
53  /**
54   * @internal
55   */
56  protected readyStore() {
57    this.$emit('store-connected', this);
58    /**
59     * Do some other work if needed.
60     */
61    this.$emit('store-ready', true);
62  }
63
64  /**
65   * @internal
66   */
67  protected disconnectStore() {
68    this.$emit('store-disconnected');
69  }
70}

The 'store-connected' event handler needs to be explicitly bound. When the root store handles 'store-connected', it auto binds all the store event listeners to the rootElement.

At this point you can start emitting strongly typed store events, and they will be handled by their corresponding store. See EventEmitter for more information.

'store-ready'

We've created an explicit store ready event to indicate when the store is ready to use, as you may wish to do some additional work upfront. It's not a hard requirement to emit this, but is considered best practice. If you've no work to do, you can just emit this right after 'store-connected'.

1// ./main/main.ts
2
3this.$emit('store-connected', this);
4/**
5 * Do some other work if needed.
6 */
7this.$emit('store-ready', true);

'store-disconnected'

Emitting 'store-disconnected' will remove all the previously bound event listeners.

1// ./main/main.ts
2
3disconnectedCallback() {
4  super.disconnectedCallback();
5  this.$emit('store-disconnected');
6}

Using store fragments

To use a store fragment in your custom element simply inject it using its interface as the DI key.

1export type EventMap = TradeEntryEventDetailMap;
2
3export class TradeEntryForm extends EventEmitter<EventMap>(FASTElement) {
4  @TradeEntry tradeEntry: TradeEntry;
5}

Now in your template you can use the values from the store fragment and raise typed events.

1import type {TradeEntryForm, EventMap} from './home';
2
3const inputEmit = createInputEmitter<EventMap>();
4
5<zero-text-field
6  type="number"
7  :value=${x => x.tradeEntry.price}
8  @change="${inputEmit('trade-entry-price-changed')}"
9>

createEmitChangeAs is a utility from @genesislcap/foundation-events to allow components with string change inputs to emit their string values as typed event detail payloads. It will warn you if you try to use it with a component that doesn't have a string target.value type. It's a convenience method only and is the same as writing:

1<zero-text-field
2  type="number"
3  :value=${x => x.tradeEntry.price}
4  @change="${(x, c) => x.$emit('trade-entry-price-changed', targetValue(c))}"
5>

We will be adding a number of these for Selects and other primitives. You can of course call to a class method and have that emit the typed event to the store, but the idea with the helpers are to remove some boilerplate and misdirection.

1<zero-select @change=${((x, c) => x.instrumentIdChange(c.event.target as Select))}>

1instrumentIdChange(target: Select) {
2  this.$emit('trade-entry-instrumentID-changed', target.selectedOptions[0]?.value);
3}

If the component in question is perhaps a library asset or simply needs to remain unaware of the DI, you can map store properties to the custom element via its attributes.

1// ./some-parent/some-parent.template.ts
2
3<trade-entry-form price="${x => x.tradeEntry.price}" />

If the components are specific to your application and won't be shared, and you've split up your store into appropriate domain specific fragments, injecting the store fragment directly into where it's needed will greatly reduce mapping boilerplate. Remember components should only have access to the data they need. If the injected store fragment provides them more than that, consider splitting that store fragment up further, or reworking your store structure.

Accessing values from one store fragment to another

If you need to read values from another part of the store in your store you may be able to simple inject it, but you won't need to pass it to the super class for processing if that's done elsewhere. If you would rather not inject it, you can use this.root.fragmentX.fragmentY.value. You should provide root store type information when creating your store fragment that will be reading root, for example:

1import type {Store as StoreRoot} from '../store';
2...
3class DefaultPositions extends AbstractStore<Positions, PositionsEventDetailMap, InternalEventDetailMap, StoreRoot> implements Positions {
4  onPositionSelected = this.createListener<PositionEntity>('position-selected', (position) => {
5    const lastTradeId = this.root.trades.selectedTrade.id;
6    ...
7  });
8}

Testing with the injected dependency in place

Using a DI based store is very powerful as it allows us to swap out our store fragments when needed, ie. a unit test:

1const mock = new TradeEntryMock();
2const Suite = createComponentSuite<TradeEntryForm>('TradeEntryForm Test', () => tradeEntryForm(), null, [
3  Registration.instance(TradeEntry, mock),
4]);

The code in your component remains as is.

Committing value mutations

Stores are read only, so if you try to set a property directly TS will flag this. To commit a value to the store you must emit a known store event. In these event handlers, you call this.commit prepended with the value you want to mutate. For example:

1// some trades store fragment
2
3onTradeSelected = this.createListener<TradeEntity>('trade-selected', trade => this.commit.selectedTrade = trade);

The this.commit interface is typed the same as the store fragment itself for full code completion, and simply acts as a proxy to the underlying store. Currently, an alternative api also exists called commitValue if you prefer.

1onTradeSelected = this.createListener<TradeEntity>('trade-selected', trade => this.commitValue('selectedTrade', trade));

The store won't complain if you forget or just don't want to use the commit api, it just means value changes won't be tracked overtime.

1onTradeSelected = this.createListener<TradeEntity>('trade-selected', trade => this.selectedTrade = trade);

Side effects

When you need to reach out to another part of the system or generally do some async work, you should ensure the initial event handler is async. We recommend that you don't commit values in this handler, as it may become difficult to track mutations overtime if other events are occurring, but it's really up to you if you want to just await and commit. Ideally we want store interactions to be standardised, predictable and traceable.

1constructor(
2  @TradeEntry readonly tradeEntry: TradeEntry,
3  @TradesService readonly service: TradesService,
4) {
5  super(tradeEntry); // < only pass the super child sub store fragments
6
7  /**
8   * Listeners not on the public interface can be created anonymously if you prefer
9   */
10  this.createListener<TradeEntity[]>('trades-load-success', trades => this.commit.trades = trades);
11  this.createErrorListener('trades-load-error', () => this.commit.trades = undefined);
12}
13
14onTradesLoad = this.createAsyncListener<string>('trades-load', async (positionId) =>
15  this.invokeAsyncAPI(
16    async () => this.service.getTrades(positionId),
17    'trades-load-error',
18    'trades-load-success'
19  )
20);

Errors

When you use this.createErrorListener, stores will automatically keep track of any errors that may occur in a store.errors map that is keyed by the event type. This means your store can hold multiple errors at a time. To output all the messages at once you can bind to store.errors.messages, for example:

1<pre>${x => x.trades.errors.messages}</pre>

You can check for specific errors too:

1${when(x => x.trades.errors.has('trade-insert-error'), html<TradeInsertErrorFeedback>`...`)}

This granularity can be useful if say you wanted to raise error notifications and allow users to clear errors one-by-one.

1this.trades.errors.delete('trade-insert-error');
2
3// or clear them all
4this.trades.errors.clear();

Please note that store.errors is not a true Map so doesn't have all the native Map apis, however it should have most of what you need. You also operate on the errors map directly without raising events. This is like this for simplicity, and because errors are transient in nature.

Store bindings

You can easily bind to the properties and getters of a store inside the internal template engine, or outside of the template engine via the store's binding() api.

Template store bindings

For example, you may wish to monitor the value of this.store.ready via template bindings to conditional render a loading phase in your template.

1// ./main/main.template.ts
2
3${when(x => !x.store.ready, html<Loading>`Loading...`)}

...or monitor the value indirectly, to swap out the entire template.

1// ./main/main.ts
2
3selectTemplate() {
4  return this.store.ready ? MainTemplate : LoadingTemplate;
5}
6
7// ./main/main.template.ts
8
9<template ...>
10  ${x => x.selectTemplate()}
11</template>

Direct store bindings

To bind to the store outside the template engine, you use the store's binding() api. The store's binding() api is strongly typed, so you will be unable to bind to a non-existent property or getter. You also don't need to think about if the data point is a property or a getter, perhaps returning derived data, as the api works the same for both cases.

Some examples:

1// TS knows the returned type of value
2this.store.binding(x => x.ready, value => {...});
3this.store.binding(x => x.someNumericProp, value => {...});
4
5// TS needs some help to type the returned value, so you need to provide that (we hope to fix this).
6this.store.binding<boolean>('ready', value => {...});
7this.store.binding<number>('someNumericProp', value => {...});
8
9// You can even create your own derived binding that are not already defined as getters in the store
10this.store.binding(x => x.prop1 * x.prop2, value => {...});
11
12// These can even be volatile providing you pass true for isVolatileBinding
13this.store.binding(x => x.someToggle ? x.prop1 : x.prop2, value => {...}, true);

Here is an example of using the underlying bindingObserver as per docs.

1this.store.binding(x => x.prop1).subscribe({
2  handleChange(source) { // < note that the source is the bindingObserver itself, x => x.prop1, and not the value of the change
3    ...
4  }
5})

Updates are batch processed, so if a bunch of properties are updated in the store that any of the stores getters or derived bindings you've passed in via the binding() api use, they will by design tick only once to avoid any unnecessary updates and potential re-renders. See Reactivity for more information.

Direct store bindings as RxJS

Stores also offer a bindingAsRx() api which returns a Rxjs Observable to allow you to observe a value using Rxjs which may be useful depending on the needs of your application.

1const entireStore$ = this.store.bindingAsRx().subscribe(value => {...});
2
3const ready$ = this.store.bindingAsRx('ready').subscribe(value => {...});
4
5const prop1$ = this.store.bindingAsRx(x => x.prop1).subscribe(value => {...});

We may need to do some additional work here to finish this feature.

UI state in stores

You may want to keep your UI state in your stores alongside the application data. If so consider splitting these up into separate fragments, for example:

• TradeEntry: Trade entry field values (Data).
• TradeEntryUI: Trade entry presentation status, isOpen, isLoading etc. (UI State).

UI state can of course be kept in the component itself, however there may be reasons to keep it in the store. Consider if you needed to know if the trade entry was being presented on-screen in a different part of the application. You could try to listen for the 'trade-entry-ui-open' event, but until the event hits the target store and is committed, the true state isn't guaranteed. The store should be the single source of truth.

With that in mind, we could inject that UI state store fragment and bind to the value of interest, for example:

1// some other part of the UI
2
3this.tradeEntryUI.binding(x => x.isOpen, value => value ? this.stop() : this.start());

Keeping UI state in a store also might make it easier for you to save a snapshot of the UI state for rehydration, ie. what windows did the user have open etc. You may wish to add some middleware to the commit proxy (base store concept) for converting state transitions into browser history entries, which might allow you to deep link and press browser back button to say close the modal, with each back button moving backwards though the UI state. Be careful not to blur the lines between the data and the UI state in our store fragments.

For example a UI conditional could map to a UI sub fragment, whereas a datapoint could map to the parent fragment. The component would only need tradeEntry injected to have access to both, depending on how we structure fragments.

1${when(x => x.tradeEntry.ui.isOpen, html<TradeEntryForm>`
2    <zero-card>
3        <zero-text-field :value=${x => x.tradeEntry.quantity}>
4    </zero-card>
5`}

Installation

To enable this module in your application, follow the steps below.

1. Add @genesislcap/foundation-store as a dependency in your package.json file. Whenever you change the dependencies of your project, ensure you run the $ npm run bootstrap command again. You can find more information in the package.json basics page.

1{
2  ...
3  "dependencies": {
4    ...
5    "@genesislcap/foundation-store": "latest"
6    ...
7  },
8  ...
9}

API Docs

License

Note: this project provides front-end dependencies and uses licensed components listed in the next section; thus, licenses for those components are required during development. Contact Genesis Global for more details.

Licensed components

Genesis low-code platform