You Might Be Using Typescript Wrong...

[@darksinge]

I agree with the underlying principles you taught, but cringe at phrases like "you're using X wrong!" or "you should never do this, bad dev, bad!". At some point in my career I learned that sometimes the "wrong" way to do something is actually better, and the "right" way doesn't make sense in every situation. I'd be careful talking in black and white terms because it discourages deep critical thinking and encourages cargo culting. Then there's always that dev who watches a video like this then goes on a refactoring rampage to "fix" a code base without taking into consideration the reasoning of previous devs or constraints the project may have been under. Not meaning to be critical, I just think it's important for others to understand this.

[@Brunoenribeiro]

I agree that context matters a lot, but there are some objectively problematic approaches that devs should learn about. Sometimes it's bad dev decisions that put a codebase in a situation where the "wrong thing is actually better", not commercial trade-offs or stuff like that. Devs must learn how to not put problems there in the first place. And overengineering is so common... to think there are people ditching TS because of it is just evil.

[@GenghisD0ng]

12:14: 'We' have decided this is the only library to do this now! Love learning about this stuff but man, sometimes when he begins to talk really fast like that he basically calls every other way/library the dumbest thing that ever existed haha. Atleast thats how it makes me feel like, there are many short rants like that

[@sorvex9]

This kid is too Young and inexperienced to talk about anything in life really

[@ismellpedo]

@@sorvex9 Then why don’t you provide some advice instead of harping on the “young and inexperienced”. I’ve met more than my share of what one might consider “experience” when in turn they are just set in their ways and refuse to do things differently. Things aren’t black and white you can be young and experienced and old and inexperienced. Statements like this are just as ridiculous as “You’re doing X wrong”.

[@twothreeoneoneseventwoonefour5]

I also cringe when people try to justify their bad decisions by saying: "Everything is good, every approach makes sense, just do what you like bro, it doesn't matter!". No, there are clearly better approaches than others for doing stuff. As a developer you should always strive for better readability and maintainability of your code. You, gentleman, yourself discouraging deep critical thinking and encourage bad decision making. Example is right here: "This code is bad because of xyz" - when you watched some video or read an article about why x is "bad"/"wrong". "This code seems bad, but the person who wrote it suurrreely thought about it a lot, probably was sleep deprivated, maybe his boss didn't allow him to use external libraries, and also probably had lots of other reasons for writing it the way it is, let's not touch it and not think about it anymore" - basically you. "that dev who watches a video like this then goes on a refactoring rampage" - should talk to his team lead first and if it is approved, why not? You are implying that this dev should just shut up and try to imagine a bunch of "what if" scenarios, why previous devs did this or that, and just forget about it. It is surely an opinionated topic, but giving up on improving something or thinking why X is wrong because of "cautiousness" is just stupid. It is a recipe for a stale dev who will not grow. Also about speaking with black and white. It is just a method of communication. Have you seen a lot of people who DON'T speak with black and white? - The common thing among them is that their explanations are a lot harder to grasp and understand. Imagine "correct" explanations: "Well, generally, in 96% of the times, you would use this technique, but very rarely, you might use this. Now to explain those rare 4% of the times, well, I need to explain you 4 other topics... And you may even never need those explanations in the first place, because you may never encounter those 4%, or forget about them by the time you do...". Unnecessary too complicated. And, the shocking part. We people are not children. Of course everyone understands that things may not be entirely true 100% of the times. We can think for ourselves. Not really limited to this topic but I would rather see people speak black and white more frequently than needlessly complicating stuff. You yourself should know the context. It makes no sense to go deeply technical and complicated in a simple 7 minute youtube video aimed at beginners(not this video, but generally).

[@frankwisniewski1610]

Splitting your code into multiple files is not always wrong. If you have a team, isolating code into multiple files makes it easier to merge and detect changes. For example, having separate component, api, and types files will let you clearly see what changes between commits.

[@sayamqazi]

Sometimes it goes horribly wrong and every team optimizes their local maxima developing significant inefficiencies in the glue that holds all those isolated components together.

[@drizzletone9148]

What you have presented here is tutorialish, super simple component. In that case I agree that there is no need to overengineer by creating different abstractions like services, types etc. But sometimes with huge codebases, some components share some logic and types and it would be better idea to somehow centralize types and API calls to have single source of truth.

[@webbi1540]

Correct, I don’t understand what this guy is talking about. In reality or real world projects you would normally separate files.

[@tankimloong2738]

That, and zod is basically typing your API response schema anyway so it's not that different. Depending on the size of the response schema or the project structure I might move the definition to a separate file. This example is simple of course, but I'd still have an API folder and have all API responses' schema's defined there. If I'm creating a simple component I'll probably leave the proptype definition in the tsx itself

[@buc991]

Yeah, i believe he's teaching ppl not very good practice in this part, he is telling that separation is for the sake of separation, but it's not, it's for your own convenience, and even more for convenience of your coworkers, these java guys that separate everything, they are not necessary evil, they just had some experiences with huge legacy codebases. When i just started working some years ago i made everything like he did, put all in one component and that's it. But then this escalated super quickly, you need this api call in some other place, and this type in another, and with time it's all growing inevitably, so with tons of components you already don't know what is from where, also duplication appears, and it's a mess. Nowadays i split everything from the start and follow some simple structure with that, a bit later on it helps a lot.

[@userfuckeri]

​@@buc991 Theres should rule for when you better to stop separate everything, and in his example im on his side. He showed component with uniq logic which is not used anywhere else in app(such case is pretty common is any project). If you start separating you should separate by logic not by some file structure template, cuz result will be the same. In my practice as dev when people start to separate react project on atomic components and the project is growing, it becomes just a mess, in some point of time they just start separate logic just to separate it. It becomes unintuitive.

[@MrHamsterbacke756]

