-
Notifications
You must be signed in to change notification settings - Fork 137
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
chore: deduplicate subsequent identify calls #1649
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Size Change: +3.46 kB (+0.11%) Total Size: 3.24 MB
ℹ️ View Unchanged
|
@@ -306,7 +307,7 @@ export class PostHog { | |||
this.analyticsDefaultEndpoint = '/e/' | |||
this._initialPageviewCaptured = false | |||
this._initialPersonProfilesConfig = null | |||
|
|||
this._cachedIdentify = null |
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.
was trying to decide if we should store this in local storage but i think i prefer this isn't cached outside of memory...
i'm not super familiar with identify and person processing so this feels like a safe step to take to test the waters
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.
Yeah was also thinking about that, the current implementation helps in SPA setups, but hard page reloads would only be fixed by local storage...
src/posthog-core.ts
Outdated
// If the distinct_id is not changing, but we have user properties to set, we can go for a $set event | ||
this.setPersonProperties(userPropertiesToSet, userPropertiesToSetOnce) | ||
if ( | ||
this._cachedIdentify !== |
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.
i think it's ok to do this as an effectively "breaking change"... folk might be depending on the $set
for duplicate identify calls but that'd be surprising to me
and we could always add an opt-out option if people ask for it 🤔
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.
Hopefully, it should be okay, since we were already ignoring duplicate identify calls without properties. But in reality, few people make identify calls without properties so it's possible someone does rely on this behaviour...
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.
brain dumped from a quick scan... i've not really worked with identify so haven't thought about whether we should 🙈
Often duplicate $identify calls are made due to the SDK being incorrectly setup in the app, or due to re-rendering of providers.
The current behaviour is to only deduplicate $identify calls with no properties, but most $identify calls include properties like email, so they are not deduplicated. This PR extends deduplication to calls with properties.
Note: this is my first contribution to js sdk so would appreciate a thorough review.
...
Checklist