Note that Object.entries also returns keys as strings (and not keyof T), just like Object.keys does. It has the exact same problem and rationale as explained in this article. This means that if you just want to loop, you’re good, but the moment you need something fancier than a console.log you might need the keys to be typed stronger again.
In many cases though, you only need a correctly-typed key in order to index into the object to get the value -- if you've already got the value, you're fine. And if you need to limit yourself to keys that are defined on the type you're using (rather than arbitrary keys which might exist on the object at runtime) then you need to check anyway.
It has some of the same problems. It doesn't have the problem of being unable to read obj[key] because typescript doesn't realize it's the same object.
And according to the article, the issue isn't that TS doesn't realize it's the same object, it's that the object might have more keys than what is declared in your interface.
Perhaps what you meant to say is that you can directly use `val` instead of `obj[key]`.
> And according to the article, the issue isn't that TS doesn't realize it's the same object, it's that the object might have more keys than what is declared in your interface.
The main issue at hand was inability to use `options[key]`.
"the object might have more keys" was a possible issue, and was the reason typescript was blocking access to `options[key]`, but it wasn't the main problem.
> It has that same problem actually:
> Perhaps what you meant to say is that you can directly use `val` instead of `obj[key]`.
How is that different from what I said?
Because you can directly use `val`, and because that's better than `obj[key]` anyway, you "don't have the problem of being unable to read obj[key]".
I tend to avoid map and filter unless the code I'm writing can be naturally expressed using them. I almost never use reduce. Sum of a list is one of the few reasonable use cases. I've seen some horrific reduce code that's working very hard to avoid an explicit loop.
If I need to count occurrences of each character in a string, I'm using a loop.
Is there a functional rationale for this or more of style thing? I almost never use reduce but I use map and filter (and forEach) everywhere. The syntax of for loops just seems so dirty to me but maybe I just stylistically like the functional / immutable approach to architecting code which is why I use Ramda.
This is exactly the type of code I'm talking about. That spread operator is producing a lot of garbage (in the GC sense) for no real reason. It's just to avoid mutation and a loop.
Although I’m surprised there is no mention of the best solution for iterating both keys and values:
for (const [key, val] of Object.entries(obj)) { console.log(key, val) }
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...