@@buc991 If something is only used in one file, define it in that file. No problem with that. This does scale for big codebases, better then splitting the files.

[@joseisrael2946]

I really like this agnostic directory organization preference, but when dealing with dozens of types, interfaces, classes and enums on a industry level project (my experience), I still prefer separating the files likes the first few minutes of the video.

[@OzoneGrif]

I disagree about the abuse of inference. Inference has its downsides if you want to write reliable code, redeclaring the type you are expecting regularly makes sure that the whole chain of transformation is stable. If you start to infer everything, and make one mistake at some point, you will get an error at the very end of this chain, and going up to find the source of the problem can be very time consuming. It's important to be as explicit as possible when you architecture your application. Explicit code will fail-early, and this is what you want. Plus it's a good practice to learn how powerful good typing is, don't be too lazy.

[@justinkendall5647]

Agreed. Explicit types enforce invariants, which forces verification of correctness at the compiler/transpiler level where it's cheaper, easier and faster to correct. If you're choosing to forego enforcing invariants, either your project is small enough that it doesn't matter and you can get away with personal rigor (in which case, you could write JS with similar qualities) or the cost of violating invariants is minimal - eg, getting the wrong object shape back from a tracking or logging API, where you'd squelch a caught error anyway. I think advising a blanket approach to TypeScript like this is more harmful than helpful, as it declares the virtues of an effect that only apply to some small subset of projects. I would not want to maintain code written by someone with this approach to TS on server-side handling sensitive data, as all interactions with data become fuzzy gray, filled with assumptions that are not provably true (even by most unit tests).

[@nodidog]

I'm 50/50 on this. It's best to use inference when it makes sense, but understanding when it makes sense only comes with experience. You can get a long way with no explicit types at all. I use inference as much as possible, but regularly type function return values explicitly, to ensure that a function will return what I expect (and will throw a warning if it is changed). To me, Theo's example here demonstrates sensible use of inference.

[@bjbegui]

100%

[@Brandon-hd4vg]

can you share an example? I can't really think of an example of inference going wrong unless you are abusing typescript in some way. I definitely agree with wanting to catch type errors at the earliest possible point, but I don't how this example would be bad in anyway. The only thing I would disagree with this Theo's argument is that defining a zod schema is defining your type definition the only difference is zod takes it one step further and actually validates an unknown type against the schema you define instead of just asserting a response type without actually verifying that it is correct.

[@mikul3122]

Isn't that why he used zod when the inference was a little sketchy?

[@ISaNiAI]

Yeah. That's good until you start working on any bigger project: - 3 UIs projects all consuming the same API - then it's better to extract the calls somewhere to the common project/package - multiple UI components who want to use the same API endpoint data - then it's better to extract them into some common function, hook

[@LeonBlade]

We use swagger and open api for our API and then code generation to solve that problem. We have one main API and a few different clients that can consume it, so we generate the types and axios (in our case) functions that make it easy to call and we just create a form of wrapper around them either with hooks or whatnot and then you have fully typed API requests without needing to lift a finger. As part of the build step for deployments we have it run code generation as well which then can fire off errors if something is broken. It's pretty solid overall.

[@ynokenty]

@@LeonBlade now I'm jealous. Having autogenerated schema-based API logic is just perfect!

[@plexq]

@@ynokenty Yes and no... it can make life easier, but, if the client system doesn't conform perfectly to the expected usage and language choices, and also the expected library versions... this can end up making life much much worse. It's a double edged sword. So big pros... but some big cons sometimes too.

[@OryginTech]

For intermediate to advanced devs in startups with limited exposure and guidance from senior devs, your channel is a real goldmine. I’m writing all our front end code and these videos have helped break bad habits that I didn’t even know I had. Great work as always!

[@t3dotgg]

❤️❤️❤️ legit made this channel because I missed having a bunch of senior+ devs around to shitpost with. Pumped it’s filling the void I felt 🙏

[@nodidog]

Agreed 👍

[@anyadatzaklatszjutub]

@@t3dotgg your community and content is such a breath of fresh air! love that I've found it, feels nice to see and meet like minded people thanks man, keep it up hey btw, how about a video on best practices over feature flags? So based on different user permissions, you need to hide/show various parts of the UI, protect the routes for your app, protect the API endpoints on the backend... Really interested in your take on it!

[@miauw8762]

​@@t3dotgg Have been looking for a while for a channel like this. Most channels are just introduction to Very interesting video

[@Samulnik]

@Arizona +1 ;)

[@andogrando487]

This whole video had very little to do with TypeScript and more just about a design pattern. As many others have said this is fine for a one-off tutorial where you trying to just hinge on click-baiting title, but in practice separating out things saves so much time and makes it so much easier to bring others into a project.

[@KnThSelf2ThSelfBTrue]

Don't use zod to type API responses in your client-side app. Don't type API responses in your client-side app. I know the video wasn't technically encouraging you to do this, but I'm calling it out anyway because I see it all the time. If your backend devs know what they're doing, they should be exposing API definitions based on open standards that compile to TypeScript API client SDKs so that you never have to type API responses to begin with. It's the backend's system's job to expose the definition of its own API. It's not the frontend's job to provide a type-definition for the API(s) it depends on across the network. REST has Swagger/OAS, Postman Collections, and more. GraphQL, GRPC, and SOAP all require schemas anyway. A good backend dev will generate these standard documents during compilation, and then serve them up in dev over an API and/or some manner of artifact registry. The zod example is probably better in the context of data-entry where you actually need frontend runtime validation whose interface isn't already defined by external systems. The frontend has to own data-entry interfaces so that the UX has the option not to mirror the network traffic patterns. That's where getting 2-for-1 run-time and compile-time errors from zod makes a big difference. As a frontend developer, API response type definitions should be something you just get handed for free, and if that's not what you're getting, start demanding it. The worst you should ever be forced to accept is learning how to configure and run the CLI for oazpfts. Any more than that, and you're being overworked for no reason.

