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

refactor: Migrate Types Module to TypeScript #950

Conversation

alexs-mparticle
Copy link
Collaborator

@alexs-mparticle alexs-mparticle commented Nov 21, 2024

Instructions

  1. PR target branch should be against development
  2. PR title name should follow this format: https://github.com/mParticle/mparticle-workflows/blob/main/.github/workflows/pr-title-check.yml
  3. PR branch prefix should follow this format: https://github.com/mParticle/mparticle-workflows/blob/main/.github/workflows/pr-branch-check-name.yml

Summary

  • Migrates Types module to TypeScript and refactor to use objects as constants instead of enums.
  • For our usage, using objects as constants offers us the ability to verify we're passing in some server side values rather than just using the correct enum element.
  • For example, treating MessageTypes as a number when making conditional comparisons while at the same time verifying that we are using the correct MessageType constant.

Testing Plan

  • Was this tested locally? If not, explain why.
  • Run automated tests and verify they behave as expected
  • Manually test external interfaces for Types to verify they return as expected

Reference Issue (For mParticle employees only. Ignore if you are an outside contributor)

src/types.ts Outdated
// Dictionary that contains MessageTypes that will
// trigger an immediate upload.
export const TriggerUploadType = {
[MessageType.Commerce]: 1 as const,

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

@alexs-mparticle alexs-mparticle changed the base branch from development to refactor/ts-migration-blackout-2024 November 21, 2024 21:11
@alexs-mparticle alexs-mparticle marked this pull request as ready for review November 21, 2024 21:48
Copy link
Member

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

src/apiClient.ts Show resolved Hide resolved
src/batchUploader.ts Show resolved Hide resolved
MessageType.UserIdentityChange,
] as const;

return !this.batchingEnabled || priorityEvents.includes(eventDataType as typeof priorityEvents[number]);
Copy link
Member

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?

Copy link
Collaborator Author

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.

src/identity-user-interfaces.ts Show resolved Hide resolved
src/identity-user-interfaces.ts Show resolved Hide resolved
UserIdentityChange: 18 as const,
};

export const EventType = {
Copy link
Member

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.

Copy link
Collaborator Author

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+.

src/kitFilterHelper.ts Show resolved Hide resolved
src/sdkRuntimeModels.ts Show resolved Hide resolved
src/types.ts Outdated Show resolved Hide resolved
Comment on lines +386 to +388
export const ProfileMessageType = {
Logout: 3 as const,
};
Copy link
Member

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.

Copy link
Collaborator Author

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).

Comment on lines +390 to +392
export const ApplicationTransitionType = {
AppInit: 1 as const,
};
Copy link
Member

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

Copy link
Collaborator Author

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.

test/jest/types.spec.ts Outdated Show resolved Hide resolved
test/jest/types.spec.ts Outdated Show resolved Hide resolved
test/jest/types.spec.ts Outdated Show resolved Hide resolved
test/jest/types.spec.ts Outdated Show resolved Hide resolved
Comment on lines +383 to +412
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');
});
Copy link
Member

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Copy link
Member

@rmi22186 rmi22186 left a 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

test/jest/types.spec.ts Outdated Show resolved Hide resolved
@alexs-mparticle alexs-mparticle force-pushed the refactor/SQDSDKS-5218-migrate-types branch from 74925d2 to 2cffd75 Compare November 25, 2024 19:50
Copy link

sonarcloud bot commented Nov 25, 2024

@alexs-mparticle alexs-mparticle added wait to merge refactor Changes to the structure of the code labels Nov 25, 2024
@alexs-mparticle alexs-mparticle merged commit 5b0113e into refactor/ts-migration-blackout-2024 Nov 27, 2024
31 of 35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Changes to the structure of the code wait to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants