Add support for named global context - #1331
Conversation
7f61ff7 to
bcc8a1c
Compare
BundleMonFiles added (6)
Total files change +101.68KB 0% Final result: ❌ View report in BundleMon website ➡️ |
Matus Tomlein (matus-tomlein)
left a comment
Matus Tomlein (matus-tomlein)
left a comment
There was a problem hiding this comment.
I really like the approach and that it is done in a non-breaking way!
I am a bit unsure whether we should keep providing so many ways to configure global context or rather should deprecate the non-named approach and just guide users to name their global context. It makes it more confusing for users if the API supports so many variations. On the other hand, global context is a commonly used feature and making the change non-breaking should speed up the adoption of the v4, so this solution is very tempting.
I must be doing something stupid, but for some reason I don't see the global context entities configured using the named approach in events tracked from a demo React app. I do see the ones configured with the unnamed approach though. This is the way I am adding the context:
// this one doesn't show up in events
addGlobalContexts({
c1: {
schema: "iglu:com.acme_company/page/jsonschema/1-0-0",
data: {
title: "Page 1",
},
},
});
// this one gets tracked in events
addGlobalContexts([
{
schema: "iglu:com.acme_company/page/jsonschema/1-0-0",
data: {
title: "Page 2",
},
},
]);
Do you see anything obvious that I am doing wrong here? I'll give it another shot tomorrow.
|
Nope, that looks fine to me. I can't replicate this issue, it works as expected for both JS tracker and Browser tracker when I build it. 😕 Did you do a full rebuild to get the changes in tracker-core etc? |
Matus Tomlein (matus-tomlein)
left a comment
Matus Tomlein (matus-tomlein)
left a comment
There was a problem hiding this comment.
Sorry, this was my confusion, for some reason I thought that global context was in the browser-tracker-core, not in the tracker-core.
It all works very nicely and is a solid improvement! I am still a bit unsure about having multiple options to do the same thing in the API, but I think we can make the trade-off towards making it easier to upgrade to v4 for users and do a better job in the docs to make sure that people use the named approach.
The `addGlobalContexts` API now accepts an `object` mapping "names" to context primitives or context generators, rather than just an array of "unnamed" global entities/generators. Calling `addGlobalContexts` multiple times with values of the same "name" will overwrite the previous value for subsequent events, allowing "upserting" or updating of global context without having to remove the previous version first and introducing duplicates. `removeGlobalContexts` can now also accept plain strings which are handled as names, so primitives/generators can be removed by name without having to own a reference to the generating function or an object that serializes to the same string.
The `addGlobalContexts` API now accepts an `object` mapping "names" to context primitives or context generators, rather than just an array of "unnamed" global entities/generators. Calling `addGlobalContexts` multiple times with values of the same "name" will overwrite the previous value for subsequent events, allowing "upserting" or updating of global context without having to remove the previous version first and introducing duplicates. `removeGlobalContexts` can now also accept plain strings which are handled as names, so primitives/generators can be removed by name without having to own a reference to the generating function or an object that serializes to the same string.
The `addGlobalContexts` API now accepts an `object` mapping "names" to context primitives or context generators, rather than just an array of "unnamed" global entities/generators. Calling `addGlobalContexts` multiple times with values of the same "name" will overwrite the previous value for subsequent events, allowing "upserting" or updating of global context without having to remove the previous version first and introducing duplicates. `removeGlobalContexts` can now also accept plain strings which are handled as names, so primitives/generators can be removed by name without having to own a reference to the generating function or an object that serializes to the same string.
The `addGlobalContexts` API now accepts an `object` mapping "names" to context primitives or context generators, rather than just an array of "unnamed" global entities/generators. Calling `addGlobalContexts` multiple times with values of the same "name" will overwrite the previous value for subsequent events, allowing "upserting" or updating of global context without having to remove the previous version first and introducing duplicates. `removeGlobalContexts` can now also accept plain strings which are handled as names, so primitives/generators can be removed by name without having to own a reference to the generating function or an object that serializes to the same string.
2 participants
This is a proposal for "named global context"; an update to the
addGlobalContexts/removeGlobalContextsAPIs to allow naming each primitive/generator.Once named, you can remove them by referencing just the name, but you can also upsert the value by adding via the same name again. This allows avoiding gymnastics required by the current API, where to update a primitive you have to have the original value around in order to remove it in order to add it again without creating duplicates.