Using forwardRef with generics is an absolute nightmare and require a bunch of hacks. Would love that it would just work (actually I would love that forwardRef wasn’t even needed)

IMO, the highest-value thing to be changed (not necessarily "fixed") is Component types: JSX.Element, ReactNode, ReactElement, FC, ComponentType, ComponentElement, ReactComponentElement Totally understand I'm massively oversimplifying the complexity of this (esp. backwards compat), but from a DX perspective, having all of these types exposed is a maddening experience. I would love if there was just a single type exported, something like `ReactComponent` (which somehow, through all these types, does not yet exist...)

Matt - HOC patterns with TS and React are a complete nightmare. And we need to be able to add constraints for children components!

One confusing thing is the amount of types available to describe components, and what happens with them. Whether you're talking about the function (or class) that implements the component, an instance of this class (whatever that means for FCs), the return value when it's invoked, the valid types for children, the render prop pattern..

I'd love to see a video of you fixing this issue and explaining things along the way.

It's long past time Flow was put out to pasture. As an aside, it amazes me that the world's most prevalent front-end library doesn't even ship with its own types. I imagine this is because of their inability to cut ties with Flow.

You're doing an extremely wonderful job, Matt! I can't skip any of your videos since these are all so valuable! You rock!

You really are the TypeScript wizard 🤯

Great initiative and video! As for type improvement suggestions, tweaking the type definitions for memo / forwardRef in order to make them work with generic component props would be pretty sweet.

You really take on all the typescript pet peeves I have! Thank you!

Thanks for making the typescript space better!

3:20 the forwardRef, i was working with react hook form, creating a custom controller and it is totally unusable with typescript

forwardRef, standardized representation of HTML element props, components with/without ref

One thing that I really suffer when using TS with react are the event properties and this one you just mentioned, the ref hook. About the events are that they're not aware of the type of event they might end up using, that's because they happen to suffer from the same as the ref, and that is that they're not aware of which tags and attributes compose them and therefore can't infer the type automatically.

ReactElement is typed in a very weird way, because it takes `` as type arguments. So it takes in the shape of the properties of a component constructor but then passes `any` along for the JSXExlementConstructor, essentially decoupling the element props from the constructor props? Would be much cooler (and intuitive to use!) if `ReactElement` could infer out the property typings of a single generic parameter defining the component type.

That's Amazing! You know what's really annoying? useReducer. It shows errors in such a non-obvious way! Create some redocer that handles complex object. Change some types in handlers, in states or somewhere else. Or mb even in init function. Or Init value. It always (well mb not always, but inconsistency is also bad, innit?) tells some bullshit in error and underlines whole reducer, not the initial values. Sometimes it happend that error in one of handlers, but reducer is still highlighted as errored. Reducer mechanics and errors are so messy in typescript. Sry for my English btw.

another thing that I *think* is a bug in react's types package is that when a component returns undefined/void (which is allowed since React 18) you still get an error when using the component saying that the function can't be used as a JSX expression. So I'm still stuck doing `return null`. Edit: I think the reason this is not that easy to change is due to other users of JSX such as solid which are more strict about stuff like not allowing early returns. Backwardscompatibility shouldn't be the big problem here since you're *supposed* (nobody does, I know y'all have @types/node at 20.x even if you're actually using 16 or 18) the major (and sometimes even minor) versions of types packages with the installed version of the actual library, so users of React 17 should be using @types/react@^17

Discriminated unions of props. I'd love to be able to have an Input component where based on the type prop I pass to it it's going to take a different set of propsz or even just different types on value and onChanfe. You can do this with plain objects using typescripts discriminated unions, but in react this doesn't work well at all. I often end up passing a data prop which has the discriminated union there, but it doesn't feel right.

Off topic : do you have a video or a link that describes the tools and devices (so your setup) you are using to record and mount your youtube videos (cam / microphone / Softwares /../..) ?

From now on I will call you a TS doctor

Step 1: Live vicariously through Pocock Step 2: ...

