Conversation
8211525
to
1d68f56
Compare
/** | ||
* Default to `undefined` on the client and let client side | ||
* SSR state hydration pull the SSR generated ID into the client. | ||
* This way we avoid generating any spurious IDs on the client. | ||
*/ | ||
usageSessionId: process.server ? uuidv4() : undefined, |
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.
🔥 🔥 🔥
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.
This definition of a 'session' should be fine for some time and the new types are great.
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.
Very interesting to read about the approach.
/** | ||
* @param {object} props | ||
* @param {string} props.query | ||
* @param {unknown} props.resultRank |
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.
This type can be set to a number because it's a result of a findIndex
call: https://cs.github.com/WordPress/openverse-frontend/blob/af82bcd215933032fd3c557495bd32d41866b44d/src/store/media.js#L170
}) | ||
|
||
afterAll(() => { | ||
// avoid polluting other tests that might be affected by these flags |
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.
Nice cleanup and comment of why it's necessary, especially for future use and copying :)
97c522b
to
6e165c2
Compare
Fixes
Fixes #791 by @zackkrida
Description
I ended up choosing not to go with the
localStorage
orsessionStorage
approaches primarily because those are confined to the client side of the application, meaning that any events happening during the SSR rendering of a page would be impossible to tie to a specific session.In the linked issue I proposed a solution for being able to tie session IDs together on the analytics server side, essentially by treated each new one generated by the server that is replacing an ID the client already held in session storage as a node in a linked list (the client would be able to create a link between the previous session ID and the new one). That would have the benefit of creating a longer lived session ID than the ephemeral one we have in this PR while still maintaining the basic browser definition of session storage, because if the client doesn't have an ID in session storage then it wouldn't be able to create the link between the previous ID and the new one the server generates.
In any case, I don't know if that level of complexity is necessary yet as we're not even really using the analytics data in any detailed way at the moment as far as I know. The primary goal here, at least in my view, is to be able to continue gathering some analytics data (once we turn the feature back on in production) while still eliminating the cookie that is currently being used.
In the future if we decide we do want that broader full-session ID chain then we can work on an RFC for how to implement that. It will require coordination between the frontend and API to make the changes.
Testing Instructions
Checkout the branch and run
pnpm dev
. Load the site and ensure analytics requests are sent as expected with a single session ID between the server and client sides of the application.Checklist
Update index.md
).main
) or a parent feature branch.Developer Certificate of Origin
Developer Certificate of Origin