Type your functions in TypeScript and SAVE TIME

Recorded live on twitch, JOIN IN

[SkyKosiner]

I agree with this. Recently I've been looking back on some old typescripts projects I made years ago and having no return types or messy types everwhere it took me ages to understand what each function was doing, and after refactoring them to have clearer types it was so much easier to undesrstand

[hamm]

Exactly. If something looks confusing, it should be refactored to not be. This is a major reason why we have types to begin with - remove mental overhead. If you are adding mental overhead from the types, that should signal you to refactor your code to be manageable in your mental model. The answer isn’t to just pretend that the confusion isn’t there by hiding the confusion in type inference.

Great breakdown.

[Captainlonate]

I strongly agree with adding explicit return types. Sure it helps you write the function initially, but it's main advantage is guaranteeing that when 5 other people mess with that function in the future, that if they accidentally change the returned value, it shows the error IN THE FUNCTION, rather than in the calling code in some other file.

And for projects which are not 100% fully typed (allow the use of implicit any), it's a must. You have to make sure that at least YOUR function is typed and always will be.

[reaper]

A few days ago I saw a video advocating for dropping return times most if the time. I totally agree with your assessment. The more type declaration the better, since it's automatic documentation for the next Developer.

[atla_]

Next TS hot take: DON'T use types in TypeScript, writing without them is so much faster!

[samueldostal]

I like explicit return types more, but the first argument about not seeing return types for old / foreign code is puzzling. You can just look at the return type in your IDE with hover / virtual text LSP feature. Kind of similar to the old C convention of prefixing variable names with its data type, or C# 'I' before interface. I don't think these conventions are used anymore, only because of how powerful IDEs (or text editors) have become. I 100% agree with the other points though

[Richard-spul]

One of my favourites of your videos for a while. How to use types, made the case for why you should use em.

[yoerivanwassenhove]

I like this format. Clear, concise and educational.
Thanks for taking the time to explain your position.

[industry_std]

I didn't even realise this was the second channel!
The live conversation with Theo was actually amazing. I always feel like I'm learning much more when I watch that type of content than any other.

[gubfhidnom]

My flow is define a function (i.e. name, inputs and return type) then implement it. I already know what type I want to return and, by specifying it upfront, the type checker can help me implement the function successfully. Leaving the return type implicit means I'll realise I messed up when trying to _use_ the function, not when _writing_ it.

[snekface]

Thanks for this. Was watching through a typescript course where the guy just implicitly returns everything, and I was second guessing myself (who started off by explicitly typing everything).

[idonoD]

Saw the argument with Theo first before watching this vid. I completely agree that defining return types will improve ones codebase in the long run. Implicit returns can be useful when dealing with inlining functions or factory functions/methods.

A step further is to use function overloading and match input data with the return type. Makes it clearer what role returns what type.

[zeroww]

With generics, you can also have the correct shape returned based on the input which is better than having a union of types where you have to place guards outside the function too.

[stephenpaul]

Darnit you've convinced me.
I had these sort of issues with TRPC. I really like the library but the types are incredibly opaque and inferred to hell and back.
I eventually gave up extracting some common logic because wrangling the types was such a pain. Liberally employing typeof... Paramaters<0>... ReturnType<T>... etc. was exhausting. Also, I think this ties into the Svelte Authors latest preference for writing libs in javascript with a 'facade' of types. Libraries are better tested with unit tests than types and types tend to simply get in the way more that they help. Libraries should rather focus on DX (and that includes well-named types). I would still prefer Typescript for building libs but he's not wrong. I think that explicit return types in applications do make for better DX, and AI tools like copilot know how to autocomplete the return types.

[joerivde]

Love both your channels, but 100% agree with you in this case.

[TheBiggE.]

You should do this in Python too. I have saved myself SO much time, especially coming back after six months, or a year, to add a feature. Oh ok, I just need to input this thing into this new feature function and we are rocking and rolling. It also saves time for tests too. Types are just awesome!

[RGjolstad]

Since I'm working almost exclusively in C I really can't imagine _not_ specifying what you wish to return if you have the option to do so. It simply makes things a whole lot easier to read and understand.
I see some here mention that their IDE or LSP will show the return type, but if you're reviewing code somewhere which has limited access to such things you're really making things difficult for everyone...

[MrMudbill]

I use implicit return types for simple functions and explicit return types for more complicated functions, especially if that type is potentially useful elsewhere, since I'll have to be exporting that type anyway. I guess I don't feel the need to explicitly write that a math function returns a number if the actual calculation is 1-5 lines long. But functions that return objects, or unions of primitives, or anything more complicated than an existing type, I might need that type in a different part of the code where I'm actually calling this function (such as a React useState hook).

[rtsbase]

My hot take: I use explicit return types in some places and then in other places I think it is better to use implicit. Both are useful!

[ametreniuk]

Agree 💯 but how do you approach TS “specifics” like having weird behaviours on return types or God forbid “any”? Do you adapt depending on the type system?