Matt! This is probably the most annyoing typing problem when using React with Typescript (which is a standard these days imo) If you manage to fix, that'd be awesome!

A few things, the JSX typings are not all properly matched to their respective HTML interfaces, e.g. the details element I believe is one of several that is associated to the wrong underlying element. So speaking of refs, you’ll have to assign a ref of the wrong type because of this! Also, the forwardRef function makes typing higher order components extremely difficult, I can share examples if you like!

I’ve been beating this exact drum for ages!!!

I ran into that exact use ref problem over the weekend

Oh yeah. I've recently had to redefine forwardRef because it was eating my component generics. The solution was on stack overflow and apparently the custom forwardRef definition I'm using uses a feature of ts called something something higher order functions? I think?

Yes! Yes! Yes! Finally, I will not have to suffer this abomanation of typing logic any longer!

I always stumble upon an issue with a comma after generic type in component. For some reason it doesn’t understand that it is type unless you put a comma after this generic type or extend it from somewhere

It's not possible to strongly type 'children' to the specific component type. You can force 'children' to be a primitive type or a component, but not a specific component.

I really wish there was a way to type child components. In plain old HTML, I nest option elements inside of a select element. If I want to replicate this exact same API with a custom "Select" component and a custom "Option" component, I have no way to limit the allowed child components to only be my custom "Option" components. What I can do today is to pass an array of option entries to my "Select" component - but this is far from ideal: Let's say my custom "Select" component can display text options so I accept entries of type string array. Now this changes and I want to be able to show a small image next to the text. So, I have to change the "Select" component types to accept that. Now I want to be able to show a larger image without any text as an option. I have to change the "Select" component again. This sucks... It would be WAY NICER to have a slightly different custom "Option" component (like "TextOption", "TextWithImageOption", "ImageOption" etc.) that can be passed into my custom "Select" component. Adding or changing one of the "Option" component would not affect the internals of the "Select" component. Currently, that's not possible so I only have two options: Accept to not have type safety for my "Option" components (and thus not preventing putting the "MainNavigation" component inside of the "Select" component (for whatever reason this might happen)) or loose the API flexibility

Seems like if you type createContext it requires you to init the context with the type and doesn't allow null

I found this same issue a long time back, I should have tweeted then 😂

Matt, how you are adding the Typescript errors as comments to your code automatically?

I was breaking my head the other day trying to make Component generics a thing together with ForwardRef, AND at the same time being able to do Component.displayName="something" so it's shows when debugging. Couldn't find a solution for this

the forwardRef function is also hard to work with in typescript.

Note to self: 1) fork React 2) `rename js ts *.js` 3) fix errors 4) release brand new, *blazingly fast* Tcaer framework 5) profit

I remember there was a bit tricky to type the useContext with an initial value, can't remember exactly how but it wasn't straight-forward as one would expect.

I would appreciate if TS could trust the JSX a little more. { bar && } name won't be set to bar if bar is undefined. But TS isn't convinced..

With using forwardRef, you have to write component.displayname, otherwise it cannot understand. I dont understans why, eslint starting to error and also, if I have some errors in that component, reacts error handler cannot provide the exact position of error

Ok is that I wishlist? I wish I could enforce children to be a specific component type, eg: can only have . 🤞

Amazing. Will this fix be included as part of ts-reset?

Enabling return boolVar && instead of return boolVar ? : null JavaScript enables to return Boolean so why typescript not?

Something I would like is a generic component. Lets say I am making an element to display a list, any list, maybe it could be typed like this: `const DisplayList: FC JSX.Element }> = ...`

forwardRef, HOC, passing custom components as props.

forwardRef when component is generic is pain and requires casting and lots of hacks.

