Custom tree components are tightly coupled to their data sources

[pjmonks]

Background

There are a number of custom tree components (or wrappers around the tree components) which the UI uses, such as:

• mdm-folder-tree - the main catalogue item tree view, containing a lot of additional functionality - drag/drop, multi-selection etc
• mdm-model-tree-selector - wrapper component to use mdm-folder-tree in form field selectors
• mdm-models - another big wrapper around mdm-folder-tree to display the core catalogue item tree for browsing.

Issues

The issues found with these are that the data sources are tightly coupled to these components, for example the mdm-folder-tree is aware of how to expand each catalogue item further by directly called the MdmResourcesService. While this works, there are disadvantages too:

1. Adding additional functionality (e.g. support for further catalogue item domain types) is more complicated because more components need to be updated in sync, including delving into low-level features of the tree components
2. The tree views cannot actually be easily reused. For example, they may have features enabled such as drag/drop, multi-selection via checkboxes etc, but only for the data sources they are aware of. Similar functionality would have to be copied for a different type of data source, increasing code complexity and/or redunancy.
3. The data sources cannot easily be altered in lower level components without affecting the parent components, and therefore key parts of the application. One scenario found was updating the Import Model page to allow selection of Versioned Folders; a custom filter function had to be passed down to the lower level components which perform the data fetch, when ideally the collated data should have been passed down into the tree to render, making the tree a "dumb" component.

Discussions

As part of the "Clean Up" project, we should discuss whether the tree components can be tidied up to resolve some/all of these issues:

• Can the existing components be refactored to get around these problems?
• Do they need to be replaced with simpler components? (Though has to be weighed up against functionality to retain)
• Can the components be decoupled in any way to make them more isolated whilst still performing their jobs?

[pjmonks]

The PR #649 has introduced a new tree view component that is more simplified, the key part is that the code to fetch more child nodes on expand is separated into a custom DataSource which makes the code much simpler to follow (and removes a lot of issues I've highlighted in previous comments). Once that PR is merged, it might be worthwhile revisiting this issue to see if it helps.