$ show zsviczian/excalibrain
ExcaliBrain is an Obsidian plugin (TypeScript, bundled via esbuild/rollup) that renders a user's vault as an interactive, structured graph/mind-map using Excalidraw as the drawing engine. In production it runs as a client-side extension inside the Obsidian host application, not as a standalone service or library. It depends on at least three external ecosystems: the Obsidian API for lifecycle, views, commands, and settings; the Dataview plugin for vault-wide metadata indexing and field queries; and the Excalidraw plugin's ExcalidrawAutomate API for rendering. The plugin classifies each page's neighbors as parents, children, friends, or siblings, driven by user-configured Dataview hierarchy fields such as hasParent/hasChild/hasFriend, then augments that graph with forward/backlinks, tags, folders, unresolved 'ghost' nodes, and external URLs. Nodes and edges are laid out and rendered into an Excalidraw scene with gate-based connections, a control panel for filtering, search, pinning, and a navigation history panel. Architecturally it is a modular monolith: src/excalibrain-main.ts is the plugin bootstrap wiring commands, settings, and event listeners; src/Scene.ts owns the rendering lifecycle, layout computation, and transient scene updates; src/graph/* contains the page model (Page.ts/Pages.ts), link logic (Link.ts/Links.ts), Excalidraw element generation (Node.ts), and grid layout (Layout.ts); src/Components/* provides tools, toggles, history, and filter UI; src/utils/* contains compatibility shims and helpers. Data flows unidirectionally from Obsidian's MetadataCache and Dataview's index into an in-memory Pages graph, which is then converted into Excalidraw elements; user editing happens through the Excalidraw scene or through ontology-field suggestions in the editor. The codebase has genuine craftsmanship: explicit compatibility layers (ExcalidrawAutomateCompatibility.ts, SettingsCompatibility.ts, ExternalPluginTypes.ts) structurally type external plugin APIs to reduce version coupling; a generic keyboard-navigable suggestion popup; a self-contained vendored multiselect component; 28-locale i18n; and a regression test suite for settings API parity. It is not flawless: settings rendering is duplicated across a legacy display() path and a newer searchable getSettingDefinitions() path, several locale files are empty stubs, PowerFilter is a no-op stub, ad-hoc repository-management scripts sit in the source tree, and tests were only partially verified. This is an application repo, not data_research: despite heavy vault indexing, the purpose is interactive visualization tooling, not analysis or reproducible research.
The LLM identified 5 files worth highlighting for reuse:
Self-contained multi-select dropdown component with option models, selection callbacks, and plural-label handling. It is vendored in-tree, has no dependencies beyond its own models directory, and was adapted for Obsidian popout windows. Another engineer could extract it into a vanilla-DOM or framework-agnostic project with minimal modification.
Generic text-input suggestion popup base class with keyboard navigation, fuzzy filtering, and result highlighting (originally inspired by Liam Cain's Periodic Notes suggester). PageSuggester and OntologySuggester extend it, proving it is a stable, reusable base pattern for any Obsidian plugin needing command-palette-style suggestions.
Local structural type definitions and runtime guards for the Excalidraw plugin's ExcalidrawAutomate API, plus helpers like getEA() and waitForExcalidrawViewReady(). This decouples the plugin from a rapidly-changing external API without bundling it. The pattern, defining minimal local interfaces with runtime validation, is broadly reusable for any ecosystem requiring resilient cross-plugin integration.
Render-only compatibility shim for Obsidian's searchable declarative settings API. It defines SearchableSettingDefinition/SearchableSettingGroup local types and falls back to legacy setting rendering when the newer API is unavailable. A clean, extractable example of forward-compatible UI abstraction during a platform API migration.
Resolves daily/weekly/monthly/quarterly/yearly note settings across three different Obsidian plugins (Periodic Notes, Calendar, and the built-in daily-notes plugin), normalizing them into one date-helper interface. This solves a recurring problem for any Obsidian tool dealing with date-based note naming conventions, and is usable without the named plugins being installed.