Use case or problem
Creating/opening a modal is very easy. You instantiate it with the constructor params you want and then you open it. No complicated lifecycle stuff or initial states.
Views on the other hand, are much more complicated:
- you can’t create them directly, you have to provide a Factory function (which can’t take any argument) then request obsidian to show them
- because previous point, you can’t provide an initial value/state, you have to handle uninitialized state on your view, and when requesting obsidian to open the view, also provide the desired state
- because you can’t call your constructor directly, and can only provide state indirectly, you basically have to treat this two parts of the same application as two remote systems, forcing you to “validate” the provided values in the view while loosing all the type safety in the calling site. This is a loose-loose situation
- the data you can pass down to your view is limited to serializable data, adding just extra inconvenience
This is all very complicated because how disconnected each part of the same outcome. Every time I want to add a new view ro my plugin I have to review my notes about this flow because how complicated it is
Proposed solution
I think a new type of view should be provided that is as easy to create and manage as a modal.
Current workaround (optional)
You can just treat obsidian as the “rendering engine” and build your own routing, communication method and other stuff within the boundaries of your plugin. This is basically treating obsidian like it was a browser tab and just build your app inside of it.