That’s a good point, but I think we should handle this potential error state in the
LockOn class. I’ve added the note about this in the refactor PR (3.)
I tried the replace-if-present first, but in the situation illustrated in the gif (i.e. transitioning to a post via a link with an anchor) the order of installed locks is: “scroll to the anchor” first, then “scroll to the post”. Hence discarding if a lock-on is present.
Ideally, there would be just a single lock-on to begin with, but both make sense where they are - one being our default scroll-to-element lock installed in
handleURL and the other being installed by the
topic-from-params route (via
(some time later)
Okay, here’s an attempt to make lockOn replace-if-present: https://github.com/discourse/discourse/commit/d300eab4b4f45038046712ae6bebfad8bee7614c
It uses the
_discourse_anchor (from the other PR) and then passes it around through two transitions and a controller setup.
(It’s just a reference, i.e. doesn’t work on it’s own It requires the commits from the refactor, and it also uncovered an unrelated issue that has yet to be solved. damn you, fontawesome sprites!)