-
Notifications
You must be signed in to change notification settings - Fork 530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(analytics): generate fallback userToken #5500
fix(analytics): generate fallback userToken #5500
Conversation
* feat(insights): automatically load search-insights if not passed FX-2244 * different wording * fix(insights): notify of error when insights fails to load * prettier snippet
To better prepare for the insights middleware being automatically added, we are making the following changes: - useCookie by default true so userToken does not need to be provided - still call `insightsClient` if no userToken is found (userToken can be applied using useCookie, thus not known) - error on unknown algolia credentials converted to warning
FX-2250 Co-authored-by: Sarah Dayan <5370675+sarahdayan@users.noreply.github.com>
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 f107a67:
|
}, | ||
}); | ||
search.use(insights); | ||
// const insights = instantsearch.middlewares.createInsightsMiddleware({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to revert
This makes sure when the same userToken is set multiple times, it doesn't cause multiple search requests, as could be the case if something would call setUserToken without condition. Discovered in #5500, but should be merged separately.
This makes sure when the same userToken is set multiple times, it doesn't cause multiple search requests, as could be the case if something would call setUserToken without condition. Discovered in #5500, but should be merged separately. Co-authored-by: Fabien Motte <fabien.motte@algolia.com>
ad20519
to
b6ef7b3
Compare
This makes sure when the same userToken is set multiple times, it doesn't cause multiple search requests, as could be the case if something would call setUserToken without condition. Discovered in #5500, but should be merged separately. Co-authored-by: Fabien Motte <fabien.motte@algolia.com>
This makes sure when the same userToken is set multiple times, it doesn't cause multiple search requests, as could be the case if something would call setUserToken without condition. Discovered in #5500, but should be merged separately. Co-authored-by: Fabien Motte <fabien.motte@algolia.com>
b6ef7b3
to
00568aa
Compare
This makes sure when the same userToken is set multiple times, it doesn't cause multiple search requests, as could be the case if something would call setUserToken without condition. Discovered in #5500, but should be merged separately. Co-authored-by: Fabien Motte <fabien.motte@algolia.com>
b4e9504
to
7f415a8
Compare
With the RFC on decoupling (or using v3) we'll likely not need this. Should we close @Haroenv? |
This makes sure when the same userToken is set multiple times, it doesn't cause multiple search requests, as could be the case if something would call setUserToken without condition. Discovered in #5500, but should be merged separately. Co-authored-by: Fabien Motte <fabien.motte@algolia.com>
This makes sure when the same userToken is set multiple times, it doesn't cause multiple search requests, as could be the case if something would call setUserToken without condition. Discovered in #5500, but should be merged separately. Co-authored-by: Fabien Motte <fabien.motte@algolia.com>
Summary
Result