fix(routing): fix history router based on history length

[FabienMotte]

Summary

This PR solves the issue with the history router when the InstantSearch.js is disposed:

• in a SPA use case, the URL should not be cleaned.
• in a modal use case, the URL should be cleaned.

The fix has been suggested by @Haroenv and it's based on the window.history.length. It allows to determine if a window.history.pushState has been triggered elsewhere, and thus to prevent the write (called when dispose is called on the InstantSearch.js instance) method from calling window.history.pushState.

Result

As a result, in a SPA use case, the history stack is correct and the browser back button works as expected. In a modal use case, when the InstantSearch.js instance is disposed, the URL is cleaned as expected.

SPA use case: https://codesandbox.io/s/vue-instantsearch-spa-fixed-fsdno
Modal use case (not changed): https://codesandbox.io/s/instantsearch-js-modal-zg12q

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit de02dca:

Sandbox	Source
InstantSearch.js	Configuration
vue-instantsearch_spa_fixed	PR
instantsearch.js_modal	PR

[FabienMotte]

Thanks for your reviews!

I think it makes sense to document these two behaviors @sarahdayan mentioned:

Routing with debounced (more than 400 ms) third-party client-side router does not clean the URL after navigating

The scenario as I understand it is:

• User refines InstantSearch, route updates (/?indexName[query]=Apple)
• User clicks navigation handled by 3rd party router, but router doesn't kick in right away because it's debounced (longer delay than ours)
• InstantSearch is disposed, history length is the same, so it cleans (/)
• Router finally writes (/about)

If yes I think this is clear, but we should probably document it because having this intermediary / route can be surprising.

Routing using replaceState cleans the URL after navigating

Yup we do it in the next step.

Is this a behavior worth documenting? Should we say that our router doesn't work well with other routers that use replaceState?

WDYT?

[Haroenv]

Where would you document that behaviour? https://www.algolia.com/doc/api-reference/widgets/history-router/js/#about ?

[Haroenv]

🎸

[FabienMotte]

Where would you document that behaviour? https://www.algolia.com/doc/api-reference/widgets/history-router/js/#about ?

I think it could make sense in that page indeed, WDYT @sarahdayan?

[sarahdayan]

@FabienMotte Yes, we can document it here and have warnings that link to it in the routing guides that use the historyrouter:

• https://www.algolia.com/doc/guides/building-search-ui/going-further/routing-urls/js/
• https://www.algolia.com/doc/guides/building-search-ui/going-further/routing-urls/vue/
• https://www.algolia.com/doc/guides/building-search-ui/going-further/routing-urls/angular/