Refactor to use display entities

[kmcginnes]

Description

Nearly all views that show details of a node, edge, or type would do the exact same transformations at the view level. This change abstracts all of that logic to a single place, ensuring the logic is consistent and making it easier to modify the behavior across the app.

The next step of this refactoring will be to abstract the neighbor count logic to the same DisplayVertex. And after that we will have a good foundation for loading a node/edge from a simple ID, which is foundational to URL sharing.

Validation

• Smoke test all areas of the app

Related Issues

• Resolves [Spike] Investigate hurdles to entity detail query #677
• Affects [Bug] Datetime property values are not shown in details view #122

Check List

• I confirm that my contribution is made under the terms of the Apache 2.0
  license.
• I have run pnpm checks to ensure code compiles and meets standards.
• I have run pnpm test to check if all tests are passing.
• I have covered new added functionality with unit tests if necessary.
• I have added an entry in the Changelog.md.

[codecov]

Codecov Report

Attention: Patch coverage is 50.66259% with 484 lines in your changes missing coverage. Please review.

Project coverage is 18.12%. Comparing base (9d3a2b7) to head (66916be).
Report is 46 commits behind head on main.

Files with missing lines	Patch %	Lines
...aph-explorer/src/core/StateProvider/displayEdge.ts	12.38%	99 Missing ⚠️
...-explorer/src/modules/EntityDetails/EdgeDetail.tsx	0.00%	74 Missing ⚠️
...h-explorer/src/core/StateProvider/displayVertex.ts	68.42%	29 Missing and 1 partial ⚠️
...lorer/src/workspaces/DataExplorer/DataExplorer.tsx	0.00%	30 Missing ⚠️
...-explorer/src/modules/EntityDetails/NodeDetail.tsx	0.00%	22 Missing and 1 partial ⚠️
...odules/EntitiesTabular/components/NodesTabular.tsx	0.00%	19 Missing ⚠️
...les/GraphViewer/internalComponents/ContextMenu.tsx	0.00%	18 Missing ⚠️
...orer/src/modules/EntityDetails/EntityAttribute.tsx	0.00%	16 Missing and 1 partial ⚠️
...lorer/src/modules/NodeExpand/NodeExpandFilters.tsx	0.00%	15 Missing ⚠️
...er/src/modules/ConnectionDetail/ConnectionData.tsx	0.00%	13 Missing ⚠️
... and 21 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #698      +/-   ##
==========================================
+ Coverage   14.88%   18.12%   +3.24%     
==========================================
  Files         566      540      -26     
  Lines       25121    23249    -1872     
  Branches     1170     1166       -4     
==========================================
+ Hits         3739     4214     +475     
+ Misses      21050    18750    -2300     
+ Partials      332      285      -47     

Flag	Coverage Δ
unittests	18.12% <50.66%> (+3.24%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kmcginnes]

I've pushed a series of changes:

• Changed the defaultVertexTypeConfig and defaultEdgeTypeConfig to not have a display label in order to allow the display logic to fill in the display label as needed
• Added test for sparql case of displayId and displayLabel
• Updated some of the imports to be the aliased import
• Made useSelectedDisplay* hooks more efficient
• Updated styles of node and edge properties in the details sidebar
• Added default properties for edges:
  • Edge type
  • Source vertex id & type
  • Target vertex id & type
• Move edge display name logic to the DisplayEdge type rather than useGraphStyles()

[kmcginnes]

Fixed tests and added some more

[andreachild]

Curious why this check is preferred to the original check for displayId? Is there still value in setting the displayId on the EdgeDetail for SPARQL if it's not shown?

[kmcginnes]

I honestly don't remember why I made that change. If I had to guess it was to make sure no properties were optional on the model. But that's not a good enough reason.

I reverted the change.

[kmcginnes]

Actually, I take it all back. After reverting the change and seeing some errors I now remember why. It is about optionality, but specifically around the logic to get the "display name" value. Since displayId is an option on non-sparql databases if it was optional it would require display name to be optional, which I do not want.

[andreachild]

LGTM 👍