Each page contains a small booking form, where you can enter your information and get a price quote. (View Highlight)
What should happen when a user refreshes the page? Should the form be cleared, ready for them to enter their information again? If we want to pre-fill the form with the information they’ve already entered, storing it in the URL isn’t the only way. It could be part of local storage, or a cookie, or in a database. (View Highlight)
But people also share prospective bookings with other people. If I’m planning a trip with a friend, I can send them a link to the listing I’m looking at, and they’ll see the same price quote I’m seeing, with the same dates and number of guests. (View Highlight)
No other state management tool achieves the sharability of state that the URL does. (View Highlight)
This has important usability implications. If you’re on a page, and you click a link to go to another page, and then you hit the back button, you expect to go back to the page you were on before you clicked the link. (View Highlight)
All web applications should be built with the understanding that history navigation is part of the user interface. (View Highlight)
Modal popup dialogs can be a useful way to show additional information to users, without taking them away from the page they’re on. (View Highlight)
On smaller screens, there is rarely enough space to show a modal and the page content at the same time, so many websites make the modal take up the whole screen, which looks like a new page to the user. (View Highlight)
For this reason, it’s important that the modal can be closed by hitting the back button. Mobile users will often swipe left to trigger their device’s back navigation. If you take them to the previous page instead of closing the modal, they’ll be confused and feel like they just went back 2 pages. (View Highlight)
If the user should be able to bookmark the modal, or share it with someone else, then it should have its own URL. It’s not important whether this is part of the pathname like /issues/edit or a query parameter like /issues?modal=edit, as long as it’s in the URL. (View Highlight)
If the modal is relevant to the user, but not to anyone else, then you may want a URL that doesn’t share the modal. (View Highlight)
Instead of a query param, you can use Location State to store whether the modal is open or closed without it being part of the URL. (View Highlight)
This state is still stored in the browser history. Forward, back, and “re-open closed tab” will all work as expected. (View Highlight)
The back button should always take the user to the previous logical state. Pressing the back button to close a modal makes sense, and pressing it again should take them to the previous page. (View Highlight)
