{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/typescript-3-7","result":{"data":{"markdownRemark":{"html":"

Oto jest - TypeScript 3.7. Hurra!

\n

A co tym razem dostajemy?

\n
    \n
  1. Optional chaining - czyli ficzer znany choćby z C#. Dotychczas - aby uniknąć błędu z komunikatem Cannot read property 'x' of undefined - trzeba było explicite sprawdzać, czy dana zmienna jest undefined lub null. Teraz - wystarczy użyć operatora ?., który zrobi to sprawdzenie za nas. Innymi słowy - zamiast
    2. \n
\n
let x = foo === null || foo === undefined ? undefined : foo.bar.baz()
\n

można napisać po prostu

\n
let x = foo?.bar.baz()
\n

Niezłe, co nie?

\n
    \n
  1. Nullish Coalescing - znowu rzecz znana z C#. Jak łatwo przypisać do zmiennej wartość domyślną, na wypadek, gdyby podstawowa ścieżka skutkowała undefined? Dotychczas stosować musiałem sztuczkę z JavaScriptu, tj.:
    2. \n
\n
let model = options.volume || 0.5
\n

Jeśli w obiekcie options nie ma właściwości volume lub jest ona ustawiona na undefined - mogę mieć \"fallback\" do jakiejś tam wartości domyślnej (np. 0.5). Problem jest jednak taki, że ten operator || \"wybiera\" prawą stronę, gdy lewa strona jest \"falsy\",czyli gdy np. ktoś ustawi options.volume = 0, to i tak zostanie wybrana prawa strona, czyli wartość domyślna.\nTen problem rozwiązuje właśnie \"nullish coalescing\" - czyli operator ??. Dzięki temu powyższy przykład można opisać jako:

\n
let model = options.volume ?? 0.5
\n

I w ten sposób problem \"falsy\" wartości po lewej stronie mamy rozwiązany.

\n
    \n
  1. Uncalled Function Checks - ile to już razy zdarzało się, że zamiast wywołania funkcji - użyłem samego odwołania się do niej, zwłaszcza w warunku w ifie. Mam na myśli:
    2. \n
\n
if(user.isAdministrator) {\n    ...\n}
\n

zamiast tego

\n
if(user.isAdministrator()) {\n    ...\n}
\n

Co gorsza, kod w pierwszej opcji będzie się transpilował bez błędu, zawsze zwracając true, no bo właściwość, która jest funkcją zawsze jest \"truthy\". Tak było do teraz. Od wersji 3.7 w powyższej sytuacji dosteniemy błąd.

\n
    \n
  1. \"\"Flatter Error Reporting** - tworząc coś z użyciem React i TS, często zdarza się, że zmieniamy coś w propsach komponentu. W miejscu, w którym z niego korzystamy, po takiej zmianie \"interfejsu\" komponentu, oczywiście pokazać się może błąd. Często jednak ten błąd jest tak bardzo nieczytelny - zwłaszcza, gdy zmiana w interfejsie jest głęboko - jakiś atrybut, do którego przyisujemy obiekt przyjmuje teraz obiekt o lekko innej strukturze. TypeScript 3.7 dostarcza teraz komunikatów bardziej \"spłaszczonych\", tj. konkretnie informujących, że w tym miejscu strutktury zagnieżdżonych obiektów jest \"rozjazd\".
    2. \n
\n

Ja się przesiadam na 3.7 jak najszybciej, a Ty?

\n

PS. Pełną listę zmian można znaleźć tu: https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/

","excerpt":"Oto jest - TypeScript 3.7. Hurra! A co tym razem dostajemy? Optional chaining - czyli ficzer znany choćby z C#. Dotychczas - aby uniknąć błędu z komunikatem…","frontmatter":{"date":"12 November, 2019","path":"/blog/typescript-3-7","title":"TypeScript 3.7!"},"fields":{"readingTime":{"text":"3 min read"}}}},"pageContext":{}},"staticQueryHashes":["3649515864","63159454"]}