openmct/platform/commonUI
Andrew Henry 92737b43af
[API] Changes to mutation API (#3483)
Changes how object mutation works behind the scenes in order to keep objects in sync automatically when their model changes.

* The way that objects are mutated and observed has not changed, openmct.objects.mutate and openmct.objects.observe should still be used in the same way that they were before.

* Behind the scenes, domain objects that are mutable are wrapped in a new MutableDomainObject that exposes mutator and observer functions that allow objects to be mutated in such a way that all instances can be kept in sync.

* It is now possible to retrieve MutableDomainObjects from the API, instead of regular domain objects. These are automatically updated when mutation occurs on any instance of the object, replacing the need for "*" listeners. Note that the view API now provides objects in this form by default. Therefore, you do not need to do anything differently in views, the domain objects will just magically keep themselves up to date.

* If for some reason you need to retrieve an object manually via openmct.objects.get (you should ask why you need to do this) and you want it to magically keep itself in sync, there is a new API function named openmct.objects.getMutable(identifier). Note that if you do this you will be responsible for the object's lifecycle. It relies on listeners which must be destroyed when the object is no longer needed, otherwise memory leaks will occur. You can destroy a MutableDomainObject and its (internal) listeners by calling openmct.objects.destroyMutable(mutableDomainObject). Any listeners created by calls to openmct.objects.observe need to be cleaned up separately.

* If the composition of a MutableDomainObject is retrieved using the Composition API, all children will be returned as MutableDomainObjects automatically. Their lifecycle will be managed automatically, and is tied to the lifecycle of the parent.
Any MutableDomainObject provided by the Open MCT framework itself (eg. provided to view providers by the View API, or from the composition API) will have its lifecycle managed by Open MCT, you don't need to worry destroying it.
2021-01-17 14:15:09 -08:00
..
about Bump copyright year to 2020 (#3169) 2020-09-14 11:17:31 -07:00
browse Three Dot Menu Prototype (#3325) 2020-11-19 09:53:06 -08:00
dialog Bump copyright year to 2020 (#3169) 2020-09-14 11:17:31 -07:00
edit [API] Changes to mutation API (#3483) 2021-01-17 14:15:09 -08:00
formats Bump copyright year to 2020 (#3169) 2020-09-14 11:17:31 -07:00
general Three Dot Menu Prototype (#3325) 2020-11-19 09:53:06 -08:00
inspect Bump copyright year to 2020 (#3169) 2020-09-14 11:17:31 -07:00
mobile Bump copyright year to 2020 (#3169) 2020-09-14 11:17:31 -07:00
notification Bump copyright year to 2020 (#3169) 2020-09-14 11:17:31 -07:00
regions Bump copyright year to 2020 (#3169) 2020-09-14 11:17:31 -07:00
README.md [Licenses] Update copyright year to 2017 2017-04-05 14:52:46 -07:00

This directory contains bundles containing common user interface elements of Open MCT; that is, the user interface for the application as a whole (as opposed to for specific features) is implemented here.

Extensions

This bundles adds a stylesheets extension category used to inject CSS from bundles. These extensions are declaration-only (no scripted implementation is needed or used); a single property, stylesheetUrl, should be provided, with a path to the relevant CSS file (including extension) relative to the resources directory for that bundle.

Links to these CSS files are appended to the head when the application is started. These are added in standard priority order (see documentation for the framework layer); the order of inclusion of style sheets can change the way they are handled/understood by the browser, so priority can be used to provide control over this order.