Page MenuHomePhabricator

Replace old hard-coded URI-based "changes saved" jank with new overgeneralized cookie-based "changes saved" jank
ClosedPublic

Authored by epriestley on Apr 18 2020, 10:24 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 24, 11:35 PM
Unknown Object (File)
Wed, Apr 3, 3:55 AM
Unknown Object (File)
Mar 21 2024, 2:45 PM
Unknown Object (File)
Feb 12 2024, 2:19 PM
Unknown Object (File)
Jan 10 2024, 1:25 AM
Unknown Object (File)
Jan 9 2024, 2:32 PM
Unknown Object (File)
Jan 5 2024, 1:25 PM
Unknown Object (File)
Jan 5 2024, 1:24 PM
Subscribers
None

Details

Summary

Ref T13515. Settings currently has some highly specialized code for rendering "Changes saved." messages. The "saved" state is communicated across a redirect-after-POST by adding /saved/ to the end of the URI.

This isn't great. It needs a lot of moving pieces, including special accommodations in routing rules. It's user-visible. It has the wrong behavior if you reload the page or navigate directly to the "saved" URI.

Try this scheme, which is also pretty sketchy but seems like an upgrade on the balance:

  • Set a cookie on the redirect which identifies the form we just saved.
  • On page startup: if this cookie exists, save the value and clear it.
  • If the current page started with a cookie identifying the form on the page, treat the page as a "saved" page.

This supports passing a small amount of state across the redirect-after-POST flow, and when you reload the page it doesn't keep the message around. Applications don't need to coordinate it, either. Seems somewhat cleaner?

Test Plan

In Firefox, Safari, and Chrome: saved settings, saw a "Saved changes" banner without any URI junk. Reloaded page, saw banner vanish properly.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable