We've seen a very simple way of defining a component and telling typescript that this component is going
to receive some argument of child props, but there's kind of a downside to this approach.
So in this video, we're going to examine that down side and take a look at another way that we can
tell, TypeScript, about a component that we are creating.
OK, so here's the downside with the code that we have written.
We have told TypeScript, all TypeScript understands right now is that child is going to be a function
that receives an argument of type child props and returns some amount of.
That is all TypeScript currently understands.
Now, that might sound like it is a complete story and it totally describes everything that is going
on, but it really doesn't quite do.
So, you see, here's the problem, TypeScript doesn't actually specifically understand that we are
defining a react component.
You and I, of course, can look at this and say, sure, it looks like a real component to me.
But remember, there are other JavaScript libraries out there that also make use of.
So there might be some other library that would use some exact value like this.
There might be some other JavaScript library that would expect to receive some kind of function.
That returns some amount of sex so tight script cannot just directly assume that we are defining specifically
a react component.
This might be some other kind of component.
Now, why is that relevant?
Why would we care at all?
And does it actually make any difference?
Well, yes, it definitely does.
Here's a little bit of trivia.
Remember, whenever you make use of a component or whenever you define one, you can optionally assign
a couple of different properties to the react component itself.
Properties such as types display name default props or context types.
These different properties get assigned to the component itself.
These are not like props to the component.
They're assigned directly to say, child.
So for example, you would write out something like child display name is whatever.
Right now, TypeScript doesn't know that we are making specifically a react component, so TypeScript
is not really going to understand any of these different properties.
It doesn't know that our component can have a prop practice or default types or display name and so
on.
As a matter of fact, right now, if we just write out ChildNet display name by itself and then hover
over that, we'll get an error message saying that this is a property that does not exist on this.
So that is the shortcoming with this approach right here.
It might appear to us that we are giving TypeScript the full story, but we really aren't.
We are not directly telling, TypeScript, that this really, truly is a component that might have all
the different properties that are actually associated with a react component.
So to fix this, we're going to take a look at a slightly different way of defining a function component
with TypeScript.
I'm going to write out a second example down here.
I'm going to write out Export Consed Child as F.C. See, the name right here doesn't make a difference.
I'm just applying a different name so we do not have two components with the exact same name.
So you can define or name the second component, anything you want to name it.
After I put down the name, I'll then put down a Colin.
React Dot FC.
A set of angle brackets I'm going to put in child props inside their.
And then assign.
Essentially, the exact same components I'll put in color instead of curly braces, I'm going to return
a div.
That prints out that color and you'll notice I no longer have a colon right after that list of arguments
right there or a colon or the child props thing.
So this is another way of defining a function component with typescript, we can take either approach,
but there are a couple of upsides or benefits if you take this style.
Let's first examine what really happens with this line of code right here or what the real difference
is.
By taking this approach, we are now telling TypeScript a couple of different things, we are telling
TypeScript that this is going to be a react function component, specifically because we are saying
that it might be a component.
That means that we might have some additional properties assigned to it, such as types, context,
types, display, name and so on.
We are also telling TypeScript that this component is going to receive a props object of type child
props.
That's what that set of angled brackets right there is doing.
So we get all the benefits of what we had before.
But now we can also work with these different properties on the component itself, such as Propp types,
context types and so on.
If we go back over and write out child as F, C dot, now my autocomplete is going to list out all those
additional properties that are associated with the normal component, such as display name.
So if I put in a child as F.C. display name, I also get that autocomplete.
I don't get any air anymore.
And if I mouseover that, I'm told that this might be a string.
But if we never said it, it also might be undefined.
So this is another way that we can set up a rehab component with TypeScript, which one is best for
you?
It really comes down to whether or not you want to access or make use of these additional properties.
It is definitely not strictly required that you make use of this style of declaration.
Again, it really comes up to you.
And throughout this course, we might make use of both different styles.
Last thing I would mention very quickly, you might see inside of some blog post documentation and whatnot,
rather than writing out just F.C. right here, that is actually an abbreviation for function component.
So you might see some documentation that says react dot function.
Component instead, this is 100 percent identical.
It's just a much longer way of writing this out.
So chances are you usually want to make use of just F.C. unless you want to write out that entire name
of function components.
OK, so just a little bit more on props and typescript, because right here and move on in just a moment.