Skip to content

Add ability to JSON.parse function to specify the return type #30220

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

Closed
5 tasks done
ahmedkamalio opened this issue Mar 5, 2019 · 10 comments
Closed
5 tasks done

Add ability to JSON.parse function to specify the return type #30220

ahmedkamalio opened this issue Mar 5, 2019 · 10 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@ahmedkamalio
Copy link

Search Terms

  • JSON
  • JSON.parse
  • JSON.parse return type

Suggestion

Add the ability to JSON.parse function to specify the return type, I already opened a PR #30219, implementing this feature

Use Cases

let parsedObj = JSON.parse<TypeObj>("{ prop: 'val' }"); // parsedObj is TypeObj

is way better than

let parsedObj = JSON.parse("{ prop: 'val' }"); // parsedObj is any

Examples

that said in the use cases ¯_(ツ)_/¯

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@hejkerooo
Copy link

While JSON.parse returns any, you can simply do
let parsedObj: Interface = JSON.parse("{ prop: 'val' }"); // parsedObj is any

So there will be no difference between adding generic type to JSON.parse and mine "solution"

@ahmedkamalio
Copy link
Author

@hejkerooo here's a real-world example

export const getCurrentUserDataAsync = () => SecureStore.getItemAsync(SESSION_KEY).then(data => data ? JSON.parse<LoginData>(data) : undefined);

How can your solution solve it?

@hejkerooo
Copy link

hejkerooo commented Mar 5, 2019

type ReturnType = LoginData | undefined;
export const getCurrentUserDataAsync = (): ReturnType => SecureStore.getItemAsync(SESSION_KEY).then(data => data ? JSON.parse(data) : undefined);

But you shouldn't return undefined, consider throwing an error or try nullable pattern
Nullable pattern

edit
You should not declare return type basic on what is function returning, but function declaration itself

@ahmedkamalio
Copy link
Author

@hejkerooo so, for a service file that contains about ten methods like this one I'm going to define ten types separately!!!

@cpplearner
Copy link

cpplearner commented Mar 5, 2019

I think this is what a type assertion is for.

JSON.parse(data) as LoginData
// or: <LoginData>JSON.parse(data)

@hejkerooo
Copy link

@hejkerooo so, for a service file that contains about ten methods like this one I'm going to define ten types separately!!!

I think, this is a point of strongly typed languages

@j-oliveras
Copy link
Contributor

Already discussed and rejected as Working as intended: #26993 and #26994.

@ahmedkamalio
Copy link
Author

@j-oliveras but #26994 and #28416 discussing solutions that don't make sense, can you please refer to #30219, see the changes and tell me what you think?!
anyways it's up to the community to decide whether this update is useful or not ¯_(ツ)_/¯

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Mar 5, 2019
@RyanCavanaugh
Copy link
Member

JSON.parse<TypeObj>("{ prop: 'val' }");

There's already a place to put that:

<TypeObj>JSON.parse("{ prop: 'val' }");

@ahmedkamalio
Copy link
Author

@RyanCavanaugh you're right 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants