#398: Table View Interactions

[ethanluc7]

Related to issue: #398

Summary

Enhances the table view to display visual key indicators (PK/FK) in the Attribute column and enable navigation from FK relationships to the ERD diagram modal with highlighted relationships.

Description of Changes

• Replaced the layout with two separate algorithms instead of just one:
  • Sugiyama — used for the full ERD view, respects FK relationships to produce a DAG-ordered layout
  • Grid — used for the focused FK chain, compactly arranges only the schemas in the selected relationship chain
• Added getLayoutedDiagram and getLayoutedElements to drive both layouts
• Introduced DiagramViewContext to manage modal open state and an optional focusField (schema + field name).
• RelationshipDiagramContent now accepts a focusField prop: when set, it traces the FK chain for that field, filters to only the relevant schemas/edges, and renders the compact grid layout with the relationship pre-highlighted. When unset, it renders the full ERD.
• Added two new utility functions (isFieldForeignKey, isFieldUniqueKey) to detect FK and unique key fields.

Readiness Checklist

• Self Review
  • I have performed a self review of code
  • I have run the application locally and manually tested the feature
  • I have checked all updates to correct typos and misspellings
• Formatting
  • Code follows the project style guide
  • Automated code formatters (ie. Prettier) have been run
• Local Testing
  • Successfully built all packages locally
  • Successfully ran all test suites, all unit and integration tests pass
• Updated Tests
  • Unit and integration tests have been added that describe the bug that was fixed or the features that were added
• Documentation
  • All new environment variables added to .env.schema file and documented in the README
  • All changes to server HTTP endpoints have open-api documentation
  • All new functions exported from their module have TSDoc comment documentation

[JamesTLopez]

Using the non-null assertion is usually an indicator that something can be improved. Try to avoid using this going forward. Check if schema exists before making the openFocusedDiagram call.

[JamesTLopez]

Same with this one

[JamesTLopez]

Having the !! is redundant here.

[JamesTLopez]

This is technically not wrong, but this can get pretty unreadable as more conditions are added.
I suggest using a more explicit approach:

  if (!schema || !currentSchemaField) return;

  openFocusedDiagram({
    schemaName: schema.name,
    fieldName: currentSchemaField.name,
  });

or you can disable the button entirely.

<button
	css={diagramLinkStyle(theme)}
      disabled={schema && currentSchemaField}
	  onClick={() => openFocusedDiagram({ schemaName: schema.name, fieldName: currentSchemaField.name })
}
/>

[JamesTLopez]

This component can be simplified.

fieldKey,fkIndexes,getLayoutedDiagram and RelationshipDiagramFlow are declared multiple times. Lets try not to duplicate declarations here. We can start with declaring our variables at the top:

	const fieldKey = focusField ? `${focusField.schemaName}::${focusField.fieldName}` : null;
	const fkIndices = fieldKey ? relationshipMap.fieldKeyToFkIndices.get(fieldKey) : null;
	let currentNodes = dictionary.schemas;
	let currentEdges = allEdges;

We can move the if (focusField) { ... } above the useEffect and remove the repeat RelationshipDiagramFlow and getLayoutedDiagram. This conditional will just focus on redefining currentNodes and currentEdges with your filter logic.

Then we can calculate const { nodes, edges } = getLayoutedDiagram(currentNodes, currentEdges);

Adjust useEffect accordingly.

This component should just return the following at the end return <RelationshipDiagramFlow nodes={nodes} edges={edges} isFocused={!!focusField} />; at the end