I have a form that contains an action which opens a new screen for that item.
When someone closes the new screen I want them to be nav’d back to the form, but instead it closes the form too.
As it stands a user can click the back arrow to get from the new screen back to the form, but typically I think many users will click the X and get taken out of the form altogether which is not what I want to happen.
I still don’t get when to use different screen types.
Any ideas?
thanks
Forgive me if I’m wrong (not at my computer) but there is a “go back” action which should do the trick. Also a “close overlay” action.
You may even be able to hide the X with a bit of CSS if you need.
Yes I’m aware there are go back and close overlay actions. But some users will still click the X, so I’m asking if it’s possible to navigate them back to the form when they do so.
Not possible, so you have to hide the X, and implement a button to go back instead.
However, even then, if you’re using an overlay, they can just click outside of the overlay to close it.
I’ve fought this battle before as well. Couldn’t find a suitable workaround. It’s also a different experience between mobile and desktop environments. I don’t really have any good advice other than to not put an overlay on top of an overlay. It ends up not working the way you want it to.
This part is quite dizzying for the CSS code I’ve done before. I can’t find the old code anymore. This is just from a quick search, and maybe it’s worth trying just for fun. For now, it seems to be working for me with the slide-in type on the new-screen display. What the side effects are, I don’t know yet…
Place the class name “someClass” on any component on the “new screen.”
Please let me know the result…
/*Hide X button*/
#page-root:has(.someClass) [data-testid="slide-in-content"] button:nth-child(3), #page-root:has(.someClass) .desktop-modal button:nth-child(3){
display: none;
}
#app-root:has(.someClass) *, #page-root:has(.someClass) #nav-root > div > div > div {
pointer-events: none !important;
}
#page-root:has(.someClass) #overlay-root *, #page-root:has(.someClass) [data-testid="slide-in-content"] button {
pointer-events: auto !important;
}
Or try the full version for the slide-in and overlay below:
#page-root:has(.someClass) [data-testid="slide-in-content"] button:nth-child(3), #page-root:has(.someClass) .desktop-modal button:nth-child(3), #page-root:has(.someClass) #nav-root > div > div > div > header > div > div:nth-child(3){
display: none;
}
#app-root:has(.someClass) *, #page-root:has(.someClass) #nav-root > div > div > div {
pointer-events: none !important;
}
#page-root:has(.someClass) #overlay-root *, #page-root:has(.someClass) [data-testid="slide-in-content"] button, #page-root:has(.someClass) > div > div.floating-modal > div > div > div > div > button, #page-root:has(.someClass) #nav-root > div > div > div > header > div > div > button {
pointer-events: auto !important;
}
Thanks Jeff. I got a Product Manager to review the app and she didnt seem to like the way I had the overlay within an overlay and that was without spotting this closing out issue. For now I’m just going to put a back button up top and later will redesign to avoid this altogether.
thanks, I don’t have CSS edit-ability on my plan but will bookmark this for future ref.
Actually, so if I had just had the form open as Main or Current I could have avoided this?
Switching now is going to wipe everything, or is there a way to avoid this?
It’s Ok, I’ve used it before in a case where I created a pop-up. Maybe someone else will need it in the future.
Switching the target should not wipe anything.
Yes, this idea seems to work, and its behavior is different. Or you could use a Form Container.
Cool, changed the target to Current and that gets rid of the X to close. I was thinking it would wipe everything but was getting mixed up with what happens when changing a new screen to a details screen etc.
It might also help if I actually read more of the documentation.