-
Notifications
You must be signed in to change notification settings - Fork 118
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
chore: re-order folder structure for types #4090
base: develop
Are you sure you want to change the base?
Conversation
Allure Test reports for this run are available at: |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #4090 +/- ##
===========================================
+ Coverage 91.12% 91.16% +0.03%
===========================================
Files 631 632 +1
Lines 32944 33112 +168
Branches 7807 7838 +31
===========================================
+ Hits 30021 30186 +165
- Misses 2673 2708 +35
+ Partials 250 218 -32 ☔ View full report in Codecov by Sentry. |
Allure Test reports for this run are available at: |
src/types/controlPlaneConfigSpec.ts
Outdated
Config: FixMe; | ||
}; | ||
|
||
export type Destination<DestinationConfig = FixMe> = { |
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 DestinationConfig type ?
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 dynamic for each specific destination depending on what config is defined in destinationDefinition
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.
Instead of FixMe (which is basically any) can we a bit more context sensitive types?
- unknown
- Record<string, any> ( for object structures ) etc
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.
At the minimum, we can get the table structure of destConfig. As vinay pointed out, FixMe is the one which I want to avoid
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.
addressed
src/types/transformation.ts
Outdated
/** | ||
* Router transformation structures | ||
*/ | ||
export type RouterTransformationRequestData< |
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.
why to define type parameters here ?
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 you elaborate?
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.
why to set these parameters
Message = object,
DestinationType = Destination,
ConnectionType = Connection,
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.
Cleaned
src/types/eventSpec.ts
Outdated
export type MessageIdMetadataMap = { | ||
[key: string]: Metadata; | ||
}; |
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 there are no know keys and all are optional, we should use this to make it more readable and concise
export type MessageIdMetadataMap = Record<string, Metadata>;
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.
Addressed
src/types/transformation.ts
Outdated
export type ProxyV1Request = { | ||
version: string; | ||
type: string; | ||
method: string; | ||
endpoint: string; | ||
userId: string; | ||
headers?: Record<string, unknown>; | ||
params?: Record<string, unknown>; | ||
body?: { | ||
JSON?: Record<string, unknown>; | ||
JSON_ARRAY?: Record<string, unknown>; | ||
XML?: Record<string, unknown>; | ||
FORM?: Record<string, unknown>; | ||
}; | ||
files?: Record<string, unknown>; | ||
metadata: ProxyMetdata[]; | ||
destinationConfig: Record<string, unknown>; | ||
}; |
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.
Maybe instead of duplicating the entire type, we can simplify it like this?
export type ProxyV1Request = Omit<ProxyV0Request, "metadata"> & {
metadata: ProxyMetdata[];
};
This can clearly indicate that the only difference in these 2 times comes from the field metadata
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.
Addressed
Allure Test reports for this run are available at: |
fix these |
Allure Test reports for this run are available at: |
Allure Test reports for this run are available at: |
|
What are the changes introduced in this PR?
This PR cleans up the siloed type definitions that we have in
v0/utils/types/index.ts
and distributes them into appropriate filesWhat is the related Linear task?
Resolves INT-3304
Please explain the objectives of your changes below
Put down any required details on the broader aspect of your changes. If there are any dependent changes, mandatorily mention them here
Any changes to existing capabilities/behaviour, mention the reason & what are the changes ?
N/A
Any new dependencies introduced with this change?
N/A
Any new generic utility introduced or modified. Please explain the changes.
N/A
Any technical or performance related pointers to consider with the change?
N/A
@coderabbitai review
Developer checklist
My code follows the style guidelines of this project
No breaking changes are being introduced.
All related docs linked with the PR?
All changes manually tested?
Any documentation changes needed with this change?
Is the PR limited to 10 file changes?
Is the PR limited to one linear task?
Are relevant unit and component test-cases added in new readability format?
Reviewer checklist
Is the type of change in the PR title appropriate as per the changes?
Verified that there are no credentials or confidential data exposed with the changes.