Skip to end of banner
Go to start of banner

Registry

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

As per the vocabulary, the Registry is designed as a storage place for apps outside of ui-dashboard to register resources. These will then become available to dashboard for the purposes of dynamic interactions between different frontend apps.

Here "Resource" is used to mean an object managed by a particular frontend app. For example ui-agreements manages "agreement", "agreementLine", "platform" resources, amongst others.

One particular example of this can be seen in the ability for SimpleSearch widget form to use an existing "lookup component" for a particular resource. In the figure below, an Agreement widget may allow the user to filter by "Linked license". This is a resource managed by ui-licenses, so here ui-licenses is registering a resource called a "license", alongside information for how to render a lookup component for that resource.

The dashboard then consumes that resource entry and renders its lookup component dynamically.

An agreement widget filter making use of a license lookup component

Implementation Code

The registering of resources with the registry is done through stripes eventHandler system.

static eventHandler(event, _s, data) {
  if (event === 'ui-dashboard-registry-load') {
    // Data should contain Registry singleton:
    setUpRegistry(data);
    return null;
  }
  return null;
}

Here the index.js file in ui-licenses consumes the event 'ui-dashboard-registry-load', and then triggers a function which sets up the license resource within the registry:

const setUpRegistry = (registry) => {
  // License Resource
  const licenseReg = registry.registerResource('license');
  licenseReg.addViewAll('/licenses');
  licenseReg.addViewTemplate(license => `/licenses/${license.id}`);

  // Lookup plugin
  licenseReg.addLookupComponent(LicenseLookup);
};

In this example LicenseLookup is the component which is rendered in the agreement widget configuration form above.


Since the registry is a singleton, all registered entries will be available to ui-dashboard when it needs to consume them, and Registry as an object contains several methods to allow modules to interact with it.


Information on how stripes eventing works can be found here: https://github.com/folio-org/stripes/blob/master/doc/dev-guide.md#handlers-and-events

Not mentioned in that document are the necessary additions to the package.json of an implementing module. The string "handler" will need to be added to the "actsAs" array, and "handlerName" will need to reflect the name of the event method in the module's index.js, most likely "eventHandler".

"actsAs": [
  "app",
  "handler",
  "settings"
],
"handlerName": "eventHandler",

Registry API

The implementation details above cover some of the registry's API, namely how to register a resource and provide a lookupComponent. This section will cover more in depth how an implementing module can interact with the registry.

"The registry" is currently comprised of two objects and one exception:

  • Registry
  • RegistryResource
  • RegistryException

Registry, as mentioned above is a singleton, and so all additions/manipulations made by any module are reflected for all of its consumers. It does not have any publically available fields, and so all interactions must take place via its methods:

getRegistry()

Returns a Javascript Map with keys of the resources available and values of a RegistryResource.

getRegistryCount()

Returns the number of entries in the Map above.

registerResource(resourceName)

Assigns a new RegistryResource to the Map above with the key "resourceName" and returns that RegistryResource.

getResource(resourceName)

Returns the RegistryResource with that key from the Map (or unassigned if the resource does not exist).

setRenderFunction(resourceName, fieldName, func)

This is a passthrough of the same method on a particular RegistryResource.

getRenderFunction(resourceName, fieldName)

This is a passthrough of the same method on a particular RegistryResource.


A RegistryResource is a class containing information about a particular resource of the registry. It has fields that are technically publically available, but they should only be accessed through the requisite getters and setters.

Once https://github.com/tc39/proposal-private-methods#private-methods-and-fields or equivalent become available and supported, these fields should be made private. This class contains the following methods with which to interact with it:
 

The templating parts below are not yet implemented and are likely to change as the project iterates forwards.


addViewAll(getAllPath)

This function sets a string field, which should reflect a basic URL path for a "view all" page for the resource. In the case of agreements it would be "/erm/agreements/"

addViewAllTemplate(template)

Sets a function field, which should take some parameters, such as filterList, or a backend search query, and returns a URL which reflects that search in the frontend.

addViewTemplate(template)

Sets a function field which will take an object representing the resource in question and wi

getViewAll()

saffsa

getViewAllTemplate()

adsgsdg

getViewTemplate()

dagag

addLookupComponent(component)

adgadgdsg

getLookupComponent()

asdgadgds

setRenderFunction(name, func)

dsgsdg

getRenderFunction(name)

sfahf

  • No labels