[@KnThSelf2ThSelfBTrue]

I mean... think about it this way: Should I force the people I work with to hand-maintain an exact copy of all the code I own? Of course not. That's just rude. Should even I force everyone to read every Slack announcement about every field I rename or add, and respond to each and every one by dropping whatever they're doing to literally hand-type a copy of every version of my API? Again, of course not, it'd be extremely rude. And before you say "Well we only do full-stack teams here! We all have total ownership of all the code!" I'll interject with this: if you're typing your API responses on the frontend, you're just being rude to yourself.

[@KnThSelf2ThSelfBTrue]

The *only* scenario in which I would consider it okay to use an API that isn't already statically typed is if that API was owned by an entirely different company that refused to provide a compilable API definition, but otherwise provided an extremely invaluable service to your project... it does happen.

[@jhonny9378]

Didn't know about that. How do I do this? Like, let's suppose I have a Nest api and a react frontend. How would I pass the types to the frontend? Thanks in advance :)

[@tarashankarchakraborty5486]

@@jhonny9378 what you'd do is basically ingest your graphql schema with something like graphql codegen in the frontend, which would auto generate all the types for you.

[@ralexand56]

@@tarashankarchakraborty5486 that's true but I don't believe Nest is graphql. Would love a video on how to do this using standard rest apis etc.

[@anatolydyatlov963]

I get your point about type inference, but why shouldn't we split code into multiple files, as shown at the beginning of the video? Why is it bad? You can infer types even when the code is split, and keeping everything related to the given component in a single file makes it harder to read, especially when your types are huge.

[@Svish_]

The point isn't "have everything in one file", the point is "don't split things into separate files, just to separate things into separate files". In Java and certain other languages each "thing" has to be in a separate file, whether that is a class, an interface, or whatever (I think). In JS and TS, we have the choice to encapsulate and group things into a single file, when it makes sense. For example: If you write a `react-query` hook for an endpoint, and a `zod` schema for the data from that endpoint, it makes very good sense for them to live next to each other in the same file, not in separate files. And if your component has a small helper component only it uses, it can make sense to keep that in the same file as that component _and not export it_. Look at it as private vs public fields in a class. Avoid leaking implementation details and stuff something uses. If it's a big complicated function that needs a bunch of unit tests, sure split it up into a separate file and make it "official". But if it's a small helper whatever, keep it in the same file, don't export it, and don't let any other components or functions even know about its existence.

[@anatolydyatlov963]

​@@Svish_ Yes, if that was the point, I fully agree - it's exactly what I'm doing in my projects. His example, however, does not align with what you said here. The "User" component could be very interactive, which would result in a few hundred lines of code. The types of this component, which would include Zod schemas, could include numerous setting fields, personal data definitions, zod transformations and custom validation logic. My problem is that this guy stated that splitting code related to a single "thing" into multiple files is undisputably outdated and should be avoided at all costs, which simply isn't true in many scenarios We know this, but imagine if a junior watches this video and decides to blindly follow his advice...

[@sorvex9]

@@SourceHades He is just a kid

[@bambamsounds]

@@SourceHades kzbin.info/www/bejne/kHiueJVnZZ5gf5Y&ab_channel=Theo-ping%E2%80%A4gg

[@alec4441]

When your application can't live in a single tsx file, then it's pretty useful to have a centralized module exporting all the types defined in the application. It's also nice to have a single module exporting all the API helper functions. So the "This is common, and also really bad" is (a) not really needed for simple projects but nobody died from overengineering a little bit (b) actually important for large projects (c) builds good habits for when you start working on large codebases Also, sure, you don't need these patterns if your design team consists of just you. But if you start putting API calls and types etc. in the modules in which they're called, that's not scalable when you need to start reusing code. You'll have dependencies cris-crossing over your entire codebase, not to mention that it's quite easy to trap yourself into circular dependencies. New members on your team will have a much difficult time onboarding. In fact, if you ever decide to scale up an application written in this way, the first step will be to refactor the entire codebase into something more scalable. TL;DR - HARD disagree. Also, I feel like you're unnecessarily opinionated about this. Why rant about something that isn't inherently harmful?

[@nlingrel]

If your app can live in a single file, do you really need to use TypeScript at all?

[@Psy45Kai]

Ehm... What's the problem of just using interfaces? An interface gives a type a name. So talking with co workers is easier. Understanding the system gets easier. Yeah, inferring types might work and the code might look clean but than why use typescript at all if you don't use types?? I am a c++ developer. I spam "auto" all over my code. But in typescript I explicitly type everything because every object could have every shape. Thus I will not trust the code which I did not type explicitly. I just started using typescript explicitly typing things helped me avoiding errors which I would have search for if I would have relied on inferring types. Maybe you might use typescript wrong 🤷

[@ShingoSAP]

Agree !! 👍

[@arielbatista7ify]

All the code in a single file? Nahh

[@martinkinywa2512]

As a senior dev, I would probably fire theo after a few months of working with him. Too opinionated, even when he is wrong. File structure matters in a lot of cases and not thinking about it can result in unnecessary chaos. The world is not black and white theo.

[@t3dotgg]

As a principal dev, whoever gave you a senior promo fucked up. You have a lot to learn.

[@doublesushi5990]

@@t3dotgg 🤣RATIO'd him like a mf

[@TomDoesTech]

That's one thing I can't stand when types are declared all over the place where the same type would just be inferred. Infer and generate types where possible.

[@WebDevCody]

This video opened my eyes a bit 👀

[@yoJuicy]

Good to see you on this channel Tom. You two are probably the best senior developers on youtube!

[@TomDoesTech]

