Hi @kotaindah55

while I don't have time to examine the code changes, this looks promising based on the description!

Indeed, I'd prefer the a more elegant one-off solution (single event and done), instead of the currently employed, also event-driven way of focused listening on changes of a selected DOM node. While from performance perspective there will be no difference, what you propose - based on the description - promises clarity and simplicity of the solution.

The current solution, handled by the single function setWatcherForDelayedFileExplorerView, is monitoring changes of a selected DOM node (the parent node of the FileExplorer view)

Thanks for your respond!

My logic above also can be considered one-off solution. The handler will only be applied if the File Explorer view entered the deferred state. On the contrary, if the view was fully loaded at the first time, the handler is not needed anymore (since deferred views only happen at startup, the next added view will always be fully loaded).

Before I move forward applying the logic, probably you want to look at my codes first (it's not a lot of codes) to check whether it will affect the other logic or not.

Hi @kotaindah55,

I'm short on time these days and I'd like to look and review the entire solution, when ready.

If you make it as an isolated and reusable module (which probably is your approach), testable standalone and in isolation, this would prove it is a safe alternative, also for other Obsidian plugins. It can be published as a reusable standalone project in github. I noticed, that some plugin authors still struggle with correct handling of the not-so-trivial Obsidian deferred views.

Then it will need to be compared with the existing solution in this plugin from various perspectives and we will see.

Thanks for contributing!

Hi @SebastianMC!

I've finished the refactor, also tested the modified plugin in Obsidian application directly. From the result I got, the plugin works as expected.

Hi @kotaindah55,

thanks for the updates!

I've briefly examined the changes in main.ts and at glance the integration with the UndeferHandler seems to be too far fetching. For example, removing some pieces of code related to the customSortAppliedAtLeastOnce flag affects related scenarios, and there are many not obvious scenarios to test.

While the resulting code could be perfectly valid and working (time consuming tests and detailed code review are needed), this range of changes is too risky at the current stage of the plugin (stable, maintenance, minor improvements and bugfixing). Testing all of the scenarios would require much time.

If your goal is to integrate this with the plugin, could you please:

• make the integration point in main.js as minimal and isolated as possible, e.g. replace the body of setWatcherForDelayedFileExplorerView function, plus - if absolutely required - some init call when the plugin loads
• don't touch any other scenarios, flags and functions, however tempting it could seem. This is a working production code

Overall, please keep in mind the big picture:

• the PR is not about fixing some major bug and not about improving the performance, so there is no rationale to justify this range of changes and introducing this level of risk
• the PR is about replacing a simple and working solution (the body of setWatcherForDelayedFileExplorerView, 30 lines of readable code residing in a single place) with some equivalent solution
• this is why I suggested to encapsulate the UndeferHandler in a separate library with its own set of tests (tests are a must here), plus some demo code showing how to integrate the library in Obsidian plugin(s)
• from my perspective, as I already stated, the keyword here is 'a more elegant solution'. That's why I changed the title of this PR. For me, a more elegant solution for a working production code should be more readable, safe(r), isolated, etc.