Skip to content

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

Merged
merged 4 commits into from
Jan 15, 2019

Conversation

mjc1283
Copy link
Contributor

@mjc1283 mjc1283 commented Jan 9, 2019

Summary

Updates track method and event builder to support easy event tracking.

Test plan

  • Unit tests: updated, and and added new ones
  • Compatibility suite tests
  • Manual testing

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.06%) to 97.198% when pulling b847a65 on mcarroll/easy-event-tracking into 7fe2e0e on master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.06%) to 97.198% when pulling b847a65 on mcarroll/easy-event-tracking into 7fe2e0e on master.

@coveralls
Copy link

coveralls commented Jan 9, 2019

Coverage Status

Coverage decreased (-0.06%) to 97.217% when pulling 1b87b08 on mcarroll/easy-event-tracking into 9812af8 on master.

Copy link
Contributor

@jordangarcia jordangarcia left a 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) {
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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));
Copy link
Contributor

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?

Copy link
Contributor Author

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,
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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: [],
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@aliabbasrizvi aliabbasrizvi left a 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.

@aliabbasrizvi
Copy link
Contributor

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,
Copy link
Contributor

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) {
Copy link
Contributor

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'),
Copy link
Contributor

Choose a reason for hiding this comment

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

Good riddance!

Copy link
Contributor

@mikeproeng37 mikeproeng37 left a comment

Choose a reason for hiding this comment

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

lgtm

@aliabbasrizvi
Copy link
Contributor

Triggered tests for this branch: https://travis-ci.com/optimizely/fullstack-sdk-compatibility-suite/builds/97304511
Looks like we need to look at 2 tests.

@aliabbasrizvi
Copy link
Contributor

@aliabbasrizvi aliabbasrizvi merged commit fe6916f into master Jan 15, 2019
@aliabbasrizvi aliabbasrizvi deleted the mcarroll/easy-event-tracking branch January 15, 2019 01:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants