Ext JS browse UI tree view

What problem are we solving?

PE-49 reintroduces the concept of asset path hierarchy via a tree browsing service (and accompanying HTML views). However, our Ext JS browse UI still has a few remaining problems:

• It isn’t taking advantage of that new service.
• It has separate features for component browsing and asset browsing. This is overly complicated.
• There is significant pogo sticking in the current drilldown-based design. This makes browsing a repo more difficult than it should be.

How will we measure success?

There are currently 24 votes across the two sister issues (NEXUS-12518 and NEXUS-12531). We will validate the changes with everyone who voted. If successful, 90%+ of the people we talk to will indicate that our solution addresses their needs.

What do we need to do?

• NXRM users can open up a tree-like view (e.g. as a peer nav option to Browse)
• Identify if there are scalability issues (e.g. when a single node has 50k children, as could happen in a Git LFS or docker repository).
  • Scalability issues might be dealt with in other stories, and potentially quite simply - perhaps by truncation. (Who's going to tree through 50k nodes?)
• If you expand a node with multiple hops (containing only a single directory each), concatenate the names into a single node (so org > apache > activemq would become org > apache/activemq, assuming org has many children).
• We show assets in the tree as leaf nodes
  • If you select an asset, the asset detail view opens
  • If you select a component, the component detail view opens
    • Because we’re showing assets in the tree, we should remove the asset list from the component detail view
• The asset and component detail views use side-panels, not the current drilldown pattern