Would be nice to pass data with this action too.
There’s a lot of benefits to using “go to previous mobile view” vs. navigate to view. like how you can show a modal vertically and they HIDE the modal vertically with previous aciton.
this is impossible (among other things) when using go to view. The problem is that you can’t pass data using previous.
Noted! The complication here is that we don’t know what the previous view is, because you can theoretically get to the same view from multiple places. So we’d have to figure out a way manage this
Even if you can just specify that back action to only go to one place per modal…that would be fine. The “back to previous” is such a good UX that we need it to be more flexible.
Or if you could just open up more UX options for the “go to view” action.
So by going back to a specific view, is this because you don’t want to add the view you are going to onto the stack? All the go to previous view does is pop the top view off the stack, but going to a specific view theoretically shouldn’t work that way
I missed this feature these days… I’ll give you a practical example of this functionality in action:
-User clicked the button to create a new contact
-Inside the contact there is a field that, when clicked, opens a new modal with a list of options for him to select one, and the selected value should return to the previous screen, when closing the modal with the list of items.
Of course, you can put this list on a bottom sheet, but it doesn’t have a nice aesthetic, like other apps that use modals for this, for example.
Let’s say i have an estimation app to calculate price of jobs. The mian page is a list of jobs. If you click on a job it will bring you to the jobs details page:
Here’s what I want.
I click button to add labor hours.
modal pops up with hours where I input how many hours. when i hit “save” i want the modal to hide vertically and for my estimation total price (on job details view) to recalculate based on the total hours i just saved.
I also want:
Let’s say I click button to add labor hours again.
Modal pops up where I can enter number of hours. But this time I need to select overtime hours and select a new rate. So I click a button on the modal that says “choose hour type” this should swipe over (inside the modal) to let me pick from a lit of type of hours. When I choose it should go back to the last modal page. then i hit save and the modal hides verticsally and calculator updates.
Why I cant do this today:
Modal (go back to prev):
Because I can’t pass data to instantly update the sales price and subtotals etc.
Modal (go to view):
Because it stays in modal which gives me two layers of the job details page. instead of hiding the modal.
Modal (go to view and RESET stack):
Because his does not hide vertically and it’s slow, and glitches to the list view (root) temporarliy then goes to the job detials page.
Sheet:
Because you can’t smoothly slide/ navigate to the choose hour type inside the modal. I can abruptly show hide but it’s not great. Plus this forces me to build massive single views with sheets that are basically single page apps.
Shorter version:
If you’re working down a list (like door dash checkout) to fill delivery address, payment method, etc. Using modal is better than a view. It gives more context that you’re still working down the main checkout page.
In door dash:
if you tap on delivery adddress, it pulls up a modal. You can add a work or home label which slides to a new view in the modal (2 views deep).
yes. this is one major reason. plus the slide and right, down and up, feels so much cleaner on “back to prev” action. the “go to view” action breaks the feeling of sliding / swiping.
Nick, let me know if you want me to DM you a video. I’m prob not doing a good job explaining here.
I suggest downloading door dash app and trying to recreate the checkout screen, working down the list to update:
Right now it’s not possible to create that smooth back and forth transition to work down a list and pass data to the checkout screen as state/property.
You have two options to recreate this:
JANKY FEELING: eliminate the smooth slide that returns you to the checkout view. which feels odd and janky. But you can get checkout data to populate instantly on page as state/ property.
SLOW or NO UPDATE WITHOUT REFRESH: you can keep the smooth transitions by using “back to view” but since there’s no way to pass data you’ll need to rely on updating the database. The checkout view will be out of sync with the DB when you return…which feels like your changes didn’t save. This might not seem bad initially - but try running calculations in an estimator where multiple text items are a sum. It’s like using a broken calculator.
I’ve only had a brief skim read of all this, cant’ you just use a sheet? Either set property of the current page, or if using a reusable sheet set the state of the reusable sheet, then use this in the current page for your data?
If I use a sheet, how can I beautifully slide back and forth to different sections of that sheet?
I don’t think I can. I need to show/hide groups like a single page app inside of a sheet. It’s a bit janky.
If you open a modal, then inside the modal go to view, then back - it’s a beatuful native expereince of sliding left and right and then vertically when you close the modal.
Yea the limitation of not being able to slide back and forth between views within a Modal has never been an issue for me. For my app I just show/hide sheets as the user fills in details, it’s still quite elegant. Here’s an example:
looks nice! when you hit “next” button, are you hiding current sheet and then showing a new one?
I’ve actually never tested hide sheet X and show sheet Y in a single workflow…but I’m assuming it quickly pulls one down and then brings one up.
Maybe I’ll mess with this. Thanks!
Yea give it a go, you can check out my app if you want to see it without going through the development yourself 
@nick.carroll - this request is important to building how users would expect. I think I’ve boiled it down to 3 options:
or
Option 1 would work great. Even if you’re limited to going back to just one view. I could duplicate if I needed to return to other views.
I think we just need global app states / props - that would be the cleanest solve here no?
maybe! could it allow the beautiful swipe animation, slide back, and slide down on modal?
EDIT: yes! i guess you would still just nav back and update the global thing, when global thing changes the info on prev view would also force update. yes…this wwould be killer. thanks
btw - you can already swipe to go back, just pan over from the left edge of the screen and it will go to the previous view
yep - most people don’t know that tho. safari and chrome on mobile do the same thing when you swipe back. no one that uses my PWA realize they can swipe back. they wont on native either
@nick.carroll, another way to phrase the problems:
View A’s data is stale when you navigate back from editing in View B.
If I use “go to view” I can pass data but lose the beautiful swipe transitions.