@@WebDevCody I'm telling you, TS doesn't have to be a messy steaming pile. The best way to use TS is to use it as little as possible :)

[@TomDoesTech]

@@yoJuicy That's so kind of you! Been loving Theo's content lately. It's very relevant to the kind of stuff I work on.

[@JohnSmith-gu9gl]

SUMMARY: Always go with TypeScript's automatic type inference! Only use explicit type definition if TypeScript does not know/understand what type you are using or if you want to reuse types!

[@IAmLesleh]

Mostly agree, I think return types should be explicit though, otherwise it's too easy to accidentally change the return type of a function by changing its code.

[@callum177]

Very interesting. I was talking about this with a colleague the other day. We're on different teams, and he was talking about how they weren't overly great at typescript, or that they were trying to type everything, and it was getting frustrating. I said well the way I tackle Typescript is to just write JavaScript, and begrudgingly type things only when I get explicitly yelled at by the typescript server, which seems to be a similar approach to what you're talking about here. Also, just recently discovered your channel, and it's great. Keep up the good work

[@uziboozy4540]

Inferring is incredibly slow for the type checker, so for really complex data heavy enterprise applications, explicitly defining your types is better. Also explicitly defining your types makes it easier to code review in pull requests.

[@uziboozy4540]

Essentially being explicit about your return types can be really important. It makes it more maintainable and prone to errors where you could return incompatible data

[@uziboozy4540]

If you follow TDD principles, then you'd also explicitly refine return types 🤷‍♂️

[@dungkhuc9597]

`io-ts` is also a very nice validation library, couple that with `fp-ts` *chef's kiss*

[@jakejaylee123]

While I don’t 100% agree with the file organization rant, and while I love TypeScript, I’ve never heard of Zod and will definitely be using it. Thanks so much!!

[@TheMaDNiaC]

That Zod library blew my mind. You get type checking while fetching data from the API, infer the defined type and catch an error if the data doesn't fit the requested rules as well. Thanks a lot Theo, this was really amazing.

[@claytonmarshall8564]

I feel like my older brother just gave me a talking to. I'm curious why shots were taken at the file structure at the beginning. It didn't seem relevant to the main conversation about type inference and the example was too small to be a real example of "this is why you don't need more than one file". I think a domain-driven-design style of file structuring is totally fine. I'd even prefer it inside a larger node app. Anyways, nice video. I'm gonna give zod a try!

[@zb2747]

“They are breaking things up for the sake of it” Man I thought I was the only one who thought this - I agree 100%

[@hamm8934]

This video can be summed up as: keeping things together for the sake of it. You can partition files and still use typescript inference. They are not mutually exclusive. The argument for inference is disconnected from his initial critique of MVC.

[@nodidog]

@@hamm8934 he isn't disputing whether you can, he's disputing whether you should. It depends on the project context, there isn't a one-size-fits-all solution - but premature code splitting is arguably unnecessary

[@hamm8934]

@@nodidog I agree

[@showingsoftwarebugs5963]

I actually like throwing my types at the bottom of the file, because you don't have to scroll past them every time to get to the component code. I only separate out my types and interfaces into a types folder when I need to re-use them in two or more files so I do not violate the dnry rule, and I know where to go look when I see them being imported. (everything has a place) As for architecture, Mine looks something like this (has worked across 15 heavy tier projects)... - src/assets // contains imgs and docs - src/auth // authentication, authorization, routes and redirect rules go here - src/components // header, footer, layout, skeletonView(re-usable container for the content of a view), spinners, and other re-usable components that are shared on more than 1 file - src/store // all global state between views go here - src/translations // internationalization files (json files usually managed by a language team) - src/types // exported types and interfaces when shared across two or more files. - src/utils // helper functions re-used across more than 1 file and living outside the react lifecycle methods. - src/views/index.tsx // contains export wrapper for views to be plugged into routes - src/views/home/HomeView.tsx - src/views/about/AboutView.tsx - src/views/about/Article1.tsx - src/views/about/Article2.tsx - src/views/about/Article3.tsx - src/views/services/ServicesView.tsx - src/views/contact/ContactView.tsx - src/App.tsx - src/i18next.ts - src/index.tsx I never pass props into the views, and if I find I need to, that is when I use hooks to get the state from the global store. I've also seen lots of bad architectures out there, I hope this helps people...

[@ebrelus7687]

thanks!

[@plexq]

This obeys the rule of highest level functions at the top and lowest level stuff at the bottom +1 would recommend. As a developer you spend much more time reading code that writing it - make the code be a story where the interesting parts are most accessible, and the low level details are only there if you need to dig down.

[@boyracer3000]

I've been using TypeScript for around 6 years and don't really see the issue presented here. Single vs multiple files - both have valid uses cases depending on the project, framework etc being used. Type inference is useful but if you use it too much you are one step removed from a dynamically typed language again.

[@JLarky]

11:51 influencers will show you a file with two `userId: string` and will tell you "there are no type definitions on this screen" 😂

[@t3dotgg]

...I caught this when reviewing the video and hoped nobody would notice lol

[@JLarky]

@@t3dotgg don't underestimate your audience ;-)

[@vitalydrogan5214]

I think what you describe here is a flavor of the thing you said is “wrong”. Basically, instead of describing type properly as a type you implicitly define it with this zod validator - it’s literally the same as defining type but instead of proper syntax for type definitions you use some arbitrary dsl of zod. Imagine if you defined type as typescript type but some other library named doz would use it to validate entity by its type, what would change? Probably nothing

[@t3dotgg]

Except it is a runtime validator that asserts the types are valid? If I cast a type there and the response wasn’t the right shape, it would silently do the wrong thing

[@valentinopereira7763]

