This repository has been archived by the owner on Dec 30, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 386
feat(indexId): rely on indexId rather than indexName in SSR [PART-4] #1842
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
samouss
changed the title
feat(indexId): rely on indexId inside SSR [PART-4]
feat(indexId): rely on indexId rather than indexName in SSR [PART-4]
Dec 28, 2018
Deploy preview for react-instantsearch ready! Built with commit 4a48f8c https://deploy-preview-1842--react-instantsearch.netlify.com |
On your GIF you can see a query triggered after the first render. I would suppose it's unneeded on SSR. Is it hard/impossible to prevent? |
tkrugg
reviewed
Jan 3, 2019
packages/react-instantsearch-dom/src/core/__tests__/createInstantSearchServer.js
Outdated
Show resolved
Hide resolved
tkrugg
reviewed
Jan 3, 2019
packages/react-instantsearch-dom/src/core/__tests__/createInstantSearchServer.js
Show resolved
Hide resolved
tkrugg
approved these changes
Jan 3, 2019
samouss
force-pushed
the
feat/part-3-refactor-manager
branch
from
January 3, 2019 14:22
96d0c86
to
1546723
Compare
It's already the behaviour we have currently. It's a bit outside of the scope of this PR but yes it's possible to avoid the network request. We don't took the time to make it invisible yet. We already have the response so we could hydrate the client cache to avoid the network request. |
samouss
force-pushed
the
feat/part-4-ssr
branch
from
January 3, 2019 14:59
3749e78
to
af8f7c2
Compare
Haroenv
reviewed
Jan 3, 2019
packages/react-instantsearch-dom/src/core/__tests__/createInstantSearchServer.js
Outdated
Show resolved
Hide resolved
samouss
force-pushed
the
feat/part-4-ssr
branch
from
January 3, 2019 15:30
af8f7c2
to
cb92955
Compare
* feat(indexId): rename getIndex -> getIndexId [PART-6] (#1851)
samouss
added a commit
that referenced
this pull request
Jan 4, 2019
samouss
added a commit
that referenced
this pull request
Jan 4, 2019
* feat(indexId): rely on indexId rather than indexName [PART-2] (#1835) * feat(indexId): refactor createInstantSearchManager [PART-3] (#1840) * feat(indexId): rely on indexId rather than indexName in SSR [PART-4] (#1842) * feat(indexId): refactor createInstantSearchServer [PART-5] (#1843) * feat(indexId): rename getIndex -> getIndexId [PART-6] (#1851)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This is the fourth part of the work to support multi-index search on the same index. The PR updates how the search parameters are computes inside
createInstantSearchServer
. We now rely on theindexId
rather thanindexName
.Changes
createInstantSearchServer
: the value returned byfindResultsState
have now anindexId
to be able to reconstruct the result on the client side. Previously we were relying on theindexName
we can't anymore because the same index can be used multiple times.
Result