I understand what issue you're talking about. But here again, the problem is not with noUncheckedIndexedAccess, but with index signatures. If you explicitly annotate all keys, there won't be such an error. Here is the same playground but this explicit keys.
In my article, I repeatedly mentioned that the index signature is a bad thing 😁
Yes, indeed.
If you have been using the strict option in TypeScript, applying additional stricter options may not introduce many new errors.
However, for types like Array or Record, there are clear use cases, and it's not accurate to categorize them as inherently bad.
For instance, I found type casting cumbersome in cases like the code below to eliminate errors.
Just dropping my 2 cents, the possible undefined problem of the aforementioned record can be solved by an explicit cast in the value lookup, it's just that both the object and its key need to be casted.
Hey @bwca !
Thank you for sharing your approach to solving the problem!
I believe it's challenging to assess it solely based on this small code snippet. In real projects, everything can be significantly different 🥲
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey @artxe2 !
I think the issue lies more in the
for...of
/for...in
loop, as it returns a string for akey
variable. If you typecast it, everything will be fine 🙂The solution you provided might not resolve the issue.
TS Playground
Oh, I see.
I understand what issue you're talking about. But here again, the problem is not with
noUncheckedIndexedAccess
, but with index signatures. If you explicitly annotate all keys, there won't be such an error. Here is the same playground but this explicit keys.In my article, I repeatedly mentioned that the index signature is a bad thing 😁
Yes, indeed.
If you have been using the strict option in TypeScript, applying additional stricter options may not introduce many new errors.
However, for types like Array or Record, there are clear use cases, and it's not accurate to categorize them as inherently bad.
For instance, I found type casting cumbersome in cases like the code below to eliminate errors.
Agreed!
In general, as always, it depends on the situation 😁
Just dropping my 2 cents, the possible
undefined
problem of the aforementioned record can be solved by an explicit cast in the value lookup, it's just that both the object and its key need to be casted.Though the case seems rather artificial, as you'd probably be using
.values
or.entries
:PHey @bwca !
Thank you for sharing your approach to solving the problem!
I believe it's challenging to assess it solely based on this small code snippet. In real projects, everything can be significantly different 🥲