microsoft / essex-toolkit Goto Github PK

In Hierarchy Browser, if an edge list is present the connected neighbors show automatically and can't be closed. This panel should have a button to expand/collapse as desires.

The useDebounceCallback function, and the debounce function in the toolkit replicate functionality available in more popular and tested frameworks (lodash, ahooks). These hooks, and hooks that are similar in that their functionality is well implemented elsewhere, should be removed.

Currently the sorting for neighbor communities is based on number of connections but allowing users to select either number of connections or size (members) as table order.

The hierarchy browser displays a "flat" list of tables that represent each level. Many tree representations (such as folder browsers) include indentation lines, expand/collapse buttons, and so on to allow browsability and hints on the tree structure. We should explore optional visual treatments that make the hierarchy more clear (and align with commonly understood tree representations).

Right now the communityId field is used to display the community headers (see here). However, this ID is often system-generated, and applications might have other labels for the community that are more meaningful to users. An optional label field, falling back to communityId if missing, would allow customization.

We have two fixed buttons on each table header: toggle filter and download data CSV. However, different applications may want these or other commands to operate on each table. Using the command design pattern (with buttons on a command bar) would allow us to provide custom header actions.

Allow for prop to highlight row in table

The hierarchy is represented bottom-up by displaying the leaf table at the top of the browser list, and walking up the tree as you scroll down the tables (with the tree root being the bottom table). This is the default because starting from a leaf provides a predictable path to the root from a known starting point, whereas starting at the root could require navigation decisions at each level to find a leaf. For our common use cases, we are starting from a known row item that we can trace to a leaf, and showing the leaf table at the top is the finest granularity (smallest community) they are a member of - typically the preferred list to explore first.

That said, top-down is a much more common way of navigating trees so there may be times when it is desirable to represent the tree in a more traditional manner.

Right now the data tables display all of the known properties as columns. This could be configurable via a prop so that we can create custom views or allow users to edit their display preference.

Use color selection based on theme variant as either nominal+ or nominal muted, and replace multiple colors in background image gradient with single color for clarity. Look into replacing CSS with SVG rect or div implementation.