Better a function that works in some cases than not having a function at all. Also, by using TypeScript definitions you pretty much always know what's coming in and going out and VS Code will yell at you if you're trying to do something stupid.
This blog post explains why what you’re proposing is dangerous: https://jakearchibald.com/2021/function-callback-risks/#type...
When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ...
It also defends / insulates against more parameters being added in the future.
Additionally, the way `this` in javascript works (or doesn't for a lot of callbacks) also pushes against using eta-reduction.
Sure, it's a valid way of logging all the arguments that pass through forEach. I don't see a problem here?
>When using eta-reduction in Javascript both functions and all their (optional) arguments have to be known by the programmer and future programmers, instead of needing to know only the argument-slots being used by (x,y,...) => ...
My VSCode setup shows all arguments of functions automatically. Also, I always avoid optional arguments in my code and writing functions that take in a variable amount of arguments or arguments of different types. I always refactor these out of my codebase.
>Additionally, the way `this` in javascript works (or doesn't for a lot of callbacks) also pushes against using eta-reduction.
`this` is another smell that I always avoid using in my codebase, and refactor code that uses it to work without `this`. I thought `this` being harmful is common knowledge?
["1","2"].map(parseFloat) // works as expected
["1","2"].map(parseInt) // nopeconst arr = ['1','2','3']; arr.map(parseInt) is equivalent to: [ parseInt('1', 0, arr), parseInt('2', 1, arr), parseInt('3', 2, arr) ];