During SSR the url doesn't get read

[ArcoMul]

Bug 🐞

What is the current behavior?

During SSR the page gets rendered with an empty state because the state doesn't get read from the url.

Make a sandbox with the current behavior

See SSR example, neither routing.router.read or routing.router.onUpdate gets called.

What is the expected behavior?

That vue-instantsearch tries to retrieve the current state from the URL, using the routing.router methods

Does this happen only in specific situations?

No

What is the proposed solution?

That either routing.router.onUpdate gets called so that the callback can be used to push the state into vue-instantsearch, or that routing.router.read gets called so that either the state is retrieved automatically.

What is the version you are using?

3.3.0 and 4.0.1

[ArcoMul]

Might be that I'm not aware of another way to push the state into vue-instantsearch, the example suggest though that onUpdate should be called during server-side rendering. If there is any other preferred way I'm happy to hear so :-)

See also the post I created on Discourse: https://discourse.algolia.com/t/how-to-pass-current-url-to-vue-instantsearch-routing-during-ssr/13476

[reinoldus]

I think it's not the url, my ssr is not working either anymore, this sandbox works:
https://codesandbox.io/s/serene-leftpad-jp7gb

this one doesn't:
https://codesandbox.io/s/crazy-sid-tkwu7?file=/package.json

Only change is that nuxt was upgrade to 2.15.8

not sure what deps it broke

[reinoldus]

I reused my old yarn.lock and it works again, either some vue package or some instansearch.js package caused this issue. I leave it to the maintainers to figure out which one sh*t the bed

[Haroenv]

Those two sandboxes look exactly the same to me, even the nuxt version resolves to 2.15.0 in both, the . Unfortunately I have no idea what's the difference that could be causing the url not to be read. I'm guessing maybe codesandbox doesn't respect the lock file somehow? can you reproduce this working/not working locally too?

[reinoldus]

That is highly interesting, so what I did was "yarn upgrade" in the other sandbox, not sure why the yarn.lock didn't update, I ran yarn upgrade again and now the lock file has been updated.

And yes I had the exact same issue locally:
I did "yarn upgrade" locally and the "url not read" bug occurred.

I then copied an old yarn.lock over and upgrade packages (nuxt etc.) individually, but not vue-instantsearch and the bug didn't occur, so my assumption is that some of the "@algolia" dependencies caused the issue.

[Haroenv]

do you have a place with the actual packages that are different (a new lock file or something?)

[ArcoMul]

For your information, in this discourse topic we were also digging a bit deeper: https://discourse.algolia.com/t/how-to-pass-current-url-to-vue-instantsearch-routing-during-ssr/13476/7

I came there to the conclusion that things break in between vue-instantsearch 3.0.3 and 3.3.0, but I also had weird behaviour where it wouldn't work any more after reverting back to a version which should work.

[Haroenv]

Between those versions InstantSearch.js (a dependency) has changed a lot of versions, I guess that would be the issue, but not sure yet. Could you pinpoint it to a certain version via a lock file?

[reinoldus]

I can narrow it to these versions:

Here are the lock files:
https://wetransfer.com/downloads/1e635c3cc581c8c055ae7facd2a3b0df20210928100402/a1068fefda36c3ce8adf2954432880a620210928100426/00086f

[Haroenv]

In that case you can try the following things and see if that continues to work for you:

• force instantsearch.js to a lower version (4.17.0 seemed to work for you
• make sure you follow the upgrade guide for Vue InstantSearch (one side uses v3 and the other v4) -> https://www.algolia.com/doc/guides/building-search-ui/upgrade-guides/vue/#upgrade-from-v3-to-v4
• slowly update InstantSearch.js until the issue no longer shows between 4.17 and 4.30

[ArcoMul]

@Haroenv I found that from on instantsearch.js 4.29.1 SSR breaks, 4.29.0 still works

[ArcoMul]

With 'SSR breaks' I mean that the url doesn't get read, and thus every page on the server is rendered without any state

And I tested that in combination with vue-instantsearch 3.3.0

[Haroenv]

hmm, seems like it's the same issue as showed up in #1066, sorry that I haven't yet found out exactly why https://github.com/algolia/instantsearch.js/pull/4849/files causes the URL to be read / written as empty (read too early and saved?)

[ArcoMul]

Here is a sandbox demonstrating the issue: https://codesandbox.io/s/cranky-mountain-2p5pg?file=/package.json
When navigating to the Search page, selecting an refinement option, then refreshing the page keeps the refinement selected because SSR renders the list correctly.

After increasing the version of instantsearch.js in the "resolutions" section of package.json:21 to version 4.29.1 the option of the refinementlist doesn't stay selected because SSR renders the page with an empty state (and thus no option selected)

[ArcoMul]

@Haroenv Great that the issue has been found, I'll stick to 4.29.0 of instantsearch.js for now

[Haroenv]

We have just finished a comprehensive refresh of the server-side interaction with routing in the case of Vue InstantSearch. This managed to close this issue for both v3 in 3.9.0 and v4 in 4.3.2.

The pull requests in question are:

• fix(server): extend component correctly if at root #1105 (v3) fix(ssr): extend component correctly if at root (vue2) #1104 (v4)

If the component at the root is the one doing findResultsState, it doesn't have access to $vnode, and in that branch the component name is required to be passed via the first argument.

• feat(ssr): prevent initial network request #1106 (v3) feat(ssr): prevent initial network request #1090 (v4)

This is a little more involved, but fixes the issue where routing is not taken in account. Essentially in InstantSearch it was changed so that routing only gets read on .start, but Vue InstantSearch was faking start.

Luckily, in a recent version of InstantSearch, some functionality of server rendering / initial results has moved inside InstantSearch itself, and it avoids the issue, as we can use regular 'start' from then on.

[ArcoMul]

@Haroenv Finally got around testing this, the latest version fixes the issue! 🎉