-
Notifications
You must be signed in to change notification settings - Fork 26
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
Improve types for mocking #3082
Changes from 6 commits
3e8e71a
1fc04a2
5c3745f
fef0713
3bcf351
96ccb7b
728a745
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -306,7 +306,7 @@ function mapKeys(obj: {[key: string]: any}, schema?: Schema): object { | |
continue; | ||
} | ||
remappedObject[newKey] = mappedKeys.length > 1 ? deepCopy(obj[key]) : obj[key]; | ||
const keySchema: Schema & ObjectSchemaProperty | undefined = schema.properties[newKey]; | ||
const keySchema: (Schema & ObjectSchemaProperty) | undefined = schema.properties[newKey]; | ||
const currentValue = remappedObject[newKey]; | ||
if (Array.isArray(currentValue) && isArray(keySchema) && isObject(keySchema.items)) { | ||
remappedObject[newKey] = currentValue.map(val => mapKeys(val, keySchema.items)); | ||
|
@@ -367,7 +367,7 @@ function unmapKeys(obj: {[key: string]: any}, schema?: Schema): object { | |
continue; | ||
} | ||
remappedObject[newKey] = deepCopy(obj[key]); | ||
const keySchema: Schema & ObjectSchemaProperty | undefined = schema.properties[key]; | ||
const keySchema: (Schema & ObjectSchemaProperty) | undefined = schema.properties[key]; | ||
const currentValue = remappedObject[newKey]; | ||
if (Array.isArray(currentValue) && isArray(keySchema) && isObject(keySchema.items)) { | ||
remappedObject[newKey] = currentValue.map(val => unmapKeys(val, keySchema.items)); | ||
|
@@ -380,8 +380,8 @@ function unmapKeys(obj: {[key: string]: any}, schema?: Schema): object { | |
|
||
export function untransformBody(body: any, schema: Schema | undefined): any { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks like we had a bug here compared to what There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How does this manifest itself? Will this break any existing behavior related to 2-way sync? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wasn't able to repro that code path with 2-way sync but I did update one place where we have test coverage here: https://github.com/coda/coda/pull/118340 |
||
if (isArray(schema) && isObject(schema.items)) { | ||
const objectBody = body as Record<string, any>; | ||
const mappedObjs = unmapKeys(objectBody, schema.items); | ||
const objects = body as Array<Record<string, any>>; | ||
const mappedObjs = objects.map(obj => unmapKeys(obj, schema.items)); | ||
return mappedObjs; | ||
} | ||
|
||
|
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.
The
returns
-->resolves
thing seems like the most significant change, would call that out. Will external developers who have written unittests also need to update all usage like you did in thepacks
repo? If so I think we need to pre-announce this and explain how to update things. Clearly what was there before was broken so it's a good change but if it's not backwards-compatible we need to give a heads-up.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.
Yeah, if external developers wrote unit tests that didn't correctly return a promise (but instead returned a value), they'd need to update their tests to also use
resolves
to pass type checks. Functionally these tests still work because our code must in general useawait
rather than attempting to do promise chains with.then()
- the latter would have caused RTEs otherwise.@ekoleda-codaio can you help with the necessary announcement for this change?
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.
@ekoleda-codaio I think the only developer-facing change to announce would be that if somebody previously wrote tests with
newMockExecutionContext()
and they usedcontext.fetcher.fetch.returns(...)
they need to update it to usecontext.fetcher.fetch.resolves(...)
. This should always have been the case but the old behavior was inaccurate considering these are async methods.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.
Thanks for clarifying, I missed this callout. Since tests could only be written with the CLI, and SDK version upgrades are manual and optional for the CLI (compared to the Pack Studio), I think it's fine to release this without an announcement or warning. I also suspect that the number of developers writing tests period is very small, so I expect the blast radius here to be incredibly small. A clear note in the Changelog is likely sufficient, but I can also write up a short community post once the version goes live.
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.
Ok that's fine, let's just go with a more thorough changelog entry.
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.
Ok, updated the changelog.