add(method)[FE-896]: Add method for executing code without listening for popstate

[zachpwr]

Summary:

Background:

nuclear-router listens for popstate events. The browser emits these events when the "Back" button is pressed or when the application executes window.history.back(). nuclear-router handles these events by re-evaluating the URL and executing the corresponding route handler.

The Optimizely application uses URL hashes (/my-page#dialog) to represent when a full page dialog is being shown. This allows the user to close the full page dialog by hitting the "Back" button on their browser. However, in order to close a full page dialog in any other scenario (i.e. the user clicks "Submit" or "Cancel"), the application calls window.history.back() to close the dialog and remove the hash from the URL (/my-page#dialog -> /my-page).

When the application performs this navigation, nuclear-router re-evaluates the route handler for that page even though removing the URL hash does not change the underlying route being accessed. This can potentially cause unnecessary API calls and initialization work to be executed.

Implementation:

This PR adds a method to the Router interface called executeWithoutPopstateListener. It accepts one parameter, fn. This method allows the consuming application to run code without the popstate listener active. The code to be executed without the popstate listener enabled is placed in the argument fn.

This will allow the Optimizely application to close dialogs using window.history.back() without the router re-evaluating the route for the page underneath the dialog. For example:

function closeDialog() {
    router.executeWithoutPopstateListener(() => {
        /**
         * This will not cause the router to re-evaluate since
         * it's wrapped in this function
         */
        window.history.back();
    });
}

Test Plan:

This PR adds a test case to ensure that the popstate listener is deactivated while executing the function passed to executeWithoutPopstateListener.

[jamesopti]

This approach requires the caller to know the side effect of window.history.back (in your example) as a wrapper around that method.

What if instead we configured nuclear-router to ignore hash changes?

That could be a bit overkill, but are there any reasons we'd want to re-route on pop-state of a hash change?

[jordangarcia]

@jamesopti that could be a reasonable way to go about it, but it seems a lot more risky. What in our app invisibly relies on route re-evaluation for hash changes, I definitely don't know where these happen off the top of my head.

My vote is for a more gradual approach, where we have to explicitly change the behavior by using this new function. This approach seems like it de-risks such a global change.

[jordangarcia]

🐑 💨

[jamesopti]

Might there be a reason to return this result to the caller?

[jamesopti]

@jamesopti that could be a reasonable way to go about it, but it seems a lot more risky. What in our app invisibly relies on route re-evaluation for hash changes, I definitely don't know where these happen off the top of my head.

My vote is for a more gradual approach, where we have to explicitly change the behavior by using this new function. This approach seems like it de-risks such a global change.

Fair. But I'd imagine @zachpwr plans to introduce this in the dialog manager's hideDialog method, which I'd guess is 99% of our hash usage.