-
Notifications
You must be signed in to change notification settings - Fork 1
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
[TF-633] Feature: migrate to @segment/analytics-next
package
#1
Conversation
@@ -27,8 +23,11 @@ interface Props { | |||
isEnabled?: boolean; | |||
newsroom: Newsroom; | |||
story: Story | undefined; | |||
plugins?: Plugin[]; |
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 thought it would be a nice feature to allow the package consumers to pass their own plugins, that way they would be able to extend the features without the need to fork the library.
const { analytics, consent, isEnabled, newsroom, trackingPolicy } = useAnalyticsContext(); | ||
const analyticsRef = useLatest(analytics); |
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.
All of the changes to this file were basically about replacing window.analytics
with the analytics
object received from analytics-next
.
// TODO: Prezly Analytics app should be able to take the newsroom UUID from the `prezly` property | ||
writeKey: newsroomUuid, |
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 noticed that in the legacy analytics bundle Newsroom UUID is passed twice: in the prezly
property, and in the writeKey
. This seems redundant, but analytics.prezly.com/track
endpoints are giving 422 error when writeKey
is not present.
I believe this can also be populated with the actual Segment write key, if the integration is enabled for the newsroom, and in that case the event gets passed along to Segment, but this will not be needed anymore with this package.
type: 'application/json', | ||
}); | ||
|
||
navigator.sendBeacon(`${getApiUrl()}${endpoint}`, blob); |
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 is an alternative to fetch
that was made specifically to send analytics data from the browser. The main advantage is that it isn't affected by the user closing the tab - the request would still be fulfilled in the background.
See https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
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.
Curious why we'd opt for sendBeacon and the native analytics-next is not. Is there a caveat?
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 guess it's because it's not supported by IE11: https://caniuse.com/?search=sendbeacon
But since we ditched support for it a while ago, I don't see this as an issue.
@@ -1,213 +1,3 @@ | |||
// https://www.npmjs.com/package/@types/segment-analytics |
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 file used to include the types copied over from the Segment package, now they're not needed anymore.
@segment/analytics-next
package@segment/analytics-next
package
TF-633 Refactor the extracted library to rely on `@segment/analytics-next`
See TF-492 for details on how analytics work on our legacy infrastructure. Key points to keep in mind:
|
// If no Segment Write Key is provided, we initialize the library settings manually | ||
...(!writeKey && { | ||
cdnSettings: { | ||
integrations: {}, | ||
}, | ||
}), |
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 code allows the library to initialize without a working Segment Write Key (it is used to fetch the source configuration from Segment, which we don't need to Prezly-only tracking).
Somehow the tracking calls to Segment API still go through even without authorization. This is handled later in the code.
// Disable calls to Segment API completely if no Write Key is provided | ||
...(!writeKey && { | ||
// eslint-disable-next-line @typescript-eslint/naming-convention | ||
integrations: { 'Segment.io': false }, | ||
}), |
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.
After digging through analytics-next
source code, I found out that the code sending events to Segment is also a plugin (!), that can be disabled. This was an undocumented feature, but it effectively disables any calls to Segment API, while all the other plugins (like sending events to Prezly) still work fine.
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.
Looks good 👍
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'm not in favor of using undocumented features (since there's now less guarantee it'll be around), but sounds like we have a special use case.
💯
analytics.js
bundle fetched from our infrastructure with vanilla@segment/analytics-next
packageanalytics-next
, so no need to patch the codeanalytics.prezly.com
is implemented through the newPlugin
feature ofanalytics-next
Segment.io
integration, meaning that no requests are made to Segment API at all, only toanalytics.prezly.com
Bonus: