-
Notifications
You must be signed in to change notification settings - Fork 44
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
refactor: Migrate Types Module to TypeScript #950
refactor: Migrate Types Module to TypeScript #950
Conversation
b6883b6
to
b8a1a8f
Compare
src/types.ts
Outdated
// Dictionary that contains MessageTypes that will | ||
// trigger an immediate upload. | ||
export const TriggerUploadType = { | ||
[MessageType.Commerce]: 1 as const, |
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.
if these are types, should they have the same value 1
?
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 something that probably needs to be refactored. Were using the values as a sort of lookup table in the batchUploader when it might be cleaner to do this as a function instead. But that is likely out of scope for this PR.
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.
After thinking about this, I decided we should probably not be doing this as a "type" but rather as a simple lookup inside the actual BatchUploader module.
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.
Looks great so far. Putting this comments in in time for our sync. Still need to finish going through types.ts and utils.ts, and the tests.
MessageType.UserIdentityChange, | ||
] as const; | ||
|
||
return !this.batchingEnabled || priorityEvents.includes(eventDataType as typeof priorityEvents[number]); |
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 this some sort of TS black magic? shouldn't number
should be defined somewhere, right?
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.
Sort of. number
is actually being used as a type
and not as a variable. This is saying that eventDataType
should be treated as a type of priorityEvent
which is an array of numbers.
This will transpile to priorityEvents.includes(eventDataType)
but allows TypeScript to enforce that eventDataType
is treated as a parameter that is compatible with the members of priorityEvents
.
UserIdentityChange: 18 as const, | ||
}; | ||
|
||
export const EventType = { |
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.
Can we add a Jira here to split getName
from the enums (perhaps a general jira to do that for all of the types here when we are mixing and matching improperly)? i don't think this is necessary for v3 because i'm envisioning V3 as more of a "light" upgrade where the only breaking changes are deprecated methods, then in V4 we break the APIs in 1 fell swoop.
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.
From my conversations with @einsteinx2, it sounds like we may be making some architectural changes to our event translation logic. I think rather than making a ticket for sustained engineering, we should only address this for when we decide on what is actually necessary for v3+.
export const ProfileMessageType = { | ||
Logout: 3 as const, | ||
}; |
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.
small nit. similar to what you did with trigger uploads - since this is only used in the logout call in identity.js
, might be worth moving it over there. or since it's a .js file still, just remembering (or adding a ticket) to move this over there.
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.
My reasoning for moving the Trigger uplooads is because I felt it wasn't really a type
but rather a control that is specific to batchUploader
. In this case, ProfileMessageType
makes more sense (to me) to remain in this file since this file is a collection of our data types (for lack of a better term).
export const ApplicationTransitionType = { | ||
AppInit: 1 as const, | ||
}; |
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 could be moved to serverModel.ts since it's only called there. and that's already a .ts file unlike the identity.js comment above
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.
Same as above. I think this should stay in here since it's a data type.
it('returns other if the identity type is not found', () => { | ||
const { getName } = IdentityType; | ||
|
||
expect(getName(Other)).toBe('Other ID'); | ||
expect(getName(Other2)).toBe('Other ID'); | ||
expect(getName(Other3)).toBe('Other ID'); | ||
expect(getName(Other4)).toBe('Other ID'); | ||
expect(getName(Other5)).toBe('Other ID'); | ||
expect(getName(Other6)).toBe('Other ID'); | ||
expect(getName(Other7)).toBe('Other ID'); | ||
expect(getName(Other8)).toBe('Other ID'); | ||
expect(getName(Other9)).toBe('Other ID'); | ||
expect(getName(Other10)).toBe('Other ID'); | ||
expect(getName(MobileNumber)).toBe('Other ID'); | ||
expect(getName(PhoneNumber2)).toBe('Other ID'); | ||
expect(getName(PhoneNumber3)).toBe('Other ID'); | ||
|
||
expect(getName(NaN)).toBe('Other ID'); | ||
}); |
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 think you uncovered a bug here. all these should probably have an actual Name that's not Other Id. It's likely that the getName
switch statement never was updated after these new IdentityTypes were added.
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.
Created https://go.mparticle.com/work/SQDSDKS-6942 to track
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.
tiny last nits, otherwise LGTM
74925d2
to
2cffd75
Compare
Quality Gate passedIssues Measures |
5b0113e
into
refactor/ts-migration-blackout-2024
Instructions
development
Summary
Testing Plan
Reference Issue (For mParticle employees only. Ignore if you are an outside contributor)