I generally avoid using the any type, so, in that case I would type it like so:
function foo(): () => string {
return 'bar';
}
Same goes for arguments.
I see many gifted devs default to any a lot when they're first getting into TypeScript. I think that is fine as a start, but as a goal I would want to have the proper types for arguments/return values.
I think a heavy use of any generally indicates a lack of clarity about your program, and if you have a lack of clarity than anyone who works on the code after you will be even more unclear.
Why don't you know what the types are? And how can you better figure them out?
Good Point , whenever we are writing code we should be very sure of the input and output , which leads to clarity of logic as well as a good code-base , simple to read and simple to extend. When I started coding I was very poor about making this decision , but overtime I have learned that even if you cannot adhere to strict types in early phase , you must make sure to correct those things in self-review and make it a part of the code writing to be very clear about all the possible input and outputs.
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.
Is there a type that corresponds to
() => any? Is it interchangeable withFunction?Good question. There is no
functiontype. When annotating types for a function, you must specify the types of the parameters and the return values.You could type a function like that:
I generally avoid using the
anytype, so, in that case I would type it like so:Same goes for arguments.
I see many gifted devs default to
anya lot when they're first getting into TypeScript. I think that is fine as a start, but as a goal I would want to have the proper types for arguments/return values.I think a heavy use of
anygenerally indicates a lack of clarity about your program, and if you have a lack of clarity than anyone who works on the code after you will be even more unclear.Why don't you know what the types are? And how can you better figure them out?
Good Point , whenever we are writing code we should be very sure of the input and output , which leads to clarity of logic as well as a good code-base , simple to read and simple to extend. When I started coding I was very poor about making this decision , but overtime I have learned that even if you cannot adhere to strict types in early phase , you must make sure to correct those things in self-review and make it a part of the code writing to be very clear about all the possible input and outputs.