Kurs TypeScript – część 3 #57
Replies: 8 comments 18 replies
-
Dzięki za kurs :) Kawał dobrej roboty! Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Dzięki bardzo za artykuły o typescripcie. Tego potrzebowałem! Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
https://geek.justjoin.it/nowoczesny-projekt-webowy-reactem-typescriptem-przy-uzyciu-cra/ Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
React/Redux + TypeScript :D ! Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
dłuuuugi ten tydzień :-) kiedy 4 cześć :D Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
A o czym być chciał przeczytać? ;) Nikt mi nie odpowiedział :D Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
To ja odpowiem. Przykładowy programik z wykorzystaniem wiedzy przekazanej w poprzednich wpisach. Z wyjaśnieniem co gdzie jak i dlaczego, rozbijając całość na moduły. Takie jakby utrwalenie i podsumowanie tego co już było. Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Mniej informacji a mnie kodu — to zupełnie co innego. Im mniej kodu - tym lepiej ;) Nie widzę powodu, dla którego przy inferencji typu nie mógłbyś spojrzeć na typ tej zmiennej i wiedzieć jak ją możesz wykorzystać — przecież to, że typu nie napisałeś nie oznacza, że go nie ma. Wystarczy najechać kursorem albo wcisnąć jakąś kombinację klawiszy i typ jest widoczny. Jest to bez wątpienia wygodniejsze niż dopisywanie każdego zbędnego i oczywistego Ale oczywiście masz rację mówiąc, że w bardziej skomplikowanych przypadkach raczej na tym stracimy na jasności kodu — wtedy napisanie explicite typu jest jak najbardziej na plus. Ja piszę też wszystkie typy w funkcjach (również zwracany). Uważam, że tak jest czytelniej. Do tematu inferencji typów w TypeScripcie trzeba by jeszcze dopisać jeden post na tym blogu — na temat kompatybilności typów :) Wtedy staje się to jeszcze bardziej ciekawe i przydatne. Przykładowo TypeScript umie samemu wywnioskować typ argumentu w funkcji przekazanej do Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Jeśli używasz zmiennej o konkretnym typie to po co używasz operatora === ? Przecież służy on do upewnienia się że typem jest boolean a to jest pewne bo sam to zaznaczyłeś w argumencie funkcji. Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Operator === służy do porównania wartości i jest preferowany wobec == ze względu na dobre praktyki. Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Do porównania wartości służy ==. Operator === porównuje zarówno wartość jak i typ zmiennej. Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Oba służą do porównywania wartości. Tyle, że == robi to źle ;) W JS w zasadzie nie ma operatora do porównywania samego typu jako takiego. Operator == dokonuje niejawnego rzutowania gdy typy przekazanych argumentów są różne. Mówiąc inaczej, operator == porównuje wartości po uprzednim rzutowanie ich na wspólny typ. Ponieważ sposób w jaki to robi jest często nieprzewidywalny (vide porównywanie pustej tablicy z 0), unika się korzystania z tego operatora w ogóle. Operator === również porównuje wartości, ale nie dokonuje wcześniej żadnego rzutowania. TypeScript nie zmienia sposobu w jaki działają te operatory, i działają tak samo jak w zwykłym ECMAScript. Możesz doczytać o tym więcej na przykład na MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Rozumiem, teraz to logiczne. Dzięki za odpowiedź ☺ Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Co mi po tym, że pisze w typescriptcie skoro i tak będzie to skompilowane do JS. Jak pokazują statystyki brak typów wcale nie zwiększa ilości błędów, ilość błędów w typescript jak i javascript jest niemal taka sama. Rzeczą która mogła by mnie przekonać byłaby np. automatyczna validacja wejścia użytkownika - nie musiałbym pisać validatora bo byłby on automatycznie przygotowany na podstawie moich typów. Całą resztę elementów można uzyskać również w czystym JS. Wystarczy dobry edytor i trochę dodatkowych rzeczy np. eslint a będziemy w stanie pozbyć się tych samych błędów którym zapobiega typescript Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Polecam zacząć czytanie od pierwszego artykułu w serii — tam rozwiane są wszystkie Twoje wątpliwości oraz obalone niektóre mity, które powtarzasz! :) Argumentowanie, że TypeScript jest bezużyteczny, bo kompiluje się do JS-a nie ma sensu i wynika prawdopodobnie z braku zrozumienia działania języków programowania i kompilatorów. Podobnie złym argumentem byłoby, aby nie używać Haskella, bo kompiluje się do bytecode'u — od razu widać jak bardzo pozbawione sensu jest takie rozumowanie, a przecież jest to analogiczne do sytuacji TS->JS. Badania wskazują, że TS jest w stanie wykryć nawet 15% bugów, które przeszłyby niezauważone w kodzie JS[1]. A tak naprawdę więcej, gdyż badanie mówi o TS 2.0, tymczasem aktualna wersja to 3.4 — przez ten czas jeszcze sporo zostało poprawione! Warto też zajrzeć do drugiego badania na ten temat[2]. Nieprawdą jest również, że eslint zapobiega tym samym błędom co TypeScript. Oba narzędzia się uzupełniają i należy używać obu. Warstwa walidacji danych, o której wspominasz, to coś, co nie ma nic wspólnego z typami. W językach statycznie typowanych musisz walidować dane pochodzące od użytkownika tak samo, jak w językach dynamicznie typowanych. Mylenie tych dwóch warstw to powszechny błąd — prowadzący nie tylko do nierozumienia zalet statycznego typowania, ale też do katastrofalnie złej architektury aplikacji. Jeśli chodzi o automatyczne generowanie walidatorów na podstawie Typów (lub generowanie typów z walidatorów) to oczywiście jest to możliwe i całkiem powszechne. Nie ma tu miejsca, abym dokładnie opisywał, więc polecę tylko artykuł[3] oraz wspomniane w nim biblioteki Wracając jeszcze do tematu, jeśli weźmiemy pod uwagę 3 najważniejsze aspekty wywarzania aplikacji, czyli:
To każdy z tych aspektów zyskuje na statycznym typowaniu. Jeśli do tego dodamy kryterium DX (Developer Experience, czyli łatwość, z jaką devom przychodzi praca z kodem oraz ogół satysfakcji z tego) — to nie ulega wątpliwości, że statyczne typowanie jest korzystne zarówno z punktu widzenia interesariuszy i interesariuszek projektu, jak i samych programistów i programistek. Polecam te dwie prace naukowe i biblioteki: Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Poza komentarzem @miszy:disqus polecam sprawdzić także artykuł Erica Elliotta w temacie zwrotu z kosztów używania TS: https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Dzięki! Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Inferencja typów jest trochę zastanawiającym rozwiązaniem. Wydaje mi się, że używając jej, zamiast pisać po prostu typ, kod staje się mniej czytelny. Na przykład: wydaje mi się mniej czytelny, niż const tab1:Array<number|string> = [0, 1, 'lel']; Jak później chcę wykorzystać gdzieś stałą tab1, to w 1. przypadku muszę się głowić, co za typ zostanie tam przypisany przez inferencję typów. W 2. przypadku piszę raz, przy deklaracji stałej, jaki ma typ i później, przy wykorzystaniu jej, wystarczy, że spojrzę, jaki ma ona typ i już wiem, jak mogę ją wykorzystać. Nie wiem, czy dobrze zrozumiałem zagadnienie, może coś poknociłem, wtedy proszę o sprostowanie i wyjaśnienie, dlaczego (poza trochę mniejszą ilością kodu) używanie inferencji typów jest lepsze od samodzielnego definiowania tych typów. Przecież "Nigdy nie spojrzałem na kod i nie pomyślałem: »chciałbym mieć teraz mniej informacji o typach«" :) Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
typie co z tą książką o TS??? Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Będzie niedługo :) Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Rozumiem, że kolejnych wpisów nie będzie skoro skoro tyle czasu minęło od ostatniego. Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Napisałem książkę o TypeScripcie! Wszelkie informacje o niej znajdziesz na stronie https://typescriptnapowaznie.pl Komentarz zaimportowany z WordPressa |
Beta Was this translation helpful? Give feedback.
-
Kurs TypeScript – część 3
Kontynuuję serię wpisów na temat TypeScript. Pisząc poprzedni post złapałem się na tym, że dobijałem już do blisko 1800 słów. Uznałem, że to zdecydowanie za dużo jak na jeden wpis i stąd tak szybko kolejna część ;) W tym odcinku mówię o zaawansowanych typach, aliasach i literałach. Dodatkowo poruszam również…
https://typeofweb.com/kurs-typescript-czesc-3
Beta Was this translation helpful? Give feedback.
All reactions