Skip to content
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

feat: add overide to get all impression events #121

Merged
merged 5 commits into from
Oct 10, 2022

Conversation

ivarconr
Copy link
Member

@ivarconr ivarconr commented Oct 10, 2022

Make it possible to enable impression data for all isEnabled / getVariant calls. This PR also introduces a "impressionData" flag to the event itself, so the implementer can choose to discard events when we do not know whether impressionData is enabled for this toggle.

The reason we need this override in the proxy-sdk is that it simply does not know anything about disabled toggles (by design, to not leak information to the end-user about toggles). This makes it impossible to get impression data for disabled toggles, as they are not exposed to the frontend at all.

Todo:

  • Add documentation for the new config property
  • Add unit tests forimpressionDataAll

Copy link
Contributor

@thomasheartman thomasheartman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the direction this is going in and think it makes a lot of sense 😄

I wonder whether reducing impressionData to a boolean is a good idea, though. It's actually one of three states, so using a boolean, you lose information:

  1. Toggle is enabled and has impressionData enabled
  2. Toggle is enabled and does not have impression data enabled
  3. Toggle is disabled, so we don't know.

Would it be better to model it as boolean | "unknown" or something?

README.md Outdated Show resolved Hide resolved
@@ -33,6 +35,7 @@ class EventsHandler {
context: IContext,
enabled: boolean,
featureName: string,
impressionData: boolean,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to use a name like impressionDataEnabled instead? It might make the name slightly clearer (seeing as it's a boolean and not actual impression data). Happy to be overruled here, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jeah I think it would be better, but I just wanted top keep it the same as the featureToggle property, which currently is "impressionData".

Wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm open to either. As long as we've considered the option, I'm happy for you to make a decision on it ☺️ I see how keeping it the same as the toggle property makes sense, but I personally think it makes it clearer to use impressionDataEnabled or even impressionDataEnabledForFeature. It could cause some confusion when handling an impression data event that you also have a subproperty called impressionData, so I'm leaning towards being more explicit here.

Comment on lines +1158 to +1184
test('Should call getVariant event when impressionData is false and impressionDataAll is true', (done) => {
const bootstrap = [
{
name: 'impression-variant',
enabled: true,
variant: {
name: 'disabled',
enabled: false,
},
impressionData: false,
},
];

const config: IConfig = {
url: 'http://localhost/test',
clientKey: '12',
appName: 'web',
bootstrap,
impressionDataAll: true,
};
const client = new UnleashClient(config);
client.start();

client.on(EVENTS.READY, () => {
const isEnabled = client.getVariant('impression-variant');
expect(isEnabled).toBe(true);
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no test for whether impressionData events are returned when a toggle is false but impressionDataAll is true: is that supposed to have the same behavior?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I should add a test case for this as well. I did it for getVariant.

Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
@ivarconr
Copy link
Member Author

I like the direction this is going in and think it makes a lot of sense smile

I wonder whether reducing impressionData to a boolean is a good idea, though. It's actually one of three states, so using a boolean, you lose information:

  1. Toggle is enabled and has impressionData enabled
  2. Toggle is enabled and does not have impression data enabled
  3. Toggle is disabled, so we don't know.

Would it be better to model it as boolean | "unknown" or something?

You make a strong argument here. We could make the impressionData property optional and only include it when the toggle definition exists. This would work in js environments anyway as we have the undefined as falsy behavior.

@thomasheartman
Copy link
Contributor

@ivarconr Yeah, I think using boolean | undefined would work fine too. That does cover the use cases, though it makes it possible to "forget" to add it. When we make it required, you have to provide a value, which may prevent hard-to-spot bugs in the future 💁🏼

@ivarconr
Copy link
Member Author

ivarconr commented Oct 10, 2022

boolean | "unknown"

this will only work if the user of this SDK also uses typescript. The only alternative is to use string values, which feels a bit verbose in this use case. I think the only reason to enable this flag is that you really want impression events for all, and optionally have your own whitelist for what to actually store.

@thomasheartman
Copy link
Contributor

Yeah, alright, I can buy that 😄

Copy link
Contributor

@thomasheartman thomasheartman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! 🚂 We should make sure to update the Impression data docs for this too 🤓

@ivarconr ivarconr merged commit de4131c into main Oct 10, 2022
@ivarconr ivarconr deleted the feat/impression-data-all branch October 10, 2022 17:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

2 participants