I'll make this short and sweet. Learn to rely on go to definition to discover any typings associated with the library in question. Always do this before searching the web. Typed libs are essentially self documenting.
Being a typescript user I think it's one of the basic skills to find the appropriate types via navigating symbols/type definitions. Any modern IDE/LSP for any modern typed language supports this kind of stuff I think it's more of an issue to a beginner rather than any intermediate or advanced TS dev or any typed language dev
TypeScript did provide the answer, through tooling, which I think is the appropriate way for TypeScript to be involved in finding the answer. From a web documentation standpoint, you wouldn’t expect the JavaScript site to provide answers for TypeScript, just because TS extends concepts of JS. The TS team can’t be expected to keep documentation on all the different frameworks built on TS, or that can be used with TS. I also think some of the onus falls on the developer, to not just think of TypeScript as “JavaScript with types”, but to adapt their approach to development to really lean into the features, concepts, and workflow of the language they’re using. Also, when I have a question like this, and don’t feel the tooling is helpful, it’s usually quickest to ask ChatGPT; you get an answer tailored to your specific question, and you can ask clarifying follow-up questions: Q: What’s the typescript event type for a mouse event in react? A: In React, when using TypeScript, you can type your mouse event handlers using the `React.MouseEvent` type. You can specify the type of element the event is attached to, for example, a button or a div: ```tsx function handleClick(event: React.MouseEvent) { // ... } return Click me!; ``` Here are some of the commonly used mouse events and their types in React with TypeScript: - `onClick`: `React.MouseEvent` - `onMouseDown`: `React.MouseEvent` - `onMouseUp`: `React.MouseEvent` - `onMouseMove`: `React.MouseEvent` - `onMouseOver`: `React.MouseEvent` - `onMouseOut`: `React.MouseEvent` - `onMouseEnter`: `React.MouseEvent` - `onMouseLeave`: `React.MouseEvent` In the above types, `T` refers to the type of HTML element the event is attached to, like `HTMLButtonElement`, `HTMLDivElement`, etc.
As developing JS for 20+ years, I think all types are overhyped. I build JS long before TS, also using event handlers. You don't have to need the type hinting for everything, especially for basic JS and Browser methods, just check e.g. MDN, and debug what you receive. The types you are using are not always correct, and you can pick the wrong type without knowing it, till something weird happened.
I agree with the statement that this isn't a TS problem. TS is set up to be used with any framework, but at the end of the day it is the job of the maintainers of the framework to type everything properly and provide the documentation. Therefore this isn't an ecosystem problem - it is a problem at the product level of whatever tool you are using.
I've been using JavaScript for over 1.5 years. I dread using TypeScript because you have to set up TypeScript. Or if you use TypeScript for Vite you get this weird templating and it is much different from the standard TypeScript implementation. BUT lately I've been checking out the job market for JavaScript and compared it to TypeScript and there are 3 times more TypeScript jobs over JavaScript! I guess I am going to have to bite the bullet and just suck it up and learn TypeScript. I guess if you are familiar with languages like Kotlin TypeScript shouldn't be so different.
thats why i like Angular and Angular material. Everything nicely documented and typed and overall very powerful. with react you need to collect all your packages first and search every piece and part you need. with angular you get most of it out of the box and documented at one place. Typescript still over JS at any time.
@@siya.abc123 you probably nevee used it. it is still top 3 if not number 1 used framework in business applications andin my opinion the most powerful and structured one
@@JamesQQuick yep and it is still one of the best frameworks.i love it personally because of all the features, structure and modules you get with it. it s well organized overall. for some too much overhead and functionality maybe.
Yeah I think that's the general struggle is the overhead. There's more to it initially than there is with React, Vue, Svelte, etc. It's come a long way too though!@@mxz2024
So often in Typescript you find yourself doing type gymnastics to get the basics working. I think the Sveltkit JSdocs makes the whole flow a much better DX. Certainly for rapid prototyping.
I just hope I get some kind of documentation when I hover over things, and found out that way lol Flutter/Dart would even take you to the source code of what you hovered over.
Same, I discovered it pretty quickly just by hovering over a variable (that I wrote) with a correctly inferred type, then figured it should work on things imported from libraries too
Sometimes mouse hovering doesn’t work pretty good because types can be messy In such a case solution is to Type[“property”] Please don’t blame the language or the libraries. When u have more experience in TS u will realize there can be tons of types in a code base. It is really hard to provide documentation for all of them. That is why TS has provided these features and some utility functions.
James, I have to say, I'm really glad that I'm not the only one who is struggling with using TS! Personally, I use it in combination with React, too, and I have the same problems and sometimes, I'm so frustrated that I use Type Any and continue without the help of TS benefits. I also thought that this was always because of my lack of proper knowledge of TS, maybe there is a problem more on the React side. Thank you very much for the great video :-). I have a question, is there any chance you will create a video (or videocourse) using typescript, especially in combination with React? Thanks!
This is great... there are times when there's still no intellisense or proper documentation, so in those cases I log out the parameters to the console to see the type of object I'm working with and that will often help to type the signature.
Not knowing Code editor is problem also. to hover or ctrl + click, to navigate to type definititions. It is two source maintainence to have docs with the types, because you can access as pro ts dev, through type definitions every part..
I still think it’s a react documentation issue, not a typescript issue. What’s the typescript team gonna do, force the react team to update their documentation? Additionally, is the react documentation open source, I wonder if there’s an issue open for it
I cannot understand how anyone has problems using TypeScript in 2023, everything you need is in the editor. Just don't use anything that doesn't provide full types for everything, it's 100% not worth it anyway, as the devs don't value quality. I am using TypeScript for years and there is a reason why the usage of TS has surpassed JavaScript. TS is the default. PS: I don't think modern documentation should have a TS/JS toggle, it should just be TS at this point.
I have been using TypeScript since 2016, but now I increasingly feel its historical mission is nearing an end. The downsides of TypeScript are clear: it increases compilation time and debugging difficulty, requiring source maps. Moreover, compiling with pure JavaScript libraries often leads to a plethora of inexplicable errors. Additionally, new versions of TS frequently are not backward compatible, and using third-party libraries often brings a lot of trouble. Sometimes, you spend hours just to make the compilation work. My initial intent for using TypeScript was for interface checking, but now that can be achieved with IntelliSense too. I hope the next generation of ECMAScript will natively support interface type definitions.
Can we open source a type definition documentation for React, next, etc. It will serve as a go-to utility for quick solution. Who's down with this idea? Preferably someone who knows a thing or two about docs and Technical writing. I can scaffold a website. The structure and presentation will have to be deliberated.
Yeah the struggle is real, right now am struggling with import svgs as ReactComponents because I create my app using vite. Searched the internet which told me to use the vite-svgr-plugin but still Typescript is yelling at me. Then I searched some more and saw other say I have to use d.ts file to recognize svgs but still Typescript is not listening.
TypeScript examples in docs are nice, but when writing code in IDE there shouldn't be a need to google "What type does X expect", that's the whole point of TypeScript Language Server. TypeScript code is self-documenting, to a degree where you can actually generate library documentation from code automatically. Thanks for the video, a good reference to show somebody who's not used to this workflow.
I think we've all been at this point in our early React+TypeScript journeys! I think the main reason could be that React itself doesn't have the types bundled in and they have to be maintained by DefinitelyTyped (at least, IIRC). Regarding the generics as well it would also be good to have a source somewhere of each element and what React thinks it is e.g. doesn't have a matching HTMLSectionElement, so I find myself reverting to just HTMLElement with no idea if that's correct or there's something more suitable.
No typed language will guarantee type safety. You can write code in Java or C# which lacks type safety as well. This is not a TypeScript problem. It is a programming problem in general where developers don’t define types properly or don’t provide the proper types to others. You could call it an "ecosystem" problem, but it certainly isn't the language"s fault. Blame the craftsmen, not the tool.
Instead of asking someone else to improve their documentation, you should submit a PR when you find something that needs improving. You sound like you know exactly what you’re looking for in the docs so I think you might be the perfect contributor to help them improve! I do have to say though, this has absolutely nothing to do with Typescript or “the ecosystem”, this is squarely a React documentation shortcoming (although I’d check the actual official React docs before even going as far as to say that). Good news is you can personally do something about it! 😉
This is a typical situation when no one cares about the documentation, because the most important thing is to make a new release. But imagine if the builders were just as excited about the new floor, but at the same time forgot to build a staircase.
@@JamesQQuick It’s also difficult to imagine a building without part of the stairs, where everyone falls down, but at the same time pretends that everything is fine.
You can get TypeScript to tell you what type it should be by passing the function to an event handler spot with the wrong type specified. Just don't leave it as default any or you won't get that. Probably a good argument here for not having arguments be any by default.
Discoverability is a significant component of success for any given framework/tool. Even giong directly to the React docs, I find it hard to find exactly what I'm looking for
@@JamesQQuick not sure how true what you say is, have you ever tried the aws docs? you're definetely right, it should be better for you from a product perspective, that's factual, now, you want to be a developer, you get paid for it, it's your job to get things done and to do the research, therefore, i don't agree
if typescript didnt exists you still be searching random articles and reading though api docs to figure out what the shape of the handler is suppose to look like, and you have to do this for each and every different type of handler you would use and every property and method on that component. now its just a mouse hover and control+click away right in the IDE. we should do away with all type systems and just raw dawg all code and spend all day chasing undefined bugs, a lot more productive imo
Yo aprendí desde el minuto 1 que en React debes poner el ratón encima para saber qué tipo de evento es. Aplicar Redux en React con Typescript sin redux-toolkit y tiparlo todo bien es una pesadilla. Pero quien no usa redux-toolkit hoy en día? Aunque sea más codigo, y la verdad es que con React puede hacerse un poco pesado usar Typescript, en el backend se agradece muchísimo. Y en React a fin de cuentas también. Porque sin Typescript muchas veces tienes errores en React que no sabes ni de dónde vienen.
Will never understand how people can say things with such conviction and authority when there is a clear lack of knowledge. That "trick" was just a basic part of using typescript that every user should understand
With all due respect. Not particularly a fan of TS but surely you could have inspected the pseudo event object , by perhaps just triggering the event? click , this is neither TS fault nor React fault. React is not a TS library, and TS cannot account for all the solutions present past and future. But I do get your point, sometimes tools that are meant to speed things up under a false premise end up consuming critical time through their implementation.
Yeah, I think it's really easy for you (and many others) to talk about how obvious it is to have done that, but the reality is that my perspective has also been shared by lots of other people too. Some things are obvious to some and not for others. Because of that, I think it's still something to address. Thanks for adding your perspective!
I thought its a common skill you unlock when working with typescript for quite sometime 😂 just hover or ctrl+click, don’t worry you’ll get there james lol
Dude, you can't use TypeScript inside the template part of a Svelte component. It took them a long time to add that toggle to the docs. There is no versioning for the documentation, meaning what you were just browsing is old now, you don't even need to import the type anymore. Their Repl also sucks, create a new file, add some contact inside it, try to edit it, and you will lose the content inside it. I don't think you should also talk about these bad parts too, you don't want people to go learn these tools and later they realize that the tool actually sucks.
A correction: In the repl to reproduce the error, create a new file, add some content, then try editing the name of the file. My message may have sounded a little bad/wrong/negative/rude, I guess that was because I was frustrated with all of the problems I have to deal with Svelte. Sorry if it made you feel bad/sad. English is also not my first language, so things may have sounded a little rough.
Somebody is talking about documentation! Let me rant as well. In my opinion many frameworks have horrible documentation. Even the highly praised Sveltekit documentation is still below standards. Sniffing the internet for solutions or explanations brings nothing. Developers assume you can guess what they are talking about. This problem has haunted me for years and delayed my growth. At some moment I felt like a complete dumbass, as if it was my incompetence. The last few years I came to realise that it was not me, but just developers creating frameworks with an abstract of what it can do and just little documentation. What is even worse is that many RUclipsrs praise these frameworks and show what they made with it which doesn't help, because it makes you eager to try and all that you succeed in doing is npm installing and struggle to get anything to work. I know that coding is a trial and error process, but it sure doesn't help you to get productive, and from what I understood from these frameworks it supposed to do just that, getting productive. Not trying to be ungrateful for what we already have and maybe my view on this isn't righteous, but nonetheless this is something that has really bothered me and still is bothering me more than I hope for.
I recommend you read JavaScript: The Definitive Guide, 7th Edition by David Flanagan (I'm not being ironic). Often I've seen developers trying to "trial and error" various frameworks without having a good foundational knowledge of how javascript works, which often leads to frustrations similar to what I see in your comments.
I've worked as a programmer since 1974 and IMHO type definition and checking is overrated. But where it is useful it should not be part of a particular programming language or framework. Both definitions and checks should be in an independent Interface Definition Language. Remember that good old jsDoc is a good way to describe interfaces of all kinds. And with a little bit of effort you can convert the interface definitions to very reliable type checking. I never understood why so many people are trying to re-invent the wheel... Just my thoughts...
I really disagree with your assertion that this isn't a react problem. This is *absolutely* a react problem and not a typescript problem. You even gave counter-examples by way of Astro. I, myself, use typescript all the time for node projects that don't involve any front-end at all. I think it's a mistake to tightly couple Typescript and React/Vue/Svelte, or any other front-end framework. Are they significant stakeholders in the Typescript ecosystem? Absolutely (though, the fact that React isn't even written in typescript highlights my point in an ancillary way), but they are not the be-all-and-end-all or even strong indicators of the zeitgeist of typescript as a whole. I'm willing to bet this is more a reflection of your usage of typescript (which is totally valid) rather than the state of typescript overall.
@@JamesQQuick - Huh? Obviously you're aware TypeScript exists on literally over a dozen frameworks. Your whole video should be aimed towards the React team at facebook, not its users.
It's not just React. That just happens to be the example I used here. I'm also not targeting users. I'm just saying overall TypeScript can be hard to impliment sometimes when the documentation across any use case is not ideal.@@jonathangamble
Nice! I will say TypeScript has definitely gotten more and more supported with frameworks over the last couple of years. Glad to hear the same with Vue!@@cat_copilot
Type script will become supper difficult when you start writing cyrried functions. You need to type so much use recuursions inside typescript... just to do simple stuff
Such a strange point of view you are expressing. You'll never get anything working if you blame the wrong thing. And I'll never understand why so many have been sucked into to the React bandwagon. There are so many better tools out there, and the developers, who do their work for nothing, invest the time and effort into making good supporting infrastructure. Isn't it strange that the core react developers are getting paid money by big companies to do their work, and look at what a poor job they do according to you. Dump React, embrace typescript and well engineered open source projects, and your life will better.
I'll make this short and sweet. Learn to rely on go to definition to discover any typings associated with the library in question. Always do this before searching the web. Typed libs are essentially self documenting.
I've also just found myself relying on this now. Code will never lie but the internet might.
Being a typescript user I think it's one of the basic skills to find the appropriate types via navigating symbols/type definitions. Any modern IDE/LSP for any modern typed language supports this kind of stuff
I think it's more of an issue to a beginner rather than any intermediate or advanced TS dev or any typed language dev
The tools definitely make a big difference
AI tools like Copilot or Codeium can help with this, as they often suggest commonly used types
you don't have a typescript problem you have a problem creating a function before checking what the prop requires.
you missed the point my dude
you don't have heart disease you just happens to have a heart which has a problem.
@faridguzman91 what was the point, that some developers don't know everything?
I feel like there should be a more obvious way to reverse figure out the types
@@JamesQQuick maybe we need a vscode plugin that helps to create a function for a prop that auto fills in the prop requirements.
TypeScript did provide the answer, through tooling, which I think is the appropriate way for TypeScript to be involved in finding the answer.
From a web documentation standpoint, you wouldn’t expect the JavaScript site to provide answers for TypeScript, just because TS extends concepts of JS. The TS team can’t be expected to keep documentation on all the different frameworks built on TS, or that can be used with TS.
I also think some of the onus falls on the developer, to not just think of TypeScript as “JavaScript with types”, but to adapt their approach to development to really lean into the features, concepts, and workflow of the language they’re using.
Also, when I have a question like this, and don’t feel the tooling is helpful, it’s usually quickest to ask ChatGPT; you get an answer tailored to your specific question, and you can ask clarifying follow-up questions:
Q: What’s the typescript event type for a mouse event in react?
A: In React, when using TypeScript, you can type your mouse event handlers using the `React.MouseEvent` type. You can specify the type of element the event is attached to, for example, a button or a div:
```tsx
function handleClick(event: React.MouseEvent) {
// ...
}
return Click me!;
```
Here are some of the commonly used mouse events and their types in React with TypeScript:
- `onClick`: `React.MouseEvent`
- `onMouseDown`: `React.MouseEvent`
- `onMouseUp`: `React.MouseEvent`
- `onMouseMove`: `React.MouseEvent`
- `onMouseOver`: `React.MouseEvent`
- `onMouseOut`: `React.MouseEvent`
- `onMouseEnter`: `React.MouseEvent`
- `onMouseLeave`: `React.MouseEvent`
In the above types, `T` refers to the type of HTML element the event is attached to, like `HTMLButtonElement`, `HTMLDivElement`, etc.
But chatgpt is from 2021 I think. And the types would be better comes from react doc
As developing JS for 20+ years, I think all types are overhyped.
I build JS long before TS, also using event handlers.
You don't have to need the type hinting for everything, especially for basic JS and Browser methods, just check e.g. MDN, and debug what you receive.
The types you are using are not always correct, and you can pick the wrong type without knowing it, till something weird happened.
I agree with the statement that this isn't a TS problem. TS is set up to be used with any framework, but at the end of the day it is the job of the maintainers of the framework to type everything properly and provide the documentation. Therefore this isn't an ecosystem problem - it is a problem at the product level of whatever tool you are using.
Yeah I still consider that to be the ecosystem. Think we agree here. Just semantics lol
I've been using JavaScript for over 1.5 years. I dread using TypeScript because you have to set up TypeScript. Or if you use TypeScript for Vite you get this weird templating and it is much different from the standard TypeScript implementation. BUT lately I've been checking out the job market for JavaScript and compared it to TypeScript and there are 3 times more TypeScript jobs over JavaScript! I guess I am going to have to bite the bullet and just suck it up and learn TypeScript. I guess if you are familiar with languages like Kotlin TypeScript shouldn't be so different.
thats why i like Angular and Angular material. Everything nicely documented and typed and overall very powerful. with react you need to collect all your packages first and search every piece and part you need. with angular you get most of it out of the box and documented at one place.
Typescript still over JS at any time.
Angular 🤢
@@siya.abc123 you probably nevee used it. it is still top 3 if not number 1 used framework in business applications andin my opinion the most powerful and structured one
Angular was really ahead of the game by being the first to include typescript by default
@@JamesQQuick yep and it is still one of the best frameworks.i love it personally because of all the features, structure and modules you get with it. it s well organized overall. for some too much overhead and functionality maybe.
Yeah I think that's the general struggle is the overhead. There's more to it initially than there is with React, Vue, Svelte, etc. It's come a long way too though!@@mxz2024
So often in Typescript you find yourself doing type gymnastics to get the basics working. I think the Sveltkit JSdocs makes the whole flow a much better DX. Certainly for rapid prototyping.
I haven’t used it myself but I’ve heard people and products are enjoying it!
Very helpful to know. Thank you James.
I thought everyone knew this "trick", wouldn't be possible to work with TypeScript otherwise pretty much 😅
I just hope I get some kind of documentation when I hover over things, and found out that way lol Flutter/Dart would even take you to the source code of what you hovered over.
Haha yeah idk I guess I just missed it
Same, I discovered it pretty quickly just by hovering over a variable (that I wrote) with a correctly inferred type, then figured it should work on things imported from libraries too
Sometimes mouse hovering doesn’t work pretty good because types can be messy
In such a case solution is to Type[“property”] Please don’t blame the language or the libraries. When u have more experience in TS u will realize there can be tons of types in a code base. It is really hard to provide documentation for all of them. That is why TS has provided these features and some utility functions.
James, I have to say, I'm really glad that I'm not the only one who is struggling with using TS! Personally, I use it in combination with React, too, and I have the same problems and sometimes, I'm so frustrated that I use Type Any and continue without the help of TS benefits. I also thought that this was always because of my lack of proper knowledge of TS, maybe there is a problem more on the React side. Thank you very much for the great video :-). I have a question, is there any chance you will create a video (or videocourse) using typescript, especially in combination with React? Thanks!
Thanks for sharing! And yes you’re not alone! I’m working on some nextjs content that will use typescript so stay tuned :)
What browser are you using? Love the simple look without address bar!
It’s the Arc browser. Pretty cool!
This is great... there are times when there's still no intellisense or proper documentation, so in those cases I log out the parameters to the console to see the type of object I'm working with and that will often help to type the signature.
Without intellisense I’m lost lol
Not knowing Code editor is problem also. to hover or ctrl + click, to navigate to type definititions. It is two source maintainence to have docs with the types, because you can access as pro ts dev, through type definitions every part..
Very true!
I still think it’s a react documentation issue, not a typescript issue. What’s the typescript team gonna do, force the react team to update their documentation? Additionally, is the react documentation open source, I wonder if there’s an issue open for it
I cannot understand how anyone has problems using TypeScript in 2023, everything you need is in the editor. Just don't use anything that doesn't provide full types for everything, it's 100% not worth it anyway, as the devs don't value quality. I am using TypeScript for years and there is a reason why the usage of TS has surpassed JavaScript. TS is the default.
PS: I don't think modern documentation should have a TS/JS toggle, it should just be TS at this point.
I have been using TypeScript since 2016, but now I increasingly feel its historical mission is nearing an end. The downsides of TypeScript are clear: it increases compilation time and debugging difficulty, requiring source maps. Moreover, compiling with pure JavaScript libraries often leads to a plethora of inexplicable errors. Additionally, new versions of TS frequently are not backward compatible, and using third-party libraries often brings a lot of trouble. Sometimes, you spend hours just to make the compilation work. My initial intent for using TypeScript was for interface checking, but now that can be achieved with IntelliSense too. I hope the next generation of ECMAScript will natively support interface type definitions.
Can we open source a type definition documentation for React, next, etc. It will serve as a go-to utility for quick solution. Who's down with this idea? Preferably someone who knows a thing or two about docs and Technical writing. I can scaffold a website. The structure and presentation will have to be deliberated.
Yeah the struggle is real, right now am struggling with import svgs as ReactComponents because I create my app using vite. Searched the internet which told me to use the vite-svgr-plugin but still Typescript is yelling at me. Then I searched some more and saw other say I have to use d.ts file to recognize svgs but still Typescript is not listening.
lol TypeScript struggles are the worst
TypeScript examples in docs are nice, but when writing code in IDE there shouldn't be a need to google "What type does X expect", that's the whole point of TypeScript Language Server. TypeScript code is self-documenting, to a degree where you can actually generate library documentation from code automatically.
Thanks for the video, a good reference to show somebody who's not used to this workflow.
Yeahh! Glad you enjoyed it
I think we've all been at this point in our early React+TypeScript journeys! I think the main reason could be that React itself doesn't have the types bundled in and they have to be maintained by DefinitelyTyped (at least, IIRC). Regarding the generics as well it would also be good to have a source somewhere of each element and what React thinks it is e.g. doesn't have a matching HTMLSectionElement, so I find myself reverting to just HTMLElement with no idea if that's correct or there's something more suitable.
Agreed! Thanks for watching
No typed language will guarantee type safety. You can write code in Java or C# which lacks type safety as well. This is not a TypeScript problem. It is a programming problem in general where developers don’t define types properly or don’t provide the proper types to others. You could call it an "ecosystem" problem, but it certainly isn't the language"s fault. Blame the craftsmen, not the tool.
7:32
Developers defined types properly, which was demonstrated in the video.
RUclipsr problem they need a title
I usually define the function inline just to get the types inferred automatically, and then extract the function if necessary.
Yeah several people on Twitter mentioned that. Nice!
Thanks for this, informative.
Glad you thought so!
Instead of asking someone else to improve their documentation, you should submit a PR when you find something that needs improving. You sound like you know exactly what you’re looking for in the docs so I think you might be the perfect contributor to help them improve!
I do have to say though, this has absolutely nothing to do with Typescript or “the ecosystem”, this is squarely a React documentation shortcoming (although I’d check the actual official React docs before even going as far as to say that). Good news is you can personally do something about it! 😉
This is a typical situation when no one cares about the documentation, because the most important thing is to make a new release. But imagine if the builders were just as excited about the new floor, but at the same time forgot to build a staircase.
Documentation is hard to do right but makes such a big difference
@@JamesQQuick It’s also difficult to imagine a building without part of the stairs, where everyone falls down, but at the same time pretends that everything is fine.
You can get TypeScript to tell you what type it should be by passing the function to an event handler spot with the wrong type specified. Just don't leave it as default any or you won't get that. Probably a good argument here for not having arguments be any by default.
Yo can you use typescript without react?
Only if you have a special token lol
🤘Great info and some very valid points ~ thanks
Glad it was helpful!
then why don't you search in the react documentation directly? use the right tool for the job
Discoverability is a significant component of success for any given framework/tool. Even giong directly to the React docs, I find it hard to find exactly what I'm looking for
@@JamesQQuick not sure how true what you say is,
have you ever tried the aws docs?
you're definetely right, it should be better for you from a product perspective, that's factual,
now, you want to be a developer, you get paid for it, it's your job to get things done and to do the research,
therefore, i don't agree
Fair enough. Thanks for sharing your thoughts@@usher-p
if typescript didnt exists you still be searching random articles and reading though api docs to figure out what the shape of the handler is suppose to look like, and you have to do this for each and every different type of handler you would use and every property and method on that component. now its just a mouse hover and control+click away right in the IDE.
we should do away with all type systems and just raw dawg all code and spend all day chasing undefined bugs, a lot more productive imo
Bahaha don’t about that last part
thank you
Yo aprendí desde el minuto 1 que en React debes poner el ratón encima para saber qué tipo de evento es. Aplicar Redux en React con Typescript sin redux-toolkit y tiparlo todo bien es una pesadilla. Pero quien no usa redux-toolkit hoy en día?
Aunque sea más codigo, y la verdad es que con React puede hacerse un poco pesado usar Typescript, en el backend se agradece muchísimo.
Y en React a fin de cuentas también.
Porque sin Typescript muchas veces tienes errores en React que no sabes ni de dónde vienen.
Glacias por compatir tus experiencias!
As a tip: Html method almost always have a generic version to type the input argument!
Not sure what you mean html method?
If anything, this is more of a VS Code intellisense issue, not a Typescript issue.
Maybe there’s some more discoverability they could add
React is not typescript, in fact I don't like react and even less when used with TS. Angular is a much better technology with it.
Can't agree with you more!
Nice! Any specific frameworks you’re using typescript with?
@@JamesQQuick Just React. In so many cases of mine, I just started a project with TS but ended up abandoned it lol.
haha gotcha. Yeah TypeScript can be tricky to get right in different frameworks@@bushigi5913
Will never understand how people can say things with such conviction and authority when there is a clear lack of knowledge. That "trick" was just a basic part of using typescript that every user should understand
With all due respect. Not particularly a fan of TS but surely you could have inspected the pseudo event object , by perhaps just triggering the event? click , this is neither TS fault nor React fault. React is not a TS library, and TS cannot account for all the solutions present past and future. But I do get your point, sometimes tools that are meant to speed things up under a false premise end up consuming critical time through their implementation.
Yeah, I think it's really easy for you (and many others) to talk about how obvious it is to have done that, but the reality is that my perspective has also been shared by lots of other people too. Some things are obvious to some and not for others. Because of that, I think it's still something to address. Thanks for adding your perspective!
Thanks James. Please submit a PR to update the react docs with this information.
My Problem with Using Automobiles in 2023 - There are so many potholes on some roads, and road signs aren't as clear or informative as they could be
Seems legit
Ok, I'm calling it. Skill issue, lol
Bahaha fair enough
I thought its a common skill you unlock when working with typescript for quite sometime 😂 just hover or ctrl+click, don’t worry you’ll get there james lol
Dude, you can't use TypeScript inside the template part of a Svelte component. It took them a long time to add that toggle to the docs. There is no versioning for the documentation, meaning what you were just browsing is old now, you don't even need to import the type anymore. Their Repl also sucks, create a new file, add some contact inside it, try to edit it, and you will lose the content inside it. I don't think you should also talk about these bad parts too, you don't want people to go learn these tools and later they realize that the tool actually sucks.
In Svelte you can use on:input, create a function for it, and you won't get any type safety for it. TS will complain that the even target may be null!
Thanks for calling those out.
A correction: In the repl to reproduce the error, create a new file, add some content, then try editing the name of the file.
My message may have sounded a little bad/wrong/negative/rude, I guess that was because I was frustrated with all of the problems I have to deal with Svelte. Sorry if it made you feel bad/sad. English is also not my first language, so things may have sounded a little rough.
Not at all. I appreciate you sharing!@@babakfp
I mean, we can keep complaining about how the documentation sucks, or we could start making pull requests to improve it.
That’s a great point!!
Somebody is talking about documentation! Let me rant as well.
In my opinion many frameworks have horrible documentation. Even the highly praised Sveltekit documentation is still below standards. Sniffing the internet for solutions or explanations brings nothing. Developers assume you can guess what they are talking about.
This problem has haunted me for years and delayed my growth. At some moment I felt like a complete dumbass, as if it was my incompetence. The last few years I came to realise that it was not me, but just developers creating frameworks with an abstract of what it can do and just little documentation. What is even worse is that many RUclipsrs praise these frameworks and show what they made with it which doesn't help, because it makes you eager to try and all that you succeed in doing is npm installing and struggle to get anything to work.
I know that coding is a trial and error process, but it sure doesn't help you to get productive, and from what I understood from these frameworks it supposed to do just that, getting productive.
Not trying to be ungrateful for what we already have and maybe my view on this isn't righteous, but nonetheless this is something that has really bothered me and still is bothering me more than I hope for.
Documentation has a long way to go. It’s a big indicator for success with any developer focused product!
I recommend you read JavaScript: The Definitive Guide, 7th Edition by David Flanagan (I'm not being ironic). Often I've seen developers trying to "trial and error" various frameworks without having a good foundational knowledge of how javascript works, which often leads to frustrations similar to what I see in your comments.
I've worked as a programmer since 1974 and IMHO type definition and checking is overrated.
But where it is useful it should not be part of a particular programming language or framework. Both definitions and checks should be in an independent Interface Definition Language.
Remember that good old jsDoc is a good way to describe interfaces of all kinds. And with a little bit of effort you can convert the interface definitions to very reliable type checking.
I never understood why so many people are trying to re-invent the wheel...
Just my thoughts...
I’ve still never used js doc but people seem to love it
I really disagree with your assertion that this isn't a react problem. This is *absolutely* a react problem and not a typescript problem. You even gave counter-examples by way of Astro. I, myself, use typescript all the time for node projects that don't involve any front-end at all. I think it's a mistake to tightly couple Typescript and React/Vue/Svelte, or any other front-end framework. Are they significant stakeholders in the Typescript ecosystem? Absolutely (though, the fact that React isn't even written in typescript highlights my point in an ancillary way), but they are not the be-all-and-end-all or even strong indicators of the zeitgeist of typescript as a whole. I'm willing to bet this is more a reflection of your usage of typescript (which is totally valid) rather than the state of typescript overall.
How is it the ecosystems fault that react docs suck?
React is the ecosystem…
@@JamesQQuick - Huh? Obviously you're aware TypeScript exists on literally over a dozen frameworks. Your whole video should be aimed towards the React team at facebook, not its users.
It's not just React. That just happens to be the example I used here. I'm also not targeting users. I'm just saying overall TypeScript can be hard to impliment sometimes when the documentation across any use case is not ideal.@@jonathangamble
I meant React is part of the ecosystem lol It's just one example@@jonathangamble
Just don't use React
What would you use instead?
@@JamesQQuick Personally, I've been using Vue and Nuxt a lot. The TypeScript DX has improved significantly since the Vue 3.3 release
Nice! I will say TypeScript has definitely gotten more and more supported with frameworks over the last couple of years. Glad to hear the same with Vue!@@cat_copilot
all pro devs are kinda fed up with TS and switch back to JS
Haha I won’t go back. I still love it but there are times where it frustrates me
Pro devs on reddit?
NOT ONLY IS TYPESCRIPT Exceedingly ugly! It also pollutes the code base
Quote from DHH
Yeah this was very painful 😅
Thanks for always being there for me :)
@@JamesQQuick My pleasure, I have fun even if things don't work right the first time 😊
You keep streaming, I keep coming 😁
Type script will become supper difficult when you start writing cyrried functions. You need to type so much use recuursions inside typescript... just to do simple stuff
yeah it can escalate quickly lol
Such a strange point of view you are expressing. You'll never get anything working if you blame the wrong thing. And I'll never understand why so many have been sucked into to the React bandwagon. There are so many better tools out there, and the developers, who do their work for nothing, invest the time and effort into making good supporting infrastructure. Isn't it strange that the core react developers are getting paid money by big companies to do their work, and look at what a poor job they do according to you. Dump React, embrace typescript and well engineered open source projects, and your life will better.
isnt it better to use Any in this case then to ditch Typescript as a whole?
If you're the only one coding on the project, you do you. But once you've used any, you should be very careful about having set a precedent.
Using any in a case like this is same as using JavaScript haha
Yeah I think the precedent is a big deal with a team. Don’t want any to be the dramdard
@@MaxProgramming not really
@@Ayoubased Almost
lol...YT tech channels promoted TS and finally they couldn't hold the truth.
Don’t get me wrong I still love it!
Very informative. Thanks, James.
{2023-10-24}
Thank you!!