-
Notifications
You must be signed in to change notification settings - Fork 83
feat(track): Introducing easy event tracking #207
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
Conversation
1 similar comment
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.
Nothing blocking here, just some questions.
* @param {string} eventKey | ||
* @returns {boolean} | ||
*/ | ||
eventWithKeyExists: function(projectConfig, eventKey) { |
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 more of a question. Why did we decide to start passing projectConfig
to an instance of projectConfig
.
Is doing this.eventKeyMap
bad?
Also do you think it makes more sense to use the existing projectConfig.getEventId
and check the existence vs adding a new API method.
FWIW, I re-wrote projectConfig and use the API method getEventByKey
and that's enough for event creation
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.
That's a fair question. Maybe there should be a project config class instead of having all these functions accept a projectConfig
. In other SDKs it's done this way. I was following convention here and didn't think much about it.
I think using getEventId
is a little less clear than adding a new method, but don't feel strongly about 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.
Yeah not married to this pattern. I'd support refactoring this class to house those functions eventually.
eventKey)); | ||
return; | ||
if (!projectConfig.eventWithKeyExists(this.configObj, eventKey)) { | ||
throw new Error(sprintf(ERROR_MESSAGES.INVALID_EVENT_KEY, MODULE_NAME, eventKey)); |
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.
Another question: is giving an invalid eventKey
actually an error?
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.
Another fair question that I wasn't considering here. It was being treated as an error previously, and I don't want to change that behavior as part of this PR.
@@ -57,6 +57,7 @@ function getCommonEventParams(options) { | |||
client_name: options.clientEngine, | |||
client_version: options.clientVersion, | |||
anonymize_ip: anonymize_ip, | |||
enrich_decisions: true, |
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.
How did we come to the conclusion of using a config in data payload.
I'm guess I'm fine with it, it just seems kind of the wrong place to put it. This seems like something "meta" to the event, like it should go in a header or query param. I get that putting it in a header or query param is probably tough given the architecture of EventDispatcher
.
Wondering the thoughts on this.
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.
For me it was only about the current EventDispatcher not supporting headers or query params, as you said. I agree about using a header being more appropriate and would support that going forward.
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 agree header or QS is more appropriate. We'd need the logtier to be able to handle it though. Have we discussed these alternatives with em?
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.
@mikeng13 Yea, we have discussed with logtier, and they are on board with this.
var snapshot = { | ||
decisions: [], |
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.
is it okay to completely remove decisions
vs keeping it as an empty array.
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.
Yea, the API will treat no decisions the same as an empty decisions array.
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.
Changes look good. @jordangarcia and @mikeng13 should take a look as well.
nit. You should update copyright year in every file that you are updating. |
@@ -57,6 +57,7 @@ function getCommonEventParams(options) { | |||
client_name: options.clientEngine, | |||
client_version: options.clientVersion, | |||
anonymize_ip: anonymize_ip, | |||
enrich_decisions: true, |
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 agree header or QS is more appropriate. We'd need the logtier to be able to handle it though. Have we discussed these alternatives with em?
* @param {string} eventKey | ||
* @returns {boolean} | ||
*/ | ||
eventWithKeyExists: function(projectConfig, eventKey) { |
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 not married to this pattern. I'd support refactoring this class to house those functions eventually.
@@ -34,7 +34,6 @@ module.exports = { | |||
forEach: require('lodash/forEach'), | |||
forOwn: require('lodash/forOwn'), | |||
map: require('lodash/map'), | |||
reduce: require('lodash/reduce'), |
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.
Good riddance!
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.
lgtm
Triggered tests for this branch: https://travis-ci.com/optimizely/fullstack-sdk-compatibility-suite/builds/97304511 |
All tests passed: https://travis-ci.com/optimizely/fullstack-sdk-compatibility-suite/builds/97304511 |
Summary
Updates track method and event builder to support easy event tracking.
Test plan