Thinking about plugin development, we might need to support APIs for different “types” of interactions with Obsidian. For example, the following could be thought of as different types of plugins, which are scoped differently, and require different models for interacting with Obsidian.
- Plugins that want to hook into, or extend the parser
- Plugins that want to do fancy things in the editor, like triggering and populating the suggestion panel in editor mode based on some predefined condition
- Plugins that want to participate in the file “indexing”/watching process. I’m using the term indexing generically here, but the thing that generates the Obsidian cache file could be thought of as an indexer for example. We probably don’t want dozens of plugins each creating their own file change watchers, and constantly opening/parsing all the files in the vault, in order to create their own cache files. Some form of centralized access to this capability could help to ensure stability. Note: this doesn’t necessarily mean that plugins should be writing to the core cache file itself, I’m merely talking about the mechanism that creates the cache file.
- Plugins that want access to UI elements and Dom manipulation, sounds like that’s already covered
- Plugins that want to register for and react to specific App events. For example, a plugin might want to know when an editor is switched to preview mode and vice versa, or that a new file has been loaded into an existing editor window, etc…
Wanted to get this on the radar, because you can start to build some really powerful plugins by combining these different capabilities, even though they’re useful on their own.
Would love to hear people thoughts on the topic.