Add ability to `JSON.parse` function to specify the return type

[ahmedkamalio]

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]

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]

@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]

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]

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

[cpplearner]

I think this is what a type assertion is for.

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

[hejkerooo]

@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]

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

[ahmedkamalio]

@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]

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

There's already a place to put that:

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

[ahmedkamalio]

@RyanCavanaugh you're right 😅