Jesteśmy przyzwyczajeni, że JS jest liberalny, dzięki stosowanemu przezeń typowaniu kaczemu (\"jeśli coś chodzi jak kaczka i kwacze jak kaczka...\"). Innymi słowy - póki nazwy pól się zgadzają, możemy obiekty stosować wymiennie:
\nconst dog = {\n name: \"Rex\",\n age: 3,\n breed: \"German shepherd\",\n}\n\nconst cat = {\n name: \"Filemon\",\n age: 1,\n}\n\nconst sayLoveTo = ({ name }) => {\n console.log(`I love you, ${name}!`)\n}\n\nsayLoveTo(dog)\nsayLoveTo(cat)Gdy jednak do tego wszystkiego dodamy typy, sprawy się komplikują - wydawać by się mogło, że obikety dog i cat (jeśli są różnych typów, np. Dog i Cat) muszą mieć wspólny typ bazowy, żeby można było je przekazać do metody. Okazuje się jednak - że nie:
interface Dog {\n name: string\n age: number\n breed: string\n}\n\ninterface Cat {\n name: string\n age: number\n}\n\ninterface SomeoneToLove {\n name: string\n}\n\nconst sayLoveTo = (someone: SomeoneToLove): string => {\n console.log(`I love you, ${someone.name}!`)\n}Jak widać, nie ma żadnej relacji pomiędzy typami Dog, Cat i SomeoneToLove - i właśnie nie musi być! Wszak TS idzie to w ślad (i musi iść) JS, de facto stosując typowanie kacze.
Taka cecha języka może być niespodzianką i czasami prowadzić do pułapek, ale z drugiej strony w wielu miejscach ułatawia pisanie, na przykład w testach jednostkowych.
\nTen wpis jest częścią serii o TypeScripcie, inspirowaną lekturą książki D. Vanderkama pt. \"TypeScript. Skuteczne programowanie\".
","excerpt":"Jesteśmy przyzwyczajeni, że JS jest liberalny, dzięki stosowanemu przezeń typowaniu kaczemu (\"jeśli coś chodzi jak kaczka i kwacze jak kaczka...\"). Innymi słowy…","frontmatter":{"date":"28 October, 2020","path":"/blog/ciekawostki-typescript-4-typowanie-strukturalne","title":"Ciekawostki Typescript #4 - typowanie strukturalne"},"fields":{"readingTime":{"text":"2 min read"}}}},"pageContext":{}},"staticQueryHashes":["3649515864","63159454"]}