Return Types vs Inference #typescript

[Novascrub]

If I return a wider type, I am not lying. I am preventing consumers from depending on my implementation instead of the contract. The contract leaves me room to tweak my implementation. Inferred types may not.

[danielvalenzuela]

Conceptually, specifying a type makes sense to me. It forces me think about how I want this function to work. To think about the function as a black box, where I get something and I return something else. How I accomplish it is second to how that function is an important piece of a big machine.

[classic-]

After working on large scale projects with multiple teams I would say hands down always add as much types as you can cause it reduces the type lookup ts has to do to provide intellisence for your code. In small project it really doesn’t matter

[richmerch]

If I'm creating a library, I tend to add the return type. But if I'm just creating a helper function that formats a string for example, I don't bother.

[istarie]

I think some people rely too much on editor based features and forget that some approaches are meant to help readability and avoid common mistakes. By specifying the return type I'm making a contract that the function should return that and if it doesn't so I'll get a compile error. Read the return type is also much better than hovering to see it, in my opinion.

[evanbelcher]

Specifying a type is a must for any library / public api. For private functions, I usually still specify if it's a complicated function as it's a nice sanity check that your function is returning what you think it is, especially if you're writing the type before you implement the function. For simpler functions, I usually skip it

[steamerk]

Explicit return types are most helpful when a function conditionally chooses among multiple return statements. The declaration can help ensure they're all consistent at the appropriate level of abstraction. I definitely add them whenever the system infers a type I didn't expect/intend.

I'd say I use inferred return types for ~98% of functions, though. It just reduces the mechanical cost of maintaining the codebase and doesn't really hurt quality of you've got the right 2% covered.

[BeeBeeEight]

Yes, I agree that it depends. Flexibility is king. Even Rust's (very intelligent) compiler doesn't always require the programmer to specify the return type, so long as the function's parameter types are specified consistently - and Rust's types are much more specific than JavaScript's.

[duongphuhiep]

lets TS infer the return types means that you don't really know (or care) about the shape of your output.. But if you do (and care) then avoid to rely on TS Inferences, explicitely create types for the return result is not that time-consuming.. with plenty of benefits, especially for long run.

[anhdunghisinh]

I usually make return types if the function return a fresh new object with multiple properties that its type have never been declare before.

It helps me managing which properties are being used, which one aren't, so that i can trim down the logic when i don't need those code anymore.

I also use return type if the type of value being return are really messy due to it was form up by a complicated union type.

[monastyrskiiden]

My personal preference is that if you write a library that other people will consume, you should always provide a return type. It's a contract and a reminder for your future self, ensuring that the function returns the expected value, thereby preventing accidental changes to the return type during refactoring or implementation of new features. If you write an application that only consumes code from other libraries and APIs you may avoid the return type because you already know what the return type, and by avoiding it, you give yourself better flexibility in changing code later on. We've all been there, when requirements change so fast that you have to constantly rewrite things and change their contract. Types should not slow you down, or stand in your way they should help you avoid mistakes.

[robertsandiford]

Also if your function just wraps another function it's duplicated work, annoying if the inner function changes.

[AntonioSantana-llil]

I think it dependes, as You said, make a lot of sense in apps that use react . I am an angular developer, since we don't usually return components it is really helpful to always specify the returned object type of a function. Makes easier to maintain the code and even refactor it since You know no matter the Magic You make inside of the funcion You know what it should return

[rumble_bird]

My take on this is when you return an object and `satisfies` keyword applies to this case, then you should add a return type instead of using `satisfies`. For example when you return POJO from a function.

On the contrary when you return value which is either created with `new` or return from other function with a known return type or trivially inferable named one, you shouldn't.

[goodboyneon]

I let typescript infer it most of the time, and only explicitly specify a return type when I can define a type more specific than the inferred one (ex. number[] vs any[]). HOWEVER, I do always explicitly set a return type when writing library code

[tylim]

Unless your type logic is complicated, Infer is better because machine almost always more accurate and precise than human.

The notable issue with inference is it is slower

[CapsAdmin]

When the return type is complex and has reached some guarantee that it won't change in the future, I tend to solidify the return type.

Otherwise, I prefer it to be inferred.

[pupfriend]

I only add return types when it returns void.

[juanparadox]

I've always gone with the thought that writing less types in TypeScript and letting TypeScript do what it does best is the way to go. So, no, I don't set return types. Inference is preferable imo.

[andrewjarrett]

This strikes me as disingenuous.

A linter doesn’t force people to do anything. It just makes doing the wrong thing a little bit harder.

You could have easily framed this discussion the other way around and said

“Should we have guardrails, or should we let anyone do whatever they want whenever they want?”