Thanks for the reply.
I am using canDeactivate() to prevent the route changing if the form is dirty when the user tries to leave the form (by clicking on something else in the view). That works fine.
The problem I am having it how to easily disable all the other elements, buttons, links, etc, on screen when the open form has unsaved data. OK - these elements won’t work if they are triggering a navigation - all clicks and button presses will get swallowed by the canDeactivate on the active route view returning false. But to the user, it looks like the app is broken with clickable links and buttons looking active but just appearing to do nothing. And I probably also want to prevent clicking stuff that is not part of the route navigation.
The overlay approach does not really solve those problems 100%, and is a bit of a no-no from an accessibility point of view. I probably do need to disable things properly and add aria tags etc.
You mention a router event handler. I think that is what I was alluding to. What event would it be that I would need to subscribe to - I can’t see any documentation on the internals of the router and events it is broadcasting?
Also, my problem would be that every single widget in my app would need to have its
disabled property aware of that event (in addition to any other rules that would make it disabled). That can get messy and become a bit of a maintenance nightmare.
I am guessing I would need something that could do this for anything listening (effectively every widget on the view):
- user is trying to change the route
- but that has been blocked by some existing vm’s canDeactivate() stepping in and blocking it
- I need to be disabled too (if I am not already disabled by something else)
Originally, I was just routing from the read view to a completely separate edit view. I then tried sliding it in like in your demo. But the designers are keen to do editing in place all on the dashboard view by appearing to flip the card states from read to edit. I did not have to change too much to do that - but I do end up with a lot of
<router-view></router-view> on my main dashboard page.
I could rewrite it to use composition easily enough, but that does not appear to give me any advantage (maybe I am missing something) - I still have lots of stuff on the page that needs to be disabled when any given panel is in edit mode. And there is no navigation happening, so no
canDeactivateto block the card state change - I would need to manage what read/edit view was being composed or visible at any given time. Not a huge problem doing that.
My screenshots above are a really cut down example. The real app could have 10s of read/edit cards on screen at any one time.
Off course there is always another option. Don’t try to block all the screen widgets, but just alert the user if they try to leave an open edit card with with unsaved form data. That is much easier to code, but less nice for the user because we allow them to do things that result in errors and warnings.
I have a demo project at:
where I am trying to explore some of the issues.