[REFACTOR] Split the code of BpmnElementsRegistry and the code of its collaborators

[tbouffard]

Over time, BpmnElementsRegistry has become a veritable monster. It was originally intended to be responsible for the retrieval of model elements and their associated visual information.
But then we added methods to handle CSS classes, overlays and cell styling. It now has too many responsibilities, and we should consider splitting up its public API.

To prepare for this split, we first have to split the internal code, especially as some parts are very tightly coupled.
This will also prepare the code for tree-shaking and will introduce better separation of concerns.
The overlays part has already been managed in #2800

There are 2 parts in the code and here is how we can proceed (this has been followed in #2800):

• the code in BpmnElementsRegistry can move to other "registry" files. It is generally glue code
• the code in GraphCellUpdater, which generally does the real processing, that needs to be split into 2 different updater (for CSS classes and style)

In addition, extract dedicated interfaces for all new registries. This will:

• ensure internal registry used the same method signatures as the public API
• let plugins develop in addons have the same signature and ensure it includes all methods by following this interfaces
• let share the JSDoc. By putting the JSDoc of the methods in the interface only, all implementers will provide the same information to users

Possible drawback in HTML API: the split into several interfaces may require more navigation for readers. This is already the case for the split of existing type like ShapeUpdate. There is nothing we can do to improve that.

Challenges

Notes:

• The following applies to the code of version 0.38.1
• Prior implementing anything to improve the situation described below, please implement [INFRA] Rework the integration tests about CSS and style API interactions #2743 first

The main issue for this change is the coupling which has been introduced in #2732 and that had already been noticed at that time:

• feat(style): add a new API to reset the modified style of given elements via APIs #2732 (comment)
• feat(style): add a new API to reset the modified style of given elements via APIs #2732 (comment)

StyleManager (mxGraph related) and CssRegistry (domain specific) know each other introducing a cyclic dependency. The domain code can know the mxGraph code but not the opposite.
This was introduced to ensure that the style update correctly works with the CSS classes management.

The two elements include caches that need to be cleared while loading a new model. This part is probably coupled and should be improved.

Proposed renaming and file organization

registry/css-registry.ts

• rename the existing CssRegistry class into CssClassesCache
• create a new CssClassesRegistry as entry point of CSS classes management

mxgraph/

• style/StyleManager.ts: rename into 'style/style-updater.ts' and store a new StyleUpdater class with the style part of the existing GraphCellUpdater. Find a better name for StyleManager that should not been exported anymore as it should only be used by StyleUpdater
• style/css-classes-updater.ts: store a new CssClassesUpdater class with the style part of the existing GraphCellUpdater
• remove GraphCellUpdater

Note: in the existing code of GraphCellUpdater, this.graph.model.setStyle(...) should use the model constant directly instead of passing by the graph.

Proposal for new interfaces

in registry/types.ts, add the following interface

• CssClassesRegistry
• ElementsRegistry: for the methods of BpmnElementsRegistry that only managed the BPMN elements
• OverlaysRegistry
• StyleRegistry

Tasks

Preview Give feedback

1. Introduce new internal registries refactor: split internal registries #2818
2. Extract new public interfaces refactor: introduce registry interfaces #2832
3. Remove the coupling refactor: split internal registries #2818 and refactor: remove some coupling between the "CSS" and "Style" API #2825