The challenge is at technical level and it boils down to the sequence of the following events and their dependencies:
(a) the plugin can get access to File Explorer view (the view must exist)
(b) the plugin can hook up on (patch the) getSortedFolderItems method of File Explorer (monkey patch on .prototype)
(c) Obsidian populated metadata cache for all notes in the vault
(d) The plugin can read and parse sorting specs from the metadata (YAML frontmatter is part of the metadata)
(e) The sorting orders which depend on note's metadata values can be determined
(f) Obsidian populates the data for File Explorer and requests sorted lists of folders and notes from the plugin
The ideal sequence of events is when (f) happens as the last one, because it depends on the other listed events.
The problem observable by user is that on app start or vault (re)load the custom sorting is not applied, even if it is enabled.
The underlying reason is that the event (f) occurs not as the last one (relatively to the listed events). In other words, the plugin has no chance to apply the custom sorting because it doesn't know the custom sorting specifications to apply (they are stored in metadata, which is not available at that point). Also, some sorting methods depend on notes metadata, another blocker. Or the File Explorer view is not populated correctly.
Some fundamental questions:
Can the patching of File Explorer prototype be done at any moment, regardless of whether the view is lazy or not?
How to address the dependency of (d) on (c)?
The initial idea is to cache persistently (plugin folder file) the most recently parsed sorting specification.
How to address the dependency of (e) on (c)?
This dependency is much more challenging: metadata of notes in the vault. For various reasons it doesn't make sense to create yet another cache of notes metadata relevant to sorting, by design. An overkill for larger vaults and a high risk of unwanted side-effects for larger vaults.
Other options:
Delay the actions (d) and (e) intentionally after (c). In other words, trigger sorting of items in File Explorer after (c) is completed.
No, no and no. I tried this and it has a very unpleasant UX effect: File Explorer is displayed in the standard default order and then, after a second or two, it flashes and redisplays items in a different order (custom sorted). Not acceptable, the view and focus in File Explorer can change upside-down causing confusion.
Are there other alternatives?
Theoretically addressing the dependency of (d) on (c) by a new cache (as described above) could address all the vaults which don't involve metadata-based sorting methods. A partial win. Yet, not having any information about the % of users not using metadata-based sorting it could be like addressing only 5% of users.
Short term low-hanging-fruit solution:
detect the condition in scope (the plugin couldn't apply the custom sorting on vault load / app start)
show a popup "click to apply the custom sorting now"
introduce a new flag in settings (on, by default) which enables / disables the popup
Let me keep this item open until a viable solution idea appears.
The challenge is at technical level and it boils down to the sequence of the following events and their dependencies: (a) the plugin can get access to File Explorer view (the view must exist) (b) the plugin can hook up on (patch the)
getSortedFolderItemsmethod of File Explorer (monkey patch on .prototype) (c) Obsidian populated metadata cache for all notes in the vault (d) The plugin can read and parse sorting specs from the metadata (YAML frontmatter is part of the metadata) (e) The sorting orders which depend on note's metadata values can be determined (f) Obsidian populates the data for File Explorer and requests sorted lists of folders and notes from the pluginThe ideal sequence of events is when (f) happens as the last one, because it depends on the other listed events.
The problem observable by user is that on app start or vault (re)load the custom sorting is not applied, even if it is enabled. The underlying reason is that the event (f) occurs not as the last one (relatively to the listed events). In other words, the plugin has no chance to apply the custom sorting because it doesn't know the custom sorting specifications to apply (they are stored in metadata, which is not available at that point). Also, some sorting methods depend on notes metadata, another blocker. Or the File Explorer view is not populated correctly.
Some fundamental questions:
Other options:
Delay the actions (d) and (e) intentionally after (c). In other words, trigger sorting of items in File Explorer after (c) is completed. No, no and no. I tried this and it has a very unpleasant UX effect: File Explorer is displayed in the standard default order and then, after a second or two, it flashes and redisplays items in a different order (custom sorted). Not acceptable, the view and focus in File Explorer can change upside-down causing confusion.
Are there other alternatives?
Theoretically addressing the dependency of (d) on (c) by a new cache (as described above) could address all the vaults which don't involve metadata-based sorting methods. A partial win. Yet, not having any information about the % of users not using metadata-based sorting it could be like addressing only 5% of users.
Short term low-hanging-fruit solution:
Let me keep this item open until a viable solution idea appears.