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

Jsonable to support interfaces #1816

Closed
wants to merge 1 commit into from
Closed

Jsonable to support interfaces #1816

wants to merge 1 commit into from

Conversation

skylerjokiel
Copy link
Contributor

Let Jsonable support interfaces

@@ -26,4 +29,8 @@ export type JsonableArray<T> = Jsonable<T>[];
* - Non-finite numbers (`NaN`, `+/-Infinity`) are also coerced to `null`.
* - (`null` always serializes as `null`.)
*/
export type Jsonable<T = JsonablePrimitive> = T | JsonableArray<T> | JsonableObject<T>;
export type Jsonable<T> = {
[P in keyof T]: T[P] extends JsonablePrimitiveArrayOrObject
Copy link
Contributor

Choose a reason for hiding this comment

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

i just pushed a PR for basically the same thing 😋 check it out #1823

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this might be too loose. Does it fail if an interface isn't jsonable?

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, it covers all the scenarios I could think of

link to all the testing

Copy link
Contributor Author

@skylerjokiel skylerjokiel Apr 17, 2020

Choose a reason for hiding this comment

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

Something something... great minds think alike. lol

I think I like this one because the consumption syntax is much simpler and only uses the one type:

function foo<T extends Jsonable<T>>(a: T): void { 
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

i think we need type recursion to make this work

Copy link
Contributor

Choose a reason for hiding this comment

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

mine fails with that too

Copy link
Contributor

Choose a reason for hiding this comment

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

I approve of both. :-)

Slight preference for end-user ergonomics of the grand unified Jsonable<T>approach, if the results are comparable.

@skylerjokiel
Copy link
Contributor Author

closing on account of Tony's PR #1823

anthony-murphy added a commit that referenced this pull request Apr 20, 2020
This is basically taking advantage of duck typing. We are generating a type we know is jsonable from the input type, but setting anything not serializable to never, which will cause compile time issues with objects of the original type.

related #1816 #136 #363 #364
@skylerjokiel skylerjokiel deleted the jsonable branch April 21, 2020 21:23
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.

None yet

3 participants