Difference Between Structural Graph View and Domain Knowledge View in the Egonex Dashboard

The structural graph view maps code architecture using ELK layered layouts to navigate files, modules, and dependencies, while the domain knowledge view employs force-directed layouts to visualize semantic relationships between extracted entities like articles, claims, and topics.

The Egonex dashboard in the Egonex-AI/Understand-Anything repository provides two distinct visualization modes that share a single React Flow canvas. Understanding the difference between structural graph view and domain knowledge view helps developers choose the right analytical lens for exploring large codebases, whether tracing architectural dependencies or interrogating the domain meaning extracted by static analysis.

Structural Graph View: Code Architecture Visualization

The structural graph view renders the physical and logical organization of your codebase. It answers the question: How is the code structured?

Layout Algorithm and Performance Optimization

The view implements a two-stage ELK (Eclipse Layout Kernel) layered layout strategy defined in src/utils/elk-layout.ts. The applyElkLayout function first computes a stage‑1 layout for container nodes, then executes a stage‑2 lazy layout when users expand containers. This approach avoids recomputing the entire graph on every interaction.

Performance optimizations target large codebases through:

• Container aggregation that groups files into collapsible folders
• Memoized layer statistics to prevent redundant calculations
• Asynchronous ELK calls that keep the UI responsive during layout computation

Node Types and Graph Construction

The main component src/components/GraphView.tsx consumes the useOverviewGraph hook (lines 31‑70) for high‑level layer clusters and useLayerDetailGraph (lines 96‑200 and 672‑885) for drilled‑in views. The structural view recognizes four primary node types:

• layer‑cluster – Rectangular clusters representing architectural layers
• container – Collapsible folder‑like groups of related files
• custom – Individual code artifacts (files, classes, functions)
• portal – Gateway nodes linking to other layers

Interactivity centers on architectural navigation: users can drillIntoLayer, expand or collapse containers, and highlight search results or diff changes without triggering full relayouts.

Domain Knowledge View: Semantic Relationship Mapping

The domain knowledge view visualizes the meaning extracted from code rather than its file structure. It answers the question: What does this code represent?

Force-Directed Layout and Stability

Implemented in src/components/KnowledgeGraphView.tsx, this view uses applyForceLayout from src/utils/layout.ts (lines 51‑88) to compute a stable force‑based placement. Unlike the structural view, the layout runs only once per graph or filter change, not on selection or search operations, ensuring stable visual exploration of semantic webs.

Node dimensions derive from connectivity metrics via getNodeDimensions, sizing nodes proportionally to their edge counts to emphasize highly connected domain concepts.

Knowledge Nodes and Edge Taxonomy

The domain view filters the shared KnowledgeGraph data structure to display only knowledge node types: article, entity, topic, claim, and source. These render as custom nodes with color coding based on semantic type.

Edge styling conveys logical relationships through the EDGE_STYLES map (lines 24‑34), visually distinguishing:

• cites – Typically rendered as dashed lines indicating source attribution
• contradicts – Styling that emphasizes opposing claims
• related – Standard associations between entities

Key Technical Differences

While both views consume the same KnowledgeGraph type from @understand-anything/core/types, they diverge in implementation strategy:

• Layout Philosophy: The structural view uses hierarchical ELK layouts optimized for top‑down code organization, while the knowledge view uses force‑directed physics simulations that naturally cluster semantically related entities without imposed hierarchy.

• Data Filtering: The structural view filters for code artifacts (type: "file" | "class" | "function"), whereas the knowledge view filters for semantic nodes (article, entity, topic, claim, source).

• Performance Strategy: Structural optimization focuses on container aggregation and async layout stages to handle thousands of code files. Knowledge view optimization emphasizes layout stability, freezing positions after initial calculation to prevent jarring movements during analysis.

• Interaction Model: Structural interactivity supports architectural drilling (drillIntoLayer) and container expansion, while knowledge interactivity focuses on selecting entities to trace claim‑source relationships and contradictions.

How View Switching Works in the Codebase

The dashboard toggles between visualizations using a navigationLevel state stored in the central Zustand store (useDashboardStore). The root src/App.tsx mounts the appropriate component based on this flag:

// src/App.tsx (excerpt)
const navigationLevel = useDashboardStore(s => s.navigationLevel);

return (
  <ReactFlowProvider>
    {navigationLevel === "graph" 
      ? <GraphView /> 
      : <KnowledgeGraphView />}
  </ReactFlowProvider>
);

To implement a toggle button in your own extensions:

import { useDashboardStore } from '../store';

function ViewToggle() {
  const navigationLevel = useDashboardStore(s => s.navigationLevel);
  const setNavigationLevel = useDashboardStore(s => s.setNavigationLevel);

  return (
    <button
      onClick={() =>
        setNavigationLevel(navigationLevel === 'graph' ? 'knowledge' : 'graph')
      }
    >
      {navigationLevel === 'graph' ? 'Show Knowledge' : 'Show Structure'}
    </button>
  );
}

The setNavigationLevel action updates the store flag that App.tsx reads to remount the canvas with the appropriate visualization engine.

Summary

• Structural Graph View (GraphView.tsx) uses ELK layered layouts to visualize code architecture, supporting drill‑down navigation and container aggregation for large codebases.
• Domain Knowledge View (KnowledgeGraphView.tsx) uses force‑directed layouts to map semantic relationships between extracted entities, optimizing for stable visualization of knowledge webs.
• Both views share the KnowledgeGraph data model but filter for different node type subsets and apply distinct layout algorithms.
• View switching occurs at the application root via the navigationLevel state, which conditionally renders the appropriate React Flow canvas.

Frequently Asked Questions

Can I display both views simultaneously in the Egonex dashboard?

No, the current implementation uses mutual exclusion via the navigationLevel state in the dashboard store. The App.tsx component renders either GraphView or KnowledgeGraphView based on this single flag, ensuring that layout calculations and interaction handlers remain specific to the active visualization mode.

Why does the structural view use ELK while the knowledge view uses force-directed layout?

The structural view employs ELK because code architectures naturally exhibit hierarchical layering (files within folders within modules) that layered graph algorithms optimize for clarity and edge routing. The knowledge view uses force-directed layouts because semantic relationships form non‑hierarchical networks where entity proximity and clustering convey relatedness more effectively than rigid layering.

What underlying data structure supports both visualization modes?

Both views consume the KnowledgeGraph type imported from @understand-anything/core/types. The difference lies in filtering: the structural view processes nodes with types like file, class, and function, while the knowledge view filters for article, entity, topic, claim, and source nodes. This unified model ensures consistency while allowing domain‑specific rendering.

How does the structural view handle performance in enterprise-scale codebases?

The structural view implements a two‑stage ELK layout strategy (applyElkLayout in src/utils/elk-layout.ts) that first calculates container positions, then lazily computes detailed layouts only for expanded containers. Additional optimizations include memoized layer statistics in useOverviewGraph, asynchronous ELK processing to prevent UI blocking, and container aggregation that collapses thousands of files into manageable clusters.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}