Reasons for an own HierarchyWidget

[VincentKneip]

Although the imported EntityTreeWidget from the ols4 repository currently used as HierarchyWidget for our project works properly, there are some downsides to using it, which are listed below:

• The widget does not follow our design scheme
• The widget uses a global Redux store, preventing multiple HierarchyWidgets of different entities on one page
• Badges are always shown and cannot be disabled via a property showBadges like on our other widgets
• The widget still contains some bugs, which have to be identified further. Examples already identified are:
  • (View here) When querying still missing children in the hierarchy with getNodeChildren(), the entity type provided (entityTypePlural) is always the type of the selected entity. This leads to the issue that individuals are never rendered inside classes' hierarchies because entityTypePlural == classes, but the correct query would be .../children or .../instances (seem to be identical for classes) instead of .../hierarchicalChildren. Instead, both .../hierarchicalChildren and (.../children or .../instances) have to be queried for entityTypePlural == classes.
  • No icon to expand a node and show its children is rendered for individuals (which is correct as they don't have children), but the area is still clickable and works like there would be an icon, executing the wrongly placed query for instances mentioned in the former bullet. The area should not execute the query onClick (see responsible code here), therefore toggleNode() should not dispatch if node.expandable == false, and the query code segment in getNodeChildren() for entityTypePlural == individuals should be removed

If these aspects are important to us, I would suggest developing our own HierarchyWidget fixing these issues.