{"id":9998,"date":"2022-03-10T19:12:15","date_gmt":"2022-03-10T18:12:15","guid":{"rendered":"https:\/\/vived.io\/frontend-thursday-vol-78-to-juz-koniec-typescript-typy-trafia-do-javascript\/"},"modified":"2022-09-19T13:16:31","modified_gmt":"2022-09-19T11:16:31","slug":"frontend-thursday-vol-78-to-juz-koniec-typescript-typy-trafia-do-javascript","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/frontend-thursday-vol-78-to-juz-koniec-typescript-typy-trafia-do-javascript\/","title":{"rendered":"Frontend Thursday vol. 78 – to ju\u017c koniec TypeScript! – typy trafi\u0105 do JavaScript"},"content":{"rendered":"\n

1. To ju\u017c koniec TypeScript! – typy trafi\u0105 do JavaScript<\/h2>\n\n\n\n

No dobra – na razie nie wiadomo czy i je\u015bli tak to kiedy tytu\u0142owe typy trafi\u0105 do JavaScript. R\u00f3wnie\u017c szanse na to, \u017ce ich pojawienie si\u0119 zako\u0144czy \u017cywot TypeScriptu s\u0105 raczej nik\u0142e. Musicie jednak przyzna\u0107, \u017ce uda\u0142o mi si\u0119 przyci\u0105gn\u0105\u0107 Wasz\u0105 uwag\u0119. Wykorzystajmy ten fakt i przyjrzyjmy si\u0119 dok\u0142adniej szalonemy pomys\u0142owi dodania typ\u00f3w do JavaScriptu na jaki wpad\u0142 Microsoft.<\/p>\n\n\n\n

Proposal, kt\u00f3ry zaprezentowa\u0142 Microsoft, dodaje do JavaScriptu sk\u0142adni\u0119 typ\u00f3w bli\u017aniaczo podobn\u0105 do tej znanej z TypeScript. Magiczny trik umo\u017cliwiaj\u0105cy wzgl\u0119dn\u0105 kompatybilno\u015b\u0107 polega na tym, \u017ce interpreter traktowa\u0142 b\u0119dzie typy w ten sam spos\u00f3b w jaki traktuje komentarze – kompletnie je ignoruj\u0105c. Je\u015bli z ty\u0142u g\u0142owy ko\u0142acze si\u0119 Wam my\u015bl, \u017ce kto\u015b kiedy\u015b zrobi\u0142 ju\u017c co\u015b podobnego, to python wykorzystuje typy w bardzo podobny spos\u00f3b. R\u00f3\u017cnica polega na tym, \u017ce python udost\u0119pnia cz\u0119\u015b\u0107 metadanych o typach w runtime, natomiast JavaScript mia\u0142by pozbywa\u0107 si\u0119 ich kompletnie.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

To, \u017ce typy b\u0119d\u0105 ignorowane przez interpreter nie oznacza, \u017ce my deweloperzy nie skorzystamy z ich obecno\u015bci. Podobnie jak ma to miejsce przy korzystaniu JSDoc, tak i tutaj do IDE i narz\u0119dzi deweloperskich mo\u017cliwe b\u0119dzie podpi\u0119cie type-checkera, kt\u00f3ry ostrzega\u0142 nas b\u0119dzie przed b\u0142\u0119dami. Cz\u0119\u015b\u0107 deweloper\u00f3w twierdzi r\u00f3wnie\u017c, \u017ce samo dodanie typ\u00f3w sprawia, \u017ce kod jest znacznie czytelniejszy. Ja osobi\u015bcie mocno si\u0119 z nimi nie zgadzam, bo typy bez podpi\u0119tego type-checkera s\u0105 dla mnie oczywistym strza\u0142em w kolano.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Warto zwr\u00f3ci\u0107 r\u00f3wnie\u017c uwag\u0119 na r\u00f3\u017cnice pomi\u0119dzy proponowanym formatem, a znanym ju\u017c JSDoc. Po pierwsze proponowany przez Microsoft format jest znacznie zwi\u0119\u017alejszy i czytelniejszy ni\u017c JSDoc. Po drugie mo\u017cliwo\u015bci JSDoc s\u0105 mocno ograniczone (za jego pomoc\u0105 ci\u0119\u017cko jest zdefiniowa\u0107 chocia\u017cby generyki) i nowy format ma pozbywa\u0107 si\u0119 tych ogranicze\u0144.<\/p>\n\n\n\n

\/**\n * @param {string}  p1 - A string param.\n * @param {string=} p2 - An optional param (Closure syntax)\n * @param {string} [p3] - Another optional param (JSDoc syntax).\n * @param {string} [p4="test"] - An optional param with a default value\n * @return {string} This is the result\n *\/\nfunction stringsStringStrings(p1, p2, p3, p4) {\n    \/\/ TODO\n}\n\nfunction stringsStringStrings(p1: string, p2?: string, p3?: string, p4 = "test"): string {\n    \/\/ TODO\n}<\/code><\/pre>\n\n\n\n
Proposal na razie jest dopiero na etapie zerowym, wi\u0119c raczej nie nale\u017cy mocno przywi\u0105zywa\u0107 si\u0119 do jego tre\u015bci. Zanim dotrze do kolejnych etap\u00f3w jego tre\u015b\u0107 zmieni si\u0119 zapewne jeszcze wielokrotnie. Zgodnie z jego tre\u015bci\u0105 do JavaScript mia\u0142oby trafi\u0107 wi\u0119kszo\u015b\u0107 funkcjonalno\u015bci zwi\u0105zanych z typami jakie znamy z TypeScript(w tym generyki i union oraz intersection types!). \u0141atwiej b\u0119dzie wi\u0119c wymieni\u0107 funkcjonalno\u015bci,  kt\u00f3re nie b\u0119d\u0105 wspierane, a s\u0105 to enumy, namespaces, parameter properties oraz JSX. No c\u00f3\u017c, nie mo\u017cna mie\u0107 wszystkiego.<\/p>\n\n\n\n
Przegl\u0105daj\u0105c opinie deweloper\u00f3w na twitterze i reddicie nie spos\u00f3b nie odnie\u015b\u0107 wra\u017cenia, \u017ce spo\u0142eczno\u015b\u0107 jest wr\u0119cz zakochana w proposalu Microsoftu. Zreszt\u0105 nic dziwnego, bo statyczne typowanie JavaScriptu wed\u0142ug State of JS od lat by\u0142o najbardziej oczekiwan\u0105 przez deweloper\u00f3w funkcjonalno\u015bci\u0105 JavaScript. Ja z przykro\u015bci\u0105 musz\u0119 przyzna\u0107 si\u0119, \u017ce nie p\u0142yn\u0119 wraz z spo\u0142eczno\u015bci\u0105 na tej fali zachwytu. Wsp\u00f3\u0142czesny kod aplikacji klienckich bezwzgl\u0119dnie wymaga transpilacji i minifikacji, kt\u00f3ra sprawi, \u017ce typy znikn\u0105. Na usprawnieniach mogliby\u015bmy skorzysta\u0107 w trakcie developmentu, ale dost\u0119pne ju\u017c dzi\u015b source mapy zaspokajaj\u0105 moje potrzeby. Do tego z typ\u00f3w w JavaScript nie skorzystaj\u0105 najwi\u0119ksze dost\u0119pne frameworki, bo te albo wykorzystuj\u0105 JSX, albo wymagaj\u0105 kompilacji, albo nawet wymuszaj\u0105 korzystanie z TypeScript. Typy w TypeScript oka\u017c\u0105 si\u0119 wi\u0119c przydatne w niewielkich projektach, kt\u00f3re nie wymagaj\u0105 kompatybilno\u015bci wstecznej przegl\u0105darek.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Nie zrozumcie mnie \u017ale – nie jestem przeciwnikiem typ\u00f3w w JavaScript. Z pewno\u015bci\u0105 znajd\u0105 one swoje nisze, takie jak na przyk\u0142ad aplikacje serwerowe, w kt\u00f3rych nie liczy si\u0119 rozmiar wynikowych plik\u00f3w. Ja po prostu nie potrafi\u0119 si\u0119 nimi zachwyci\u0107, bo wszystko czego<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Jak ju\u017c wspominali\u015bmy proposal jest na razie na etapie zerowym i Microsoft ma zamiar przedstawi\u0107 go TC39 Meeting na najbli\u017cszym spotkaniu. Patrz\u0105c na reakcj\u0119 spo\u0142eczno\u015bci proposal ten raczej trafi do kolejnych etap\u00f3w. Znaj\u0105c jednak tempo proces\u00f3w TC39, to typy do oficjalnej specyfikacji trafi\u0105 najwcze\u015bniej za kilka lat i to pod postaci\u0105 mocno zmienion\u0105 wzgl\u0119dem zaprezentowanego w tym tygodniu szkicu.<\/p>\n\n\n\n
\u0179r\u00f3d\u0142a:<\/h3>\n\n\n\n
 https:\/\/devblogs.microsoft.com\/typescript\/a-proposal-for-type-syntax-in-javascript\/<\/a>
 https:\/\/github.com\/giltayar\/proposal-types-as-comments\/<\/a><\/p>\n\n\n\n
2. TypeScript 4.6<\/h2>\n\n\n\n
Ostatnie tygodnie w Microsoft musia\u0142y by\u0107 bardzo pracowite, bo opr\u00f3cz wspomnianego w poprzednim akapicie proposala w minionym tygodniu wydany zosta\u0142 r\u00f3wnie\u017c TypeScript 4.6. Ja jak zwykle polecam notatk\u0119 przygotowan\u0105 przez Microsoft, bo standardowo ju\u017c jest ona najwy\u017cszej jako\u015bci. Tych, kt\u00f3rzy oczekuj\u0105 telegraficznego skr\u00f3tu najwa\u017cniejszych zmian, zapraszam natomiast poni\u017cej.<\/p>\n\n\n\n
Jedn\u0105 z ciekawszych nowo\u015bci jest naprawa drobnej niekompatybilno\u015bci pomi\u0119dzy JavaScriptem i TypeScriptem. Ten pierwszy w konstruktorze klasy umo\u017cliwia umieszczenie fragmentu kodu przed wywo\u0142aniem super, pod warunkiem \u017ce fragment ten nie odwo\u0142uje si\u0119 do this. TypeScript do tej pory na etapie kompilacji wymaga\u0142, aby wywo\u0142anie super by\u0142o pierwsz\u0105 akcj\u0105 wywo\u0142ywan\u0105 w konstruktorze. Od wersji 4.6 zachowanie to ma zosta\u0107 usp\u00f3jnione.<\/p>\n\n\n\n
class Base {\n    \/\/ ...\n}\n\nclass Derived extends Base {\n    someProperty = true;\n\n    constructor() {\n        \/\/ previously: error! have to call 'super()' first because it needs to initialize 'someProperty'.\n        doSomeStuff();\n        super();\n    }\n}<\/code><\/pre>\n\n\n\n
Druga interesuj\u0105ca zmiana te\u017c jest w pewnym stopniu napraw\u0105 istniej\u0105cego ju\u017c b\u0142\u0119du. Gdy kompilator sprawdza czy dwa typy mog\u0105 zosta\u0107 do siebie przypisane, to przy osi\u0105gni\u0119ciu odpowiedniego poziomu rekurencji zak\u0142ada on, \u017ce typy s\u0105 kompatybilne. Mimo, \u017ce na pierwszy rzut oka wygl\u0105da to przera\u017caj\u0105co, po g\u0142\u0119bszym zastanowieniu logika ta ma oczywi\u015bcie sporo sensu. Ze wzgl\u0119du na zastosowanie strukturalnego typowanie,  niemo\u017cliwe jest por\u00f3wnanie definicji obiekt\u00f3w, co stanowi wyzwanie w sytuacji, gdy poprzez odpowiednie zastosowanie generyk\u00f3w da si\u0119 zdefiniowa\u0107 klas\u0119 o niesko\u0144czonej definicji. Usprawnienie, kt\u00f3re przygotowa\u0142 Microsoft nie rozwi\u0105zuje ca\u0142kowicie problem\u00f3w strukturalnego typowania, ale sprawia \u017ce TypeScript w niekt\u00f3rych przypadkach b\u0119dzie w stanie wykry\u0107 niekompatybilno\u015bci pomi\u0119dzy dwoma bardzo zagnie\u017cd\u017conymi typami.<\/p>\n\n\n\n
interface Source<T> {\n    prop: Source<Source<T>>;\n}\n\ninterface Target<T> {\n    prop: Target<Target<T>>;\n}\n\nfunction check(source: Source<string>, target: Target<number>) {\n    \/\/ Resolving those types structure will result in an infinite loop. \n    \/\/ Because of that compiler uses depth heuristic\n    target = source;\n}<\/code><\/pre>\n\n\n\n
interface Foo<T> {\n    prop: T;\n}\n\ndeclare let x: Foo<Foo<Foo<Foo<Foo<Foo<string>>>>>>;\ndeclare let y: Foo<Foo<Foo<Foo<Foo<string>>>>>;\n\n\/\/ In TypeScript 4.5 this will work ok. In TypeScript 4.6 compiler will return error\nx = y;<\/code><\/pre>\n\n\n\n
Ostatni\u0105 interesuj\u0105c\u0105 nowo\u015bci\u0105 jest lepsze wsparcie dla typ\u00f3w zale\u017cnych. Co tu du\u017co m\u00f3wi\u0107, ma\u0142a rzecz, a cieszy.<\/p>\n\n\n\n
type Func = (...args: ["a", number] | ["b", string]) => void;\n\nconst f1: Func = (kind, payload) => {\n    if (kind === "a") {\n        payload.toFixed();  \/\/ 'payload' narrowed to 'number'\n    }\n    if (kind === "b") {\n        payload.toUpperCase();  \/\/ 'payload' narrowed to 'string'\n    }\n};\n\nf1("a", 42);\nf1("b", "hello");<\/code><\/pre>\n\n\n\n
Tak jak wspomina\u0142em ju\u017c przy okazji premiery wersji beta TypeScript 4.6, kolejne wydania tego j\u0119zyka od jakiego\u015b czasu ekscytuj\u0105 mnie coraz mniej. Nie odbieram tego jednak negatywnie, bo \u015bwiadczy to o dojrza\u0142o\u015bci jak\u0105 uda\u0142o mu si\u0119 osi\u0105gn\u0105\u0107.<\/p>\n\n\n\n
\u0179r\u00f3d\u0142a:<\/h3>\n\n\n\n
 
Announcing TypeScript 4.6<\/a><\/blockquote>