3 ms·

Only UI state should be stored in the URL and navigational UI state should (almost) always be stored in the URL. That way when you refresh or share the page it

Only UI state should be stored in the URL and navigational UI state should (almost) always be stored in the URL. That way when you refresh or share the page it will look (near) identical. Don’t store user state in the URL, that may bite them when it’s shared.

Scarblac 4y ago
Not all UI state though. If you use the back button, you want something to happen that's similar to going back a page, not undo a tiny change on that page. I say that navigation state should be in the URL.
- graftak 4y ago
  That depends on what method of storing state in the URL you use; History#replaceState[1] versus #pushState[2], not on storing state in the URL in general. [1] https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState https://developer.mozilla.org/en-US/docs/Web/API/History/rep... [2] https://developer.mozilla.org/en-US/docs/Web/API/History/pushState https://developer.mozilla.org/en-US/docs/Web/API/History/pus...
- dgb23 4y ago
  > I say that navigation state should be in the URL. That's a truism. You still have to decide what navigation is. - opening or closing a modal - switching between representations (example: grid view vs list view) - collapsing / hiding major parts of the screen - entering something into a search box - turning knobs on a form that draws a graph - drag and drop ui elements without side effects on the wider application - the above with side effects on the wider application All of these things and more have been implemented with or without changing the URL.
- fleddr 4y ago
  What is navigation and what is state is not always clear. Example: Visit https://www.dpreview.com/ https://www.dpreview.com/ Next, we open this article: https://www.dpreview.com/samples/7583235225/nikon-z-50mm-f1-2-s-sample-gallery https://www.dpreview.com/samples/7583235225/nikon-z-50mm-f1-... Within the article, we click the main photo, which opens another page with a slideshow: https://www.dpreview.com/sample-galleries/8661039925/nikon-z-50mm-f1-2-s-sample-gallery/1047586991 https://www.dpreview.com/sample-galleries/8661039925/nikon-z... As we're keenly interested in the slideshow, we use the next arrow to cycle through all 47 photos. Now that we're done with that, the slideshow has no further use, so let's hit BACK to return to the article we came from, and BACK again to return to the homepage. Doesn't work, we have to hit BACK 47 times first. Because in this case slideshow manipulation is seen as navigation, and thus part of history. Is navigating a slideshow state or navigation in itself? You tell me, it's not very obvious. Each slide is bookmarkable so it very much looks like a navigation action. And yet it does not lead to a great experience.

Scarblac 4y ago

Not all UI state though. If you use the back button, you want something to happen that's similar to going back a page, not undo a tiny change on that page. I say that navigation state should be in the URL.

graftak 4y ago
That depends on what method of storing state in the URL you use; History#replaceState[1] versus #pushState[2], not on storing state in the URL in general. [1] https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState https://developer.mozilla.org/en-US/docs/Web/API/History/rep... [2] https://developer.mozilla.org/en-US/docs/Web/API/History/pushState https://developer.mozilla.org/en-US/docs/Web/API/History/pus...
dgb23 4y ago
> I say that navigation state should be in the URL. That's a truism. You still have to decide what navigation is. - opening or closing a modal - switching between representations (example: grid view vs list view) - collapsing / hiding major parts of the screen - entering something into a search box - turning knobs on a form that draws a graph - drag and drop ui elements without side effects on the wider application - the above with side effects on the wider application All of these things and more have been implemented with or without changing the URL.
fleddr 4y ago
What is navigation and what is state is not always clear. Example: Visit https://www.dpreview.com/ https://www.dpreview.com/ Next, we open this article: https://www.dpreview.com/samples/7583235225/nikon-z-50mm-f1-2-s-sample-gallery https://www.dpreview.com/samples/7583235225/nikon-z-50mm-f1-... Within the article, we click the main photo, which opens another page with a slideshow: https://www.dpreview.com/sample-galleries/8661039925/nikon-z-50mm-f1-2-s-sample-gallery/1047586991 https://www.dpreview.com/sample-galleries/8661039925/nikon-z... As we're keenly interested in the slideshow, we use the next arrow to cycle through all 47 photos. Now that we're done with that, the slideshow has no further use, so let's hit BACK to return to the article we came from, and BACK again to return to the homepage. Doesn't work, we have to hit BACK 47 times first. Because in this case slideshow manipulation is seen as navigation, and thus part of history. Is navigating a slideshow state or navigation in itself? You tell me, it's not very obvious. Each slide is bookmarkable so it very much looks like a navigation action. And yet it does not lead to a great experience.