PropTypes dans une application TypeScript React

121

Est-ce que l'utilisation a du React.PropTypessens dans une application TypeScript React ou est-ce juste un cas de «ceinture et bretelles»?

Puisque la classe de composant est déclarée avec un Propsparamètre de type:

interface Props {
    // ...
}
export class MyComponent extends React.Component<Props, any> { ... }

y a-t-il un réel avantage à ajouter

static propTypes {
    myProp: React.PropTypes.string
}

à la définition de classe?

reactjs typescript react-proptypes

— Ralph
source

Réponses:

104

Il n'y a généralement pas beaucoup de valeur à maintenir à la fois vos accessoires de composant en tant que types TypeScript et React.PropTypes en même temps.

Voici quelques cas où il est utile de le faire:

Publication d'un package tel qu'une bibliothèque de composants qui sera utilisée par JavaScript brut.
Accepter et transmettre des entrées externes telles que les résultats d'un appel d'API.
Utiliser des données d'une bibliothèque qui peuvent ne pas avoir de typages adéquats ou précis, le cas échéant.

Donc, généralement, il s'agit de savoir dans quelle mesure vous pouvez faire confiance à la validation de la compilation.

Les versions plus récentes de TypeScript peuvent désormais déduire des types basés sur votre React.PropTypes( PropTypes.InferProps), mais les types résultants peuvent être difficiles à utiliser ou à consulter ailleurs dans votre code.

— Joel Day
source

Pouvez-vous expliquer la première déclaration?

— vehsakul

@vehsakul Désolé, pour clarification, si vous écrivez un package qui sera installé par des développeurs qui n'utilisent pas TypeScript, ils ont toujours besoin de PropTypes afin d'obtenir des erreurs au moment de l'exécution. Si votre projet est uniquement pour vous-même / d'autres projets TypeScript, les interfaces TypeScript pour vos accessoires sont suffisantes car le projet ne sera tout simplement pas construit.

— Joel Day

Ceci est un POC qui ajoute des PropTypes à partir d'interfaces dactylographiées au niveau du Webpack github.com/grncdr/ts-react-loader#what-it-does

— borN_free

Je veux un oneOfType - optionalUnion: PropTypes.oneOfType ([PropTypes.string, PropTypes.number, PropTypes.instanceOf (Message)]), - typescript a des types d'union, mais ils ne me donnent pas tout à fait la même chose

— Mz Un

J'ai publié une bibliothèque qui le fait également: github.com/joelday/ts-proptypes-transformer Il est implémenté comme une transformation de compilateur TypeScript et il produit des propTypes précis pour les génériques profonds, les unions, etc. toute contribution serait merveilleuse.

— Joel Day

141

Typescript et PropTypes ont des objectifs différents. Typescript valide les types au moment de la compilation , tandis que les PropTypes sont vérifiés à l' exécution .

Typescript est utile lorsque vous écrivez du code: il vous avertira si vous passez un argument du mauvais type à vos composants React, vous donnera la saisie semi-automatique pour les appels de fonction, etc.

Les propTypes sont utiles lorsque vous testez la façon dont les composants interagissent avec des données externes, par exemple lorsque vous chargez JSON à partir d'une API. PropTypes vous aidera à déboguer (en mode Développement de React) pourquoi votre composant échoue en imprimant des messages utiles comme:

Warning: Failed prop type: Invalid prop `id` of type `number` supplied to `Table`, expected `string`

Même s'il peut sembler que Typescript et PropTypes font la même chose, ils ne se chevauchent pas du tout. Mais il est possible de générer automatiquement des PropTypes à partir de Typescript afin de ne pas avoir à spécifier deux fois les types, voir par exemple:

— afonsoduarte
source

Les types propTypes et Typescript se désynchronisent-ils facilement? Quelqu'un a-t-il une expérience de la maintenance à nous dire?

— Leonardo

C'est la bonne réponse! Les propTypes (à l'exécution) ne sont pas les mêmes que la vérification de type statique (à la compilation). Par conséquent, utiliser les deux n'est pas un «exercice inutile».

— hans

Voici une belle explication sur la façon dont les types statiques peuvent être déduits de PropTypes: dev.to/busypeoples

— hans

Runtime vs temps de compilation n'a pas de sens lorsque vous avez vue cli avec rechargement à chaud et eslint. Ce qui génère des erreurs lors de la sauvegarde.

— Julia

@Julia, hot reload est complètement different de runtime. Même avec un rechargement à chaud, vous n'aurez aucune idée de ce qui sera vraiment retourné par api

— Kostya Tresko le

Je suppose que dans certaines situations désordonnées où le type d'accessoires ne peut pas être déduit au moment de la compilation, il serait utile de voir tous les avertissements générés par l'utilisation propTypesau moment de l'exécution.

Une telle situation serait lors du traitement de données à partir d'une source externe pour laquelle les définitions de type ne sont pas disponibles, comme une API externe indépendante de votre volonté. Pour les API internes, je pense que cela vaut la peine d'écrire (ou mieux, de générer) des définitions de type, si elles ne sont pas déjà disponibles.

A part ça, je ne vois vraiment aucun avantage (c'est pourquoi je ne l'ai jamais utilisé personnellement).

— Tom Fenech
source

La validation des PropTypes a également un sens pour valider les structures de données chargées dymaniquement (provenant du serveur via AJAX). PropTypes est la validation d'exécution, et peut donc vraiment aider à déboguer des choses. Les problèmes produiront des messages clairs et conviviaux.

— e1v