Dialog ergonomics and potential improvements

I am experimenting with this library which so far has been excellent and a relatively unknown gem in the phoenix ecosystem. I have some questions regarding the dialog/modal ergonomics vs core_components modal. Perhaps I have misunderstood the intent but I am attempting to have a *somewhat* similar experience to core_components modal but the changes to work with dialog seem quite intrusive. Some questions: 1. Is it possible to set the initial show/hide state using an attribute such as ```is_open_on_mount``` ? I did not see an obvious way to open a dialog from the server side without a form field. 2. Is use of a *form* field absolutely necessary for managing show/hide state? i.e. could a regular assign or even a static value ```true``` be used? 3. Is there a reason dialog show/hide state is not managed client side? One could potentially use ```JS.set_attribute({"data-show", "true"})``` so that state is sticky in the UI and doesn't require polluting the form, plus it avoids the round tripping and requirement to re-inject the state in the form on each event handler. Additionally with some hook logic in ```onBeforeElUpdated``` a server temporary assign could be used to override (and un-stick) client state to the server specified value. 4. Is there a way to handle dialog cancel differently to a confirmation action? I note that core_components modal has a dedicated event handler for cancel events. I am happy to work up a PR for improving dialog ergonomics, but first I wanted understand your thoughts on the above and what you see as possible improvements based on your experience which has led to the current approach.