Hey buddy, what you suggested, to have stuff inferred, I highly disagree as for me its against the rule of readability.. Code should speak for itself. Debugging inferred code makes us create a mind map of what the type of the current variable is - which is something typescript already solves by having typed definitions for all variables. What you said, assumes everyone one the planet uses vscode or some smart editor, and that the user is actually going to hover over the inferred variables all the time. Just an example to make things clear - I do a lot of PR reviews on Github, and it's just hard to review code which has a lot of inference in it. It's not clear what is the type of the variable being passed to the function - if I had to understand that - then I'd have to find where the variable is declared. Now I have to remember this while reviewing the rest of the file. Typing the variables makes the code much simpler to understand - you could even copy paste a function into notepad and figure out what a function is doing, what it takes as input (simple case string, number etc.) and what it returns.

[@ToNmAnAyO]

if you lived in a perfect world this would work, but when you get a file that is 3k lines long this is a joke

[@t3dotgg]

When you get to a file that's 3k lines long, break it up based on RESPONSIBILITY! Taking a 3k line file and ripping out all the typedefs makes working with it HARDER, not easier. I've gutted enough 3k+ TS files at Twitch to say this with confidence - if you architect things the way I lay out at the beginning, that is worse than a huge file.

[@bodorgergely8545]

@@t3dotgg why would putting the type definitions in another file make things harder? wouldn’t it make that file responsible for defining user types?

[@hamm8934]

@@bodorgergely8545 my way of doing things is better than your way of doing things because I like the way I do things

[@dealloc]

@@bodorgergely8545 Defining types should not be a responsibility of your software. Responsibility is about co-locating the things that are in the same domain; including logic, types and data. A "types" file doesn't tell you anything about what domain of types it declares without looking at it or having knowledge about its availability. Importing a "user" file is clearer about the domain. Additionally it also avoids the "10 imports per file" without any architectural changes.

[@hamm8934]

@@dealloc this is just a difference of construal. what you consider one domain, many others consider a different domain. just use a system that works (hint: countless systems work)

[@Svish_]

Agree in general, although in teams, on larger projects, I highly recommend at least making function definitions (including the return type) required to be explicit. It makes it so much easier to know, not just what is returned, but what _is supposed to_ be returned. Explicit return types have more than once prevented myself from writing incorrect code as well, because I had explicitly defined it to return X, and I was sure it did, but Typescript caught my error in an overlooked path that actually resulted in no return at all, i.e. undefined. Without an explicit return type, I potentially wouldn't have caught that. And without an explicit return type, a future developer, including me, would not know "was this on purpose? is this supposed to return `X | undefined`? Explicit function definitions and module boundaries, yes please.

[@JoshMertens17]

Instead of declaring your types with Zod and `return zObject.parse(res)` you can use `UseQueryResult` with type as a generic. Using _as_ will just override the response shape without checking it, but adding the above as the return type (with ...({ userId: string }): UseQueryResult) will check that the object matches the shape, similar to what you're doing with zod

[@Dontcaredidntask-q9m]

I'm tired of my tech lead (ex C# dev) forcing us to write C# TS - dependency injection, classes, services/repos/clients zzzz

[@Dontcaredidntask-q9m]

Oh and files and files of interface/class types

[@t3dotgg]

I'm so, so sorry

[@KnThSelf2ThSelfBTrue]

I think the only time it's okay to have a bajillion files for one component is if you're up to shenanigans where merely importing something into a unit test suite would otherwise instantiate something you want to avoid instantiating in a way that your mocking framework doesn't know how to prevent. Moving the thing under test to its own file is one solution to that problem. Also, you get to avoid meetings and code review comments with devs that are obsessed with short files, so that's a perk.

[@robertlemiesz7143]

I dont think its inherently bad to split stuff out into multiple files. I find that in complex projects its actually very useful, and prevents people from doign nonsense cross module imports.

[@jynxycats]

Much agree. Putting too much in one component leads to it quickly being a specific use-case situation, and that sucks when you are trying to use the thing elsewhere. Or if you're defining API data models (sucks if you're doing it by hand, and not automatically, but such is life), you can use those Types elsewhere in other function parameter typings, State management files, or who knows where else. The stuff in this video feels fine if you're doing a low level tutorial, but as soon as you're trying to make something real, having too much in one component file is just a bad time for yourself later.

[@KangJangkrik]

Pro tip: ALWAYS use interface for defining props. Do not embed props type inside triangle bracket like React.FC for sake of readibility

[@OmarAbdelaziz__47]

please make more like this type of videos. Somehow I wasted a lot of time for type definitions. Thank you Theo!

[@MJGorecki]

I can't even remember when I had to go that low into writing Typescript, so that old way would probably have been the way I used to code it.

[@lukasmolcic5143]

well this works if the user component is the only thing that is using the the useUserData query, but if you want to use it in different places you need it in its own file, we keep a services folder for that purpose and if I we have one service which uses the user type we can keep it inside that service file, but more often then not, we have multiple services like get all, get by id etc. which are using the same interface, so moving the type to services/users/interfaces makes sense. Hopefully will try tRPC in the near future and see if that changes anything.

[@t3dotgg]

Yeah break things out when they’re reused!!! Just not until then :)

[@salehm5413]

For me with typescript : any : any : any .......etc

[@pregooooooooski]

Thanks for the example, nice learning on inference types. Although I'll keep using a hybrid approach to use inference but split files by logical segments, it's way more functional in real industry like environments.

[@jcollins519]

Great topic! Would love to hear more about how you structure directories and modules like you mentioned in the beginning. Also I heard you mention in another video how you like to extract some more complex hook logic into a hook outside the component function, which is something you showed in this video and is something I've taken a liking to in my own work. It's good to see how you manage type safety in this scenario.

[@masmeert]

I think this is an issue you can see with many python devs (no offense, I am one myself and was guilty of this). Python's type hinting system is mainly used as code documentation so once they start learning TS they think it serves the same purpose. I'll definitely start sharing this now lmao.

