与Typescript互动：使用Typescript可以代替propTypes定义吗？

Question

I'm new to Typescript and after reading some related articles it seems that by using Typescript in React, propTypes definitions are no longer needed.

But by checking some of the most populars React Component Libraries projects

like Material-IU :

• /packages/material-ui/src/Button/Button.js
• /packages/material-ui/src/Button/Button.d.ts

or Semantic UI React

• /src/elements/Button/Button.js
• /src/elements/Button/Button.d.ts

or React Toolbox

• /components/button/Button.js
• /components/button/Button.d.ts

...it seems some big projects are using both. So, i'm a bit confused about this. And i don't really get the purpose of these *.d.ts files

Why are they using both? What is the purpose of the *.d.ts files? How does this fit in a react development workflow?

My actual idea about this this is that:

• *.d.ts should contain the types for the component's props
• typescript will launch compilation errors if some prop is receiving a wrong type of data
• the React component definition can avoid defining the propTypes (as this is handled now by Typescript in a different file)

Is this correct? Can anyone shed some light on this? :)

Thanks in advance!!

Answer 1

The TypeScript definition ( .d.ts ) files define the type information used by the TypeScript compiler, and in many IDEs these files are also used to provide feedback during development. Aside from the definitions provided by vendors, you can use interface s when writing your React components in TypeScript. A common use case is to define the type of the props object.

One benefit of using a interface, as opposed to defining propTypes , is that this code disappears at runtime, so if you pass the right props you don't need to run any type checks in the compiled version of your app.

That said, there are situations where it is still helpful to check the type of props passed to a component at runtime. For example, maybe you are using data from an external API and wanted to make sure that the format is what you expected. In this case, it would make sense to use propTypes .

Also, as rightly pointed out in the comments, the propTypes are useful when the library is consumed by code written in JavaScript, which would use a compiled version of the code that would otherwise lack the type information.