Not sure if it's about type script but I am a newbie and have problems with ESM or something in that area. Update node-fetch from 2.6.1 to 3.1.x and the code goes nuts about require, it wants import. The issue is that the error message suggests some solutions with adding a type in the package.json with module or commonjs and changing the file from js to mjs or cjs and nothing really seems to work. Maybe I don't understand something really small and fundamental in the move from JS to TS but I want to avoid moving to TS because it's a major change as I see it and the code is not strongly typed. It's a lot of work and I don't have the time to do it. People on the internet say to update to the latest of 2.6 which what I did and it works. What I'm saying is that error messages need to be more helpful...

cloneElement required type omitting Example: const Foo = (props: { foo: string; bar: string }) => ... const BarWithSlot = (props: { action: ReactElement }) => {cloneElement(props.action, { foo: 'baz' })} // "foo" is required to pass even tho BarWithSlot will override it

fix/explore forwardRef types pleaseee

Nice video! One thing that would be cool is to see your PR done to fix this issue so people can know exactly what you did to fix it :)

When using forwardRef, the generics needed for the props and ref are opposite to the arguments, which is small but super annoying.

Generic functions wrapped into memo are broken. I should cast type of memo's result by 'as unknown as typeof MyComponent'

What's the proper way of defining props with React? Is it const Component: React.FC = (props) => or const Component = (props: PropsType) => or something else..

At this point, is it not just better to merge "type" and "interface" or remove on or the other?

no way pog

Honestly, typing the props of a component is a pain. I'd rather have an inferred way with a simple interface than needing something like React.FC and also inferred returns (if this is even recommended) Like can we just make a function with an interface param be a component straight away?

You’re simply a wizard

Ok lets talk about polymorphic component and as or component prop please!!!

Typing children or react element e.g. react.reactNode vs react.element vs react.fc …etc

Compound components that have implicit props are really not great when you add TypeScript into the mix. Right now our workaround is to make all implicit props on the child components optional, but as you can imagine that's far from ideal.

Dynamic forward ref Example: type TypographyProps = ( ({ component: 'span' } & HTMLAttributes) | ({ component: 'a' } & AnchorHTMLAttributes) | ({ component: 'time' } & TimeHTMLAttributes) | ) & { ... } const Typography = forwardRef(({ component: Component, ...props }: Props, ref: /* ??? */) => ( ))

It would be nice to have strongly typed JSX. Rather than JSX.Element for everything

we need higher kinded types

Do you actually get anything done or just fight your tools lol

Why not show us the code you wrote to fix the types?

fix enums!

what does useRef do?

forwardRef should be easier to use, for me it’s never inferring the function argument props and I need to manually pass the generic arguments. forwardRef should also have any as default type for the ref, having a strict type for the ref argument is never useful in my experience

Matt, I have an issue that you might be awesome for. JSX isn't checked in any IDE (not even by ESLint) as HTML. Because it isn't. The problem is that people make many errors and not being aware of it. How difficult (very difficult, I am aware, probably) would it be to have JSX be validated as HTML by TypeScript? Could TS error out when someone puts a inside an ? Could it also bubble up from custom components e.g. asd and throw an error, if that MyButton component renders a button element? I'm seeing many websites with mistakes exactly like that, and it's honestly driving me crazy. Good HTML matters for SEO, accessibility, and many other reasons, and (unfortunately) too many people are simply not familiar of the W3C validator ;) What would your take be? Could TS do this, and do it with good performance?

So happy with Svelte when I see things like this.

That you cannot use "ReactNode" for this: type TitleProps = { value: ReactNode; }; const Title: FC = ({ value }) => { const isString = Object.prototype.toString.call(value) === '[object String]'; if (isString) { return ( {value} ); } return value; };

forwardRef types are a bit annoying too.

Refs are just confusing all-up

CSSProperties don't allow custom propierties, but in TS now they could add support for template literal types now, so `--${string}` should be a valid property

Return type 'Element[]' is not a valid JSX element.

You look younger than in your profile pics

Cool but I need Typescript fixed in Vue

React has been a lost cause the day it was released to the public.

React needs a hard reset

Typescript is the problem. Eliminate that, problems gone

This wasted a lot of time for someone learning react with typescript

we should just stop using react

How to get good at dev? 🥲