About no-unnecessary-type-parameters rules in JSON parse function #11060
Closed
richex-cn
started this conversation in
Technical Discussions
Replies: 1 comment
-
Interesting question. What you're asking for is still not safe: interface User { name: string }
localStorage.setItem('key', JSON.stringify('not a user 😈'));
parseJSON('key').name.toUpperCase(); When using a "parse this unknown raw data" API like
Btw, we reserve the Technical Discussions category for:
This is a rule-specific feature or documentation suggestion, not a deeper architecture or API one. I'm going to go ahead and close it out. Thanks for filing though! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Body
I prefer to follow as many rules as possible without closing them, in order to better ensure the robustness of the code, so this discussion is based on the premise of not closing this rule.
When I enabled the strictTypeChecked rule and encountered this issue in a JSON parse function, There is codes:
If you want to follow the rules, you must use
as
to determine the type when calling the function:However, it is not guaranteed that all developers will not miss
| null
when calling functions, so sometimes this code may appear:Most importantly, the return value here may be null but ESLint cannot detect this type error.
So I wonder if it's possible to add some options or allow this case?
For example, when the return value extends a type parameter, it is not considered an error? In the above example, the type parameter T is only used once, but the function return value is modified to
T | null
is no longer considered an error at this time.Additional Info
Any additional info...
Before you submit your discussion, please confirm the following. If any of these required steps are not taken, we may not be able to review your RFC. Help us to help you!
Beta Was this translation helpful? Give feedback.
All reactions