fix: do not store anonymous token in cookie when user has opted out

[eunjae-lee]

Summary

This PR follows userHasOptedOut a step further.
Even with userHasOptedOut: true, search-insights created anonymous user token and stored it in the cookie, which is totally not used at all. (I'm not talking about the possibility of that customers could've read that cookie directly for some reason)

In my opinion, this shouldn't be treated as a breaking change. What do you think?

---

ps. I put the people I recently talked about this with as reviewers.

[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 b13c0ac:

Sandbox	Source
Vanilla	Configuration

[Haroenv]

I think it makes sense, although we might need to change opt out to opt in in the next major

[tkrugg]

From my perspective, this does not break any feature because the library does nothing with the content of the cookie when passed userHasOptedOut: true. Is the cookie still used by InstantSearch with Insights ?

[eunjae-lee]

From my perspective, this does not break any feature because the library does nothing with the content of the cookie when passed userHasOptedOut: true. Is the cookie still used by InstantSearch with Insights ?

Hey @tkrugg , this cookie is still read by InstantSearch with Insights (but not written).

By the way, we need to think a little more about InstantSearch side, because so far we already assumed we always have a token because of anonymous user token. However now there could be really nothing, meaning

hasUserOptedOut: true
+
no explicit token setting

will make a hole. We should prevent events being sent with no token and alert the devs via warning messages and docs. Does it make sense? @Haroenv @francoischalifour @tkrugg

[Haroenv]

yes, we should not send when there's no user token, nor anonymous one and error in development for that case

[francoischalifour]

@eunjae-lee Makes sense to me.

[tkrugg]

By the way, we need to think a little more about InstantSearch side, because so far we already assumed we always have a token because of anonymous user token. However now there could be really nothing, meaning

hasUserOptedOut: true
+
no explicit token setting

will make a hole. We should prevent events being sent with no token and alert the devs via warning messages and docs. Does it make sense? @Haroenv @francoischalifour @tkrugg

Hey @eunjae-lee this isn't quite clear to me yet.
When hasUserOptedOut: true, we already are in a situation where events cannot be sent.
Also, an error is thrown when userToken was not supplied. So I wouldn't worry about the case you're highlighting.

FYI documentation is being updated to reflect this change here: algolia/doc#5053.

[eunjae-lee]

@tkrugg oh you're right 🤦🏻‍♂️ Thank you!