[@Ch1ll0ut1]

IMO in js/ts every file is a module and they should follow the Single Responsibility Principle. For me, types of the business logic or presentational logic, belong to that logic. I wouldn't wanna work again on any codebase with a "types.ts" file. Especially in bigger projects these files grow exponentially and are like a trash bin for anything type related. I completely agree with Theo, this is really bad practice. Instead extract re-usable logic, that doesnt belong to the files main purpose, into separate files. E.g.: A component displaying a list of users doesnt need to know how to query the users from the backend, instead it should call a re-usabable custom react hook, which encapsulates the logic to query the users. No need to separate types into files. Separate responsibilities!

[@JeyPeyy]

My coworker is trying to get everyone to be explicit about their types, but I'm of the complete other opinion; be as implicit as possible (as long as the type hints don't get overly complicated). The point of types is not to document it everywhere, but to make sure you get compilation errors instead of runtime errors. We often have functions that return subset types of what they actually return because of the obsession of being explicit :/

[@Synesthesia-r9]

I find parameter and return types on functions are explicit enough usually. I have been stung multiple times with implicit return types. Obviously don't overdo it, ie; I haven't found a good reason to do `const name: string = 'Joe Blogs'`

[@json_bourne3812]

I personally think you can't be too explicit. If I had to pick one or the other (being very loose/implicit or being very explicit), I'd pick explicit every time. I think the thing that bogs people down with writing this code is the structure of the project, files, and code - and that is much more of the problem that how implicit/explicit you are.

[@JeyPeyy]

@@json_bourne3812 no, the main issue is that it can lead to unnecessary narrowing of types, which can cause people to believe they don't have access to properties when they in fact do. What bogs me even more is even people type assert when it's not needed, because that will make you think you have access to properties you don't. Refactoring also becomes much more cumbersome when explicitly typing everything.

[@json_bourne3812]

@@JeyPeyy on the contrary, it makes refactoring rather clear and easy. Change the type definitions first to the requirements, then change the code. Everyone has their preferences, and to be clear when I say explicitly typing, I don't mean unnecessary narrowing, I simply mean declaring what should go in and out of anywhere. If you really want to narrow then the code should also narrow by creating a new object with the required values, though I don't know where you'd want to do that over just passing what main interface you need.

[@hundvd_7]

Awesome video. The problem is, _I_ didn't need this. My company does.

[@jacksonmalloy144]

Awesome! I've been following this approach too. Only pitfall is making sure your tests catch changes with the type coming from the server. You can also do useQuery(... For autocomplete of the data in the component.

[@t3dotgg]

Wait til you watch my tRPC videos ;)

[@tiltMOD]

I think the reason you get "uknown" for error is that `parse` method in Zod throws an error, so the UI component will never any properties in that case. You can use `safeParse` which gives you either the parsed data or an error object.

[@zb2747]

Would love a Sr dev series where you give your point of view and share best practices for Junior devs like myself

[@SeanGoresht]

2:33, no; you're doing it wrong. File names DO matter, and they matter a lot. Index is a terrible file name, and also probably user.js sucks too. How do you expect to pull up the file via CTRL P later unless you name your files explicitly? Having "one file to rule them all" is a problem symptomatic of the "divitis" proselytized by ye "react"/Next/Remix evangelists. It starts with mixing logic and presentation together, taking the web backwards to PHP days of inline styles where we mingled both interchangeably. It ends with this kind of mentality, with files longer than 2000 lines. "But make more components", I hear the naysayers call out. No, you don't need a component just for button; it's a native HTML5 element, and just because the first example on the "new" react docs use it doesn't mean you should create one. MVC is not the past, and it still exists for a reason: the web was literally built on it! More aptly VC because CSS and HTML comprise the view while javascript traditionally comprises the "controller". Look at Angular and Ember, or even Rails or Django for examples of separation of concerns. If you think having more files will slow down your builds, then you are very wrong, especially if you serve your website using Next and HTTP2. More components or not, you benefit from caching at the very least if you separate out your concerns. You don't go back to the stone age when you separate HTML, CSS, and Javascript; you give yourself peace of mind, knowing you won't have to think in 3+ languages while writing your code and just focus on one language at a time.

[@loekTheDreamer]

to start off, thank you for making this video. i actually didnt know inference worked like that, so thanks for the lesson 😉 maybe you should rather use the title "zod, your doing doing typescript wrong". because it honestly feels like just another package to learn.

[@hmh530]

15 minutes in two words: abstraction, zod. I feel like you can’t claim “you’re using typescript wrong” and then tell someone it’s because they’re not using a specific package.

[@t3dotgg]

I used Zod as an example of inference?? ??? I get that you want to be mad at the video but at least make a real point

[@drekforder2952]

Every single line of code you've vritten can be written in pure JS ( including the type checking ). Based on what you've shown TS really seems pretty useless, which it's not. example: TS: function add( x: number, y: number ){ ... } JS: /** * @param { number } x * @param { number } y */ function add( x, y ){ ... } *note that It may also be written in a more compact way, I just find it much easier to read this way*

[@jdubz8173]

I ended up with a use case for zod but couldn't remember for the life of me what it was called. Returned to Theo's vid here to remember. Very useful to see an example in action to help me understand it quickly. Thank you!

[@Elies313E]

I think he's referring to the people not already using this system, not indicating that there are times when separating the types in a project/feature into a types folder is a better idea (might be wrong though).

[@rdefazio]

I love your content man. I'm going to be checking out ZOD. My question is... what are you supposed to do when you need to refer to the same type in multiple files? I don't imagine you'd say we should redefine the same type in those files. I'm just curious what solution you're aware of that you'd recommend as a better approach for that situation because I currently create a type file that I can export types from when I need to reuse them.

