Components 7 exercises
solution

Specifying Props for React.FC

The solution is to apply a type definition of React.FC to the Button.

This represents a React function component.

/* @ts-expect-error */
export const Button: React.FC = (props: Props) => {
  return {
    ohDear: "123",
  };
};

Removing the @ts-expect-error will show us sever

Loading solution

Transcript

0:00 The solution here is to apply a type definition of React.FC to this button. I'm going to remove this ts-expect-error just so we can see the errors coming up. What's happening here is that we have React.FC, which represents a React function component. There's two things it's going to do.

0:26 Let's actually just remove these props for now. The first thing it's going to do is it's going to yell at me because oh dear string is missing the following property from type ReactElement. Basically saying that you can't return this from a component. If instead, I return something more reasonable like return <div> or something, then it's going to be quiet. It's going to chill.

0:46 If I return again, which is a valid ReactElement, then it's going to relax. There's an issue here, which is now className does not exist on type IntrinsicAttributes. Oh, dear. Props is actually being typed as this empty object here.

1:04 If I try to do props, props here, then this is going to yell at me because React.FC by default doesn't contain any props. It doesn't let you parse any props. How do we tell React.FC to receive some props to tell it that it's propful. That's not a word.

1:20 React.FC, we can actually parse it a type argument. If you comment on this or, sorry, hover over it like that, we can actually go to the type definition. It's got this single letter P, which indicates that it takes some props. They defaulted to an empty object. Weirdly, we can actually parse anything in here, which is gross. Props can actually be a string. This should probably be constrained to an object.

1:47 React.FC props equals props. Then we can actually get all of our inference working beautifully. If we try to return something stupid, it's going to warn us on the correct line. React.FC is a really useful little bit of kit. If we find in definition on it, command-click into it, we can see that the main signature of it is a props. It's also got some context on it funnily enough for legacy reasons.

2:16 Then it's got to return a ReactElement. It also has some other attributes on it, like prop types, default props, and display name. If we take a look at that because we've used React.FC, we can actually get autocomplete on these things. If we're using default props, for instance, then this is going to need to be a partial of props.

2:35 If you're using default props like this, then you can do that. Default props I think is going to be deprecated. React.FC, in my eyes, is losing utility over time. I'm using it less and less. Really, I would probably just say that this is a little bit more ergonomic, just saying props, props like that, how can you beat that in terms of succinctness and conciseness?

3:03 You do need to know about this because you'll probably see lots of code bases where this is written. I wouldn't refactor this out of the code base if it's been consistently put in over time. React.FC, it's a useful tool in your toolkit. You're probably going to see it in the wild.