Nice explanation and code examples. I still think you should ditch jsdoc though 😜 that said... Array reducers are the only time I dislike typescript... It always produces a type collision between the initial value for the reducer and the current value, so you always have to give the initial value an explicit type, instead of relying on type inference, which I prefer, because having to make changes in explicit typing (when they aren't for data models) sucks imho. Not sure if it would be technically possible for typescript to infer the type from the return value of the reducer function though... Probably not.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Hahaha I prefer TS unless it's a quick script tbh, but IRL there are so many projects without TS that I feel like necessary to spread a bit of JSDoc (it makes it a lot easier to migrate JS to TS).
Type inference would be possible I guess but when you have functions that return different types then it will be a mess, I can imagine something like:
userAge is a number, then you calc the amount of years he needs to work before he can retire, which can also be a number, everything OK here, then you cast this number as string inside the email body so the return type is not a number anymore but a string, and so on and so forth.
Hence I assume that even if TS tried, most of the time it could be wrong idk 😅
Some comments have been hidden by the post's author - find out more
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.
Nice explanation and code examples. I still think you should ditch jsdoc though 😜 that said... Array reducers are the only time I dislike typescript... It always produces a type collision between the initial value for the reducer and the current value, so you always have to give the initial value an explicit type, instead of relying on type inference, which I prefer, because having to make changes in explicit typing (when they aren't for data models) sucks imho. Not sure if it would be technically possible for typescript to infer the type from the return value of the reducer function though... Probably not.
Hahaha I prefer TS unless it's a quick script tbh, but IRL there are so many projects without TS that I feel like necessary to spread a bit of JSDoc (it makes it a lot easier to migrate JS to TS).
Type inference would be possible I guess but when you have functions that return different types then it will be a mess, I can imagine something like:
userAge is a number, then you calc the amount of years he needs to work before he can retire, which can also be a number, everything OK here, then you cast this number as string inside the email body so the return type is not a number anymore but a string, and so on and so forth.
Hence I assume that even if TS tried, most of the time it could be wrong idk 😅