Smart Connections View and Command Flow

Use this skill when wiring Smart Connections views, commands, ribbon actions, settings-tab entry points, or workspace-leaf persistence so registration and teardown stay aligned with the plugin lifecycle.

Critical

• Put registration in src/main.js inside SmartConnectionsPlugin extends SmartPlugin, and keep cleanup on the plugin lifecycle. Do not register commands, views, or workspace listeners from render callbacks.
• Register each custom view once with this.registerView(...); open it by its view type, not by creating ad hoc instances in commands.
• Use src/utils/view_leaf_location.js for any command that should reopen in the same pane or restore the previous leaf. Do not hand-roll leaf persistence.
• Keep settings UI in src/views/settings_tab.js and reuse render_settings_config from obsidian-smart-env instead of building a separate settings renderer.

Instructions

1. Find the existing flow before changing anything.

   • Inspect src/main.js, src/views/connections_item_view.js, src/views/lookup_item_view.js, src/views/release_notes_view.js, and src/views/settings_tab.js.
   • Match the repo's naming pattern: existing files use src/views/connections_item_view.js and src/views/lookup_item_view.js, view classes use PascalCase, and view type strings are stable constants used by registerView(...). Verify the closest existing view/command flow is identified before proceeding to the next step. This step uses the output from no prior step.

2. Build the new view shell in src/views/connections_item_view.js-style files (for example, src/views/release_notes_view.js for command/panel pages).

   • Use Obsidian API imports from obsidian the same way the existing view files do.
   • Export a view class with the same lifecycle shape as the current views:
     • getViewType()