[@universecode1101]

Typescript is useful, maybe it will be indispensable, but it's not a choice I make for every project. For big projects, yes because it can help you, but honestly, today I prefer for small projects, simple Vanilla Js

[@t3dotgg]

I compete in Advent of Code in TS every year. For smaller things I find TS just as essential as I get more frustrated when I have dumb bugs TS makes it so much easier to go back to that "small thing" and fix it with confidence, and with less brain power throughout :)

[@triyuga]

The only thing worse than a really bad haircut is a really, really, really bad haircut

[@greenstarlover1]

The double await bothers me immensely in a deep primal way.

[@duke605]

Disagree with the condensing everything into one file but hard agree with the no types file. Make the type where you need it. AND UNDER NO CIRCUMSTANCES HAVE A SINGLE TYPES FILE WITH EVERY TYPE IN YOUR CODEBASE

[@lyflfflyflff]

but you can easily reuse types with such file instead of defining same type again and again

[@duke605]

@@lyflfflyflff 🤔 just export the type so it can be used elsewhere...

[@lyflfflyflff]

@@duke605 I can define type User in some Dashboard component, than forget about that and define same type again in UserPage, instead of having all types in one file and easily reuse them

[@duke605]

@@lyflfflyflff seems like you need a better IDE that suggests you the types in your codebase when you partially type them in

[@lyflfflyflff]

​@@duke605 ok, that can help, but I'd rather see some Invoice type imported from a types.ts file than from SomeUnrelatedComponent.tsx.

[@lastink444]

Couple of month later your videos and this one in particular, helped me to improve myself A LOT, stop doing some dumb stuff that I didn't know was dumb. You're like that cool lead/architect that I miss at my work. So thank you

[@thomassynths]

This video is predicated on the false (and implied) assertion that writing types is onerous and time consuming. Writing function bodies dwarfs the time needed to write signatures. The immediate cost of writing signatures is insignificant. Especially in languages like TS where refactoring tools work without issue (unlike C++ where all syntactic tools are beyond buggy).

[@boomer5015]

I've never seen a validator used for a get and weirdly never thought to use one. Makes so much sense and seems so obvious.

[@yousifal-raheem5061]

Your understanding of JS and TS is so minimal, you shouldn't be making such videos claiming that we're doing things wrong. You don't even know where to put the type when you're doing object destructuring. My advice is, spend a few years before to avoid misleading your audience.

[@t3dotgg]

Sincerely hope you’re not in a position to make hiring decisions because you SUCK at guessing experience levels. Excited for you to get to Chapter 3 of your Typescript book where you learn I’m right :)

[@maurov2104]

@@t3dotgg Yousif is right tho, you just renamed the property when you destructured it lol

[@marktellez3701]

Hey Theo. Your content is so good. Beyond your years really. Here’s a filmography tip. Move your camera so you head is higher in the frame. I know you don’t want to cut off your beautiful head of hair, but eyes on the top third line brings a more emotional connection. Please try it in one of your future videos.

[@t3dotgg]

I want to do this but my camera is bolted to the damn wall lol, not as easy as it sounds :( soon hopefully!

[@marktellez3701]

@@t3dotgg i know the struggle! Get a dji om 5. Set it on your desk with just a camera phone in it. You’ll be blown away. If I can ever give you a hand with anything let me know. I love your stuff. I’m devmentorlive btw :)

[@Elies313E]

So this is pretty neat because when you open a file you know what types are being used just by looking at the top of the file (and thanks to zod the error handling is quite easy). In the other case you don't know what types are used in what file unless you explicitly called them out in a comment at the beginning of the file, which seem to me more like a hack than a good system. Also, I don't have experience working with large codebases (I've never written more than 1k LoC for a project) so if someone wants to point out a scenario where separating the types into a type folder is a better idea I'd be very grateful.

[@raylawlor4887]

Is this a joke? Your title should be "React devs have no idea what TS is".

[@t3dotgg]

You sound like my Tiktok commenters

[@arthuro555]

Have you heard of typanion? It's a validator made by the maintainer of yarn that's TypeScript-first.

[@Daniel-ve8yr]

Thanks for the video, man. The title drew me in. Just subbed. You definitely deserve more views.

[@dtinth]

I love type inference! Though, there are some cases where I like to use explicit types - when I want to “lock” its type. For example, explicitly specifying return types of a function can help prevent future developers from inadvertently changing the return type of that function (I usually do this for exported functions, or when constructing objects that should conform to some interface. I see React.FC as an extension of this principle).

[@t3dotgg]

Totally agree. There aren’t too many cases where I care to do explicit return types but FCs are absolutely one of them

[@chibapu]

damn, senior dev billy idol has a point.

[@DevMeloy]

Some valid points and these might be fine in smaller applications, but I find that splitting code out make life easier when we're talking about 100's of files and thousands of lines of code. TS is a band-aid on JS.. I like JS but look forward to the day when a strongly typed language can be used.

[@huhu77700]

Insane coupling to libraries, no test, using React.FC (you need children prop for what ?), hardcoded const and symbols. No no no.

[@ChillAutos]

Gotta say I disagree with the files thing. I find it far easier to work in smaller files with better logical separation.

[@purpinkn]

*uses typescript because js infers types *Infers types with typescript anyway

[@plexq]

Whilst I think "wrong" is a strong statement, I think there is valid in the SOLID model - I do think some folks can end up too heavy handed with it. And if you didn't know about zod (I didn't), then the next best thing is a type definition to help the downstream type inference happen. So I'd say that I'd prefer zod over an explicit type definition, but I wouldn't say an explicit type definition is incorrect, it's simply that there's a better way.

[@macr76]

Instead of return await (await fetch(...)).json(); you can simply write return fetch(...).then(res => res.json());. Much simpler and cleaner code, there is absolutely no need to write return await unless you wrap it in try {} catch {} block.

