Skip to content

Conversation

@ccnixon
Copy link
Contributor

@ccnixon ccnixon commented Apr 9, 2019

Add a types file to make the module compatible with TS programs.

@ccnixon ccnixon requested a review from ucarion April 9, 2019 01:10
@codecov-io
Copy link

codecov-io commented Apr 9, 2019

Codecov Report

Merging #117 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #117   +/-   ##
=======================================
  Coverage   99.21%   99.21%           
=======================================
  Files          12       12           
  Lines         507      507           
  Branches      162      162           
=======================================
  Hits          503      503           
  Misses          4        4
Impacted Files Coverage Δ
lib/track.js 98.4% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff1f320...9350f24. Read the comment docs.

@ccnixon ccnixon force-pushed the add-typefile branch 3 times, most recently from 5efdb22 to 1b82ab6 Compare April 12, 2019 18:58
@ccnixon ccnixon requested review from f2prateek and fathyb April 12, 2019 18:59
@f2prateek
Copy link
Contributor

Can we re-use docs from the JS implementation? It looks like a lot of it is duplicated - which might cause them to go out of sync.

index.d.ts Outdated
* for. Casing does not matter.
* @return {Object|undefined}
*/
options(integration?: string): object | void
Copy link
Contributor

Choose a reason for hiding this comment

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

why void? can object be undefined?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep I think you're right though honestly it's tough to tell in that function.

/**
* Get `groupId` from `context.groupId`.
*/
groupId(): unknown
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this always be a string?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No it just returns the value of the groupId property. Technically this could be anything the customer wants though it is usually a string.

/**
* Get `sessionId / anonymousId`.
*/
anonymousId(): unknown
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, should this always be a string?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It should be a string but it could be anything. Users have sent numbers here before.

* Interesting values of `type` are `"ios"` and `"android"`, but other values
* are possible if the client is doing something unusual with `context.device`.
*/
device(): unknown
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be object instead of unknown?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes actually it looks like this is guaranteed to be an object.

*/
device(): unknown
/** Get the User-Agent from `context.userAgent`. */
userAgent(): unknown
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be string?

Copy link
Contributor

@f2prateek f2prateek left a comment

Choose a reason for hiding this comment

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

there are a lot of files marked unknown - is that intentional?

@ccnixon
Copy link
Contributor Author

ccnixon commented Apr 12, 2019

Hey @f2prateek - yeah I intentionally put those as unknown. The library doesn't actually ensure that return types adhere to our spec (except in some cases). We should communicate this to the end user to ensure defensive coding.

@ccnixon
Copy link
Contributor Author

ccnixon commented Apr 12, 2019

My thinking is that we shouldn't use our spec to define the return types if we can't guarantee it. This will make it painful to use with TS but I think we should solve it with tooling rather than just hope that the return value is what our spec says.

@f2prateek
Copy link
Contributor

If almost all the return types are unknown, what value does this offer (over the non-typed JS that we currently have)?

@ccnixon
Copy link
Contributor Author

ccnixon commented Apr 12, 2019 via email

@ccnixon ccnixon merged commit 349a7be into master Apr 22, 2019
@ccnixon ccnixon deleted the add-typefile branch April 22, 2019 20:35
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.

4 participants