TypeScript React: Confused about icon: Icon and {...}: Props syntax in component props
I'm working with a Next.js and TypeScript tutorial (https://www.youtube.com/watch?v=djDgTYrFMAY), and I came across this component syntax that I'd like to understand better:
I'm particularly confused about two parts:
1. What's the significance of
icon: Icon?
2. What does }: Props mean at the end of the parameter list?
Would appreciate if someone could break down this syntax!Dave Gray
YouTube
Next.js Full Stack Project w/ Nextjs 15 & React 19
Build a Next.js full stack project with Nextjs 15 & React 19 in this video tutorial series. Our full stack app will include Next.js, TypeScript, Tailwind CSS, ShadCN/ui, Sentry, Kinde Auth, Neon Postgres, Drizzle ORM, and more.
⭐ Use the code "davegray" for 3 months free on the Team plan of Sentry for any new accounts:
- Sentry Homepage: https:...
8 Replies
1. What's the significance of icon: Icon?
Re-naming the object key icon into Icon so it can be used as JSX
<Icon />
1. What does }: Props mean at the end of the parameter list?
It’s assigning a typescript type to the object in the function arguments basically saying that{ icon: Icon, label, href } is of type PropsThank you for your reply! This is mostly what I initially understood as well, but I had assumed that
}: Props was explicitly enforcing that the object must be of type Props. Is that not the case?In way yes, we are "enforcing", so if you add another parameter to the object (let's say you need to add a isActive boolean) your editor will tell you "look the field isActive does not exist in type Props" and so it forces you to add it to the Props type. But the reason we do this mostly is to have autocomplete and types (when you hover for example) when you are working inside the component, specially if your component props are bigger or complex
Ahh okay that makes sense! Thank you for your answer 😁
@akashamba I know it may be a bit outside of asked question, but I wanted to share a bit of TypeScript context: The enforcement is a very loose term in here. Your IDE and compilation process will check if the variables that will be passed in code are of correct types.
This check, however, is not going to happen when the app is actually built and started. You'll have no errors thrown if label and href are not strings e.g. if loaded from file, or from external api. So it's more like IDE forces you to write a code that is type compliant.
Oh I see! So type errors can be caught during build time (which helps check prevent type inconsistency across the app) but not during runtime if, as you mentioned, the href and label are loaded from some source which is out of the app's control
Exactly. If in any case you need runtime validation, you'll have to use something on top of it. E.g.
zod offers that validation and is well integrated with typescript types, which makes it good proposition for extending build-time validation to runtime one.Makes sense, and the most common use case for this would be forms