[@ZeusTheKid]

7:15 no you cant put that there ;)

[@MrHamsterbacke756]

Yeah, also noticed it.

[@TenFeetDown]

Bam, so much information condensed in a short video, thanks so much.

[@nomadshiba]

let me help you more const useUserData = (params: { userId: string }) => { ... } const UserComponent: React.FC = ... or you can add some extra props like const UserComponent: React.FC = ... you can also type the color like type Color = `#${string}` or type Color = `#${Lowercase}` so you say it has to start with # and it has to be lowercase etc

[@nomadshiba]

typescript has many more features than people are aware of like for example you can get a return type of a function or you can find and replace types in an object you can exclude, omit etc, Uppercase string literals and many many more stuff you can write types like writing a function lib for types for example example of replacing types in an object export type ReplaceType = { [K in keyof T]: T[K] extends Search ? Replace : T[K] extends object ? ReplaceType : T[K] }

[@WebDevCody]

Thanks for this video. I’ll have to try this approach when I decide to start using typescript more for my side projects.

[@aplomBomb]

Instead of casting the response inside your function, you should add to the return type to the function's return signature instead, casting is a no no

[@drench1580]

I suspect you can parameterize the fetch call. E.g fetch(…whatever)

[@arshiagholami7611]

Theo reminds me of Andrew Tate somehow

[@ward7576]

React-table is pure example of sh*tty TS. I cannot understand for the life of it how those types work there. It makes me feel like what I have learned in fundamentals can be thrown out of window since there's one more "feature" they add - unreadable sea of types that make little to no sense.

[@stylianoszampoulakis9345]

what's that theme?

[@jtrenda333]

I am using zod and rely on type inference as much as possible in my code, but I still feel like I spend more time trying to get rid of red squiggly lines than actually building software.

[@tongshen86]

typescript allowed me to code for 30min without looking at browser

[@tochithebedford7672]

The sigh i sighed before beginning the vid was crazy 😔

[@Ce_Lazca]

Just subbed. Good stuff, gonna watch all you TS vids

[@dominikdorfi]

Never heard of zod before, you my good sir are a lifesaver!

[@Kodunmi]

I feel this guy doen't really know that much

[@t3dotgg]

crazy I could say the same about you

[@GigaFro]

I’m definitely a noob at type script… but wouldn’t explicitly defining your type for the output of the function useUserData as UserApiResponse do all the shape checking you need? If so, this work around doesn’t seem to add much value, but rather lines of code that you need to maintain. Now, not only do you need to update the type itself every time it evolves, you have to update the corresponding Zod code. 🤷‍♀️

[@jansandor3055]

Check how "as" in TS works and you will understand. It's not type casting with checks. With "as" you tell TS that you know better the type (you turn TS off a bit). If I don't have to, I don't use "as". I must have really good reason to do so.

[@GigaFro]

@@jansandor3055 I am not talking about the use of the "as" keyword anywhere in my response.

[@alek282]

As mainly a Python developer just browsing these I am a bit confused, Python has pydantic which essentially achieves the same exact thing with runtime validation of data, but it allows usage of builtin types and extended types it provides itself (PositiveInt, ConstrainedInt, etc) For extended types, you perform explicit imports, but for built in types you simply type annotate like it's business as usual, no need for custom DSL Is there no such option in TypeScript land? Why do I need to use this z.string().blah().blah(), why can I not do z: string to achieve similar effect or z: ConstainedString(max=10, min=5) or w/e the equivalent here would be Or am I missing the point plz no flame just python dev passing by wonderful channel btw!

[@t3dotgg]

Really good question actually!!! The reason stuff like that isn’t built into typescript is because “typescript is imaginary”. When you compile your TS code, all the TS goes away. The goal of TS was to add CODE validation checking on top of JS, not to change the runtime itself. As weird as it may feel coming from Python, we do kind of dig this aspect of TS. Since it’s “just JS” and is written IN JS, we’re able to build awesome things like Zod to do validation and bridge the gap 🙏

[@alek282]

@@t3dotgg gotcha, thanks for the explanation Theo, discovered your channel just few days ago and just can't stop watching, thinking of starting to drop by your streams too, awesome work

[@ryanwood9288]

Good reasons for not using Zod: Our project is already using Yup, we aren’t using typescript and there are higher priorities than swapping out two comparable libraries.

[@t3dotgg]

You're correct - priority 1 should be moving to Typescript :)

[@ryanwood9288]

Agreed! Working on it…

[@kiranojha8811]

If you want to show the error in screen instead of console then use this, if (isError && error instanceof Error) { return {error.message} }

[@SolomonTheStoryTeller]

Seems like you haven't worked with complex enterprise applications and your background is limited to the hello world equivalent web apps.

[@brenoxavier6185]

Yep, good patterns are garbage, make all in one file, without any dependency injection, don’t decouple your code. Architecture is useless, who needs a good maintainability? Let’s ship only functionalities. You can do anything with procedural code 👍🏻

[@ShingoSAP]

It would be worth it for some people to learn about separation of concerns .... But it seems the new trend is Laziness.👍

[@theoDSP]

Type inference is dope but you can accomplish a lot with typescript without using zod.

[@Wizatek]

I am not using Typescript, and i think that is the right way to use it

[@MayankSharma-mb6vk]

Hey! at 7:08 when you put the colon UserAPIResponse within the destructured object, that isn't explicit typing. That'll actually just define UserAPIResponse as a reference to the destructed variable.

[@_heyglassy]

cool story, but what's your vs code theme?

[@Blue-bb9ro]

learned alot, ty!

[@ee8s]

Instant like and subscribe, fantastic run down! I was totally using TS wrong lol

[@Nahasaki0]

What code intelligence you use in vscode? That suggestions are fascinating