{"id":16021,"date":"2023-06-09T00:03:29","date_gmt":"2023-06-08T22:03:29","guid":{"rendered":"https:\/\/vived.io\/?p=16021"},"modified":"2023-06-09T15:07:58","modified_gmt":"2023-06-09T13:07:58","slug":"react-jeszcze-blizej-php-i-rewolucja-w-angularze-frontend-monthly-may-2023","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/react-jeszcze-blizej-php-i-rewolucja-w-angularze-frontend-monthly-may-2023\/","title":{"rendered":"React == PHP && NgRevolution – Frontend Monthly (Maj 2023)"},"content":{"rendered":"\n

Zanim przejdziemy do dzisiejszego podsumowania, nale\u017c\u0105 si\u0119 Wam dwa s\u0142owa wyja\u015bnienia. W kwietniu Vived przeszed\u0142 ma\u0142e zawirowania (nic strasznego – zesp\u00f3\u0142 edytorski nadal dzia\u0142a pe\u0142n\u0105 par\u0105, \u017ceby dostarcza\u0107 do aplikacji \u015bwie\u017ce i ciekawe tre\u015bci), a na to wszystko na\u0142o\u017cy\u0142 si\u0119 m\u00f3j prawie miesi\u0119czny urlop (je\u015bli zastanawiacie si\u0119 czy warto odwiedzi\u0107 zachodnie wybrze\u017ce USA, to ja jak najbardziej warto!). W efekcie frontendowe podsumowania znikn\u0119\u0142y z radar\u00f3w na prawie 2 miesi\u0105ce… Teraz wracamy jednak z lekko zmienion\u0105 formu\u0142\u0105. Zamiast kr\u00f3tkich cotygodniowych podsumowa\u0144 mo\u017cecie spodziewa\u0107 si\u0119 odrobin\u0119 d\u0142u\u017cszych comiesi\u0119cznych raport\u00f3w i okazjonalnych wyda\u0144 specjalnych. Mam nadziej\u0119, \u017ce nowy format spodoba si\u0119 Wam r\u00f3wnie mocno jak poprzedni i bez zb\u0119dnego przed\u0142u\u017cania – \u0142apcie kubek ulubionego napoju, rozsi\u0105d\u017acie si\u0119 wygodnie i zapraszamy do lektury!<\/p>\n\n\n

\n
\"\"
Zapami\u0119tajcie, tak wygl\u0105da jedyna s\u0142uszna pozycja do czytania Frontend Monthly <\/figcaption><\/figure><\/div>\n\n\n

React 19 – <\/s> Next.js 13.4<\/h2>\n\n\n\n

Je\u015bli interesuj\u0105 Was nowo\u015bci w React, to najlepiej zrobicie je\u015bli jak najszybciej zaczniecie dok\u0142adnie \u015bledzi\u0107 co dzieje si\u0119 ekosystemie Next.js. Zesp\u00f3\u0142 Reacta skupia swoj\u0105 uwag\u0119 g\u0142\u00f3wnie na rozwoju React Server Components(RSC). Ze wzgl\u0119du na to, \u017ce funkcjonalno\u015bci tej nie mo\u017cna u\u017cywa\u0107 bez frameworka, Meta rozpocz\u0119\u0142a \u015bcis\u0142\u0105 wsp\u00f3\u0142prac\u0119 z Vercelem (firma matka Next.js) i to w\u0142a\u015bnie Next.js jest aktualnie pionierem wdra\u017caj\u0105cym kolejne nowo\u015bci. Wydany pocz\u0105tkiem maja Next.js 13.4 stanowi w tej kwestii spory krok milowy, bo nowy router oparty o React Server Components staje si\u0119 oficjalnie rekomendowanym rozwi\u0105zaniem. Zanim przejdziemy do rzeczy, cofnijmy si\u0119 o dwa kroki i przypomnijmy czym s\u0105 React Server Components i jak dzia\u0142a nowy routing w Next.js.<\/p>\n\n\n

\n
\"\"
\u0179r\u00f3d\u0142o: https:\/\/twitter.com\/thekitze\/status\/1638927506723033088<\/a><\/figcaption><\/figure><\/div>\n\n\n

React Server Components<\/h3>\n\n\n\n

React Server Components zosta\u0142y po raz pierwszy zaprezentowane przez Dana Abramova w grudniu 2020 roku. W swoich za\u0142o\u017ceniach koncepcja jest prosta – cz\u0119\u015b\u0107 z komponent\u00f3w b\u0119dzie renderowana po stronie klienta, a cz\u0119\u015b\u0107 po stronie serwera. Dzi\u0119ki jasnej separacji mi\u0119dzy serwerem i przegl\u0105dark\u0105, serwerowe komponenty otrzymaj\u0105 dost\u0119p do nowych API i b\u0119d\u0105 mog\u0142y na przyk\u0142ad bezpo\u015brednio odpytywa\u0107 baz\u0119 danych, czy korzysta\u0107 z systemu plik\u00f3w. Deweloperzy b\u0119d\u0105 mogli r\u00f3wnie\u017c przesta\u0107 martwi\u0107 si\u0119 o rozmiar zale\u017cno\u015bci w serwerowych komponentach, gdy\u017c te nigdy nie b\u0119d\u0105 wysy\u0142ane do klienta.<\/p>\n\n\n\n

"use server"\n\nimport db from 'db'; \n\/\/This is interactive client component\nimport NoteEditor from 'NoteEditor'; \n\nasync function Note(props) {\n  const {id, isEditing} = props;\n  const note = await db.posts.get(id);\n  \n  return (\n    <div>\n      <h1>{note.title}<\/h1>\n      <section>{note.body}<\/section>\n      {isEditing \n        ? <NoteEditor note={note} \/>\n        : null\n      }\n    <\/div>\n  );\n}<\/code><\/pre>\n\n\n\n
Architektura React Server Components r\u00f3\u017cni si\u0119 mocno od standardowego podej\u015bcia do renderowania po stronie serwera. Po pierwsze, w standardowym podej\u015bciu, serwer czeka, a\u017c ca\u0142a strona zostanie wyrenderowana. Oznacza to, \u017ce je\u015bli serwer potrzebuje wykona\u0107 powolne zapytanie, to ca\u0142a strona b\u0119dzie \u0142adowa\u0107 si\u0119 powoli. Przy wykorzystaniu React Server Components, szkielet aplikacji szybko trafia do przegl\u0105darki, a kolejne komponenty s\u0105 stopniowo strumieniowe w postaci pseudo HTMLa. Po drugie, w standardowym podej\u015bciu, framework po stronie klienta przejmuje kontrol\u0119 nad aplikacj\u0105, co skutkuje tym, \u017ce wszystkie komponenty by\u0107 przystosowane do dzia\u0142ania zar\u00f3wno po stronie klienta jak i serwera. W przypadku React Server Components kod komponent\u00f3w nigdy nie jest wysy\u0142any do klienta i renderowanie zawsze odbywa si\u0119 po stronie serwera.<\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
React Server Components maj\u0105 te\u017c swoje ograniczenia. Po pierwsze, ze wzgl\u0119du na zupe\u0142nie inny cykl \u017cycia, nie mo\u017cna w nich wykorzystywa\u0107 hook\u00f3w useState<\/code> i useEffect<\/code>. Po drugie, mi\u0119dzy komponentami renderowanymi po stronie serwera i kliena nie mo\u017cemy przechodzi\u0107 ca\u0142kiem swobodnie. B\u0119d\u0105c bardziej precyzyjny, komponenty renderowane po stronie klienta nie mog\u0105 bezpo\u015brednio importowa\u0107 komponent\u00f3w renderowanych po stronie serwera. Mo\u017cliwe jest jedynie przekazanie takiego komponentu jako jeden z props\u00f3w. Pomimo tego, \u017ce na poz\u00f3r mo\u017ce si\u0119 to wydawa\u0107 sporym ograniczeniem, to w ostatecznym rozrachunku nie sprawia to wielu problem\u00f3w.<\/p>\n\n\n\n
Od 2020 roku, zesp\u00f3\u0142 React intensywnie pracuje nad rozwojem React Server Components. Po drodze zmieni\u0142 si\u0119 na przyk\u0142ad spos\u00f3b oznaczania komponent\u00f3w czy spos\u00f3b obs\u0142ugi asynchronicznych operacji. Po 3 latach intensywnego rozwoju, chyba doczekali\u015bmy si\u0119 w ko\u0144cu w miar\u0119 stabilnego API. Je\u015bli jeste\u015bcie g\u0142odni detali dotycz\u0105cy serwerowych komponent\u00f3w, to osobi\u015bcie polecam oryginaln\u0105 prezentacj\u0119 Dana Abramova<\/a> i \u015bwietny blog post z Plasmic Blog w detalach pokrywaj\u0105cy ten temat<\/a>.<\/p>\n\n\n\n
Next.js Page Router<\/h3>\n\n\n\n
Wraz z Next.js 13 zaprezentowany zosta\u0142 nowy model routingu dla Next.js. Wprowadza\u0142 on sporo drobnych, aczkolwiek istotnych usprawnie\u0144. W\u015br\u00f3d nich znajdziemy mi\u0119dzy innymi natywne wsparcie dla zagnie\u017cd\u017conych szablon\u00f3w czy lepsz\u0105 obs\u0142ug\u0119 b\u0142\u0119d\u00f3w i \u0142adowania. Po\u015br\u00f3d nowo\u015bci najbardziej wybrzmiewa jednak fakt, \u017ce nowy router zbudowany zosta\u0142 w oparciu o React Server Components. Oznacza to, \u017ce wszystkie komponenty s\u0105 komponentami serwerowymi, a przysz\u0142o\u015b\u0107 Next.js \u015bci\u015ble zwi\u0105zana jest z przysz\u0142o\u015bci\u0105 React Server Components. Je\u015bli jeste\u015bcie ciekawi szczeg\u00f3\u0142\u00f3w na temat tego jak dzia\u0142a nowy Page Router, to po\u015bwi\u0119cili\u015bmy temu tematowi wi\u0119kszo\u015b\u0107 jednej z edycji naszego raportu<\/a>.<\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Next.js 13.4, Page Router i React Canary<\/h3>\n\n\n\n
Je\u015bli odpowiednio po\u0142\u0105czyli\u015bcie kropki, to zapewne teraz drapiecie si\u0119 po g\u0142owie – Jak to jest, \u017ce Next.js domy\u015blnie zaleca stosowanie React Server Components, je\u015bli nie s\u0105 one jeszcze stabiln\u0105 funkcjonalno\u015bci\u0105? Jest to mo\u017cliwe dzi\u0119ki nowemu kana\u0142owi releas\u00f3w na jakie zdecydowa\u0142 si\u0119 zesp\u00f3\u0142 Reacta. Do wersji Canary trafia\u0107 b\u0119d\u0105 funkcjonalno\u015bci o stabilnym API, kt\u00f3re wydane zostan\u0105 wraz z kolejn\u0105 wi\u0119ksz\u0105 wersj\u0105 Reacta. Dlaczego zesp\u00f3\u0142 nie zdecydowa\u0142 si\u0119 po prostu cz\u0119\u015bciej publikowa\u0107 kolejnych wersji biblioteki? Czasami zdarza si\u0119, \u017ce release zblokowany jest na kilku brakuj\u0105cych funkcjonalno\u015bciach kompletnie nie zwi\u0105zanych z ustabilizowanym w\u0142a\u015bnie API. Dzi\u0119ki nowemu kana\u0142owi releas\u00f3w, spo\u0142eczno\u015b\u0107 szybciej b\u0119dzie mog\u0142a testowa\u0107 nowe funkcjonalno\u015bci, r\u00f3wnocze\u015bnie nie martwi\u0105c si\u0119, \u017ce kolejna eksperymentalna wersja ca\u0142kowicie zepsuje ich aplikacje.<\/p>\n\n\n\n
React Server Actions<\/h3>\n\n\n
\n
\"\"
\u0179r\u00f3d\u0142o: https:\/\/twitter.com\/markdalgleish\/status\/1256800146118959109<\/a><\/figcaption><\/figure><\/div>\n\n\n
Je\u015bli regularnie czytacie nasze przegl\u0105dy, to na pewno widzieli\u015bcie ju\u017c nie jeden mem na temat tego jak React upodabnia sie do PHP. No c\u00f3\u017c, wraz z Next.js 13.4 poczyniony zosta\u0142 kolejny krok w tym kierunku. React Server Actions umo\u017cliwiaj\u0105 wywo\u0142anie funkcji na serwerze i ca\u0142kowicie ukrywaj\u0105 przed programist\u0105 warstw\u0119 komunikacji(innymi stare dobre Remote Protocol Call). Wszystko co musimy zrobi\u0107, to zacz\u0105\u0107 nasz\u0105 funkcj\u0119 od 'use server;<\/code> i voil\u00e0 – kod b\u0119dzie wykonywany po stronie serwera i nigdy nie trafi do klienta.<\/p>\n\n\n\n
import { cookies } from 'next\/headers';\n \nexport default function AddToCart({ productId }) {\n  async function addItem(data) {\n    'use server';\n    const cartId = cookies().get('cartId')?.value;\n    await saveToDb({ cartId, data });\n  }\n \n  return (\n    <form action={addItem}>\n      <button type="submit">Add to Cart<\/button>\n    <\/form>\n  );\n}<\/code><\/pre>\n\n\n\n
Co istotne, React Server Actions maj\u0105 swoje ograniczenia. Po pierwsze, funkcja tego typu musi by\u0107 asynchroniczna. Po drugie, funkcj\u0119 tak\u0105 mo\u017cemy przekaza\u0107 tylko do formularza, albo do hooka startTransition<\/code>.  Co ciekawe, w tej pierwszej opcji formularz b\u0119dzie dzia\u0142a\u0142 nawet kiedy klient wy\u0142\u0105czy po swojej stronie obs\u0142ug\u0119 JavaScript.<\/p>\n\n\n\n
React Server Actions zdecydowanie nie s\u0105 pierwszym podej\u015bciem do RPC w JavaScript. S\u0105 natomiast pierwsz\u0105 implementacj\u0105 zintegrowan\u0105 w frontendowy framework. Je\u015bli uda im si\u0119 opu\u015bci\u0107 wersj\u0119 alpha, to na pewno stan\u0105 si\u0119 ciekawym rozszerzeniem dla React Server Components.  <\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Angular 16<\/h2>\n\n\n\n
Nowe wersje Angulara pojawiaj\u0105 si\u0119 punktualnie co p\u00f3\u0142 roku niczym japo\u0144ski Shinkansen i w maju \u015bwiat\u0142o dzienne ujrza\u0142 Angular 16. Patrz\u0105c na kilka ostatnich wersji frameworka, nie spos\u00f3b nie zauwa\u017cy\u0107, \u017ce jego rozw\u00f3j znacznie przy\u015bpieszy\u0142. Co wa\u017cne, zesp\u00f3\u0142 stoj\u0105cy za frameworkiem wreszcie zacz\u0105\u0142 wys\u0142uchiwa\u0107 problem\u00f3w spo\u0142eczno\u015bci. Z wersji na wersj\u0119 rozwi\u0105zywane s\u0105 teraz najwi\u0119ksze bol\u0105czki deweloper\u00f3w – i to nawet takie, kt\u00f3re towarzyszy\u0142y frameworkowi ju\u017c od zarania dziej\u00f3w. Angular 16 kontynuuje ten trend i proponuje rewolucj\u0119 jakiej Angular jeszcze nie widzia\u0142.<\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Signals<\/h3>\n\n\n\n
Angular zosta\u0142 zbudowany na fundamencie stosunkowo niewielkiej biblioteki zone.js<\/code>. Jest ona odpowiedzialna za monkey-patching asynchronicznych metod przegl\u0105darki. Za ka\u017cdym razem kiedy kt\u00f3rakolwiek z takich metod jest wywo\u0142ywana, zone.js<\/code> powiadamia o tym Angulara, a ten stara si\u0119 okre\u015bli\u0107 czy stan aplikacji uleg\u0142 zmianie. Dzi\u0119ki takiej architekturze, Angular w stosunkowo „magiczny” spos\u00f3b potrafi od\u015bwie\u017ca\u0107 warto\u015b\u0107 zmiennych w interfejsie u\u017cytkownika.<\/p>\n\n\n
\n
\"\"
Based on famous: https:\/\/xkcd.com\/2347\/<\/a><\/figcaption><\/figure><\/div>\n\n\n
Jak to zwykle bywa, magiczne rozwi\u0105zania maj\u0105 r\u00f3wnie\u017c swoj\u0105 ciemn\u0105 stron\u0119. Aby okre\u015bli\u0107 co zmieni\u0142o si\u0119 w interfejsie u\u017cytkownika, Angular musi wykonywa\u0107 ci\u0119\u017ck\u0105 i skomplikowan\u0105 operacj\u0119 Change Detection. Je\u015bli kiedykolwiek musieli\u015bcie optymalizowa\u0107 Angularowe komponenty albo natkneli\u015bcie si\u0119 na b\u0142\u0119dy zwi\u0105zane z od\u015bwie\u017caniem interfejsu, na pewno wiecie do czego zmierzam. Magia Angulara potrafi ca\u0142kiem szybko doprowadzi\u0107 do problem\u00f3w z wydajno\u015bci\u0105 i debugowaniem. <\/p>\n\n\n\n
Na przestrzeni lat deweloperzy Angulara nauczyli si\u0119 lawirowa\u0107 mi\u0119dzy ograniczeniami zone.js<\/code> i ChangeDetection<\/code>, ale wci\u0105\u017c czuli, \u017ce da si\u0119 to zrobi\u0107 lepiej. Tym lepiej maj\u0105 by\u0107 zaprezentowane w Angularze 16 Signals, kt\u00f3re s\u0105 pierwszym krokiem w kierunku pozbycia si\u0119 zone.js<\/code>. Nie nast\u0105pi to prawdopodobnie szybko (o ile w og\u00f3le – w ko\u0144cu aplikacji i bibliotek bazuj\u0105cych na zachowaniu zone.js<\/code> jest sporo…). Wydaje si\u0119 jednak, \u017ce pod-drzewa komponent\u00f3w pozbawione zone.js<\/code> s\u0105 ju\u017c tu\u017c za rogiem.<\/p>\n\n\n\n
Wr\u00f3\u0107my jednak do clue dzisiejszego tematu i przyjrzymy si\u0119 czym tak naprawd\u0119 s\u0105 sygna\u0142y. Cytuj\u0105c za dokumentacj\u0105 Angulara: sygna\u0142 jest opakowaniem wok\u00f3\u0142 warto\u015bci, kt\u00f3re jest w stanie powiadomi\u0107 zainteresowanych konsument\u00f3w, gdy ta warto\u015b\u0107 ulega zmianie. Dla wszystkich operuj\u0105cych na co dzie\u0144 w Angularze i RxJS ja\u015bniejsza  mo\u017ce by\u0107 analogia do BehaviourSubject<\/code>, gdy\u017c dok\u0142adnie tym w lekkim uproszczeniu s\u0105 sygna\u0142y.<\/p>\n\n\n\n
Sygna\u0142y tworzone s\u0105 za pomoc\u0105 factory method signal()<\/code> przyjmuj\u0105cej warto\u015b\u0107 pocz\u0105tkow\u0105 jako parametr. Sygna\u0142y mog\u0105 by\u0107 komponowane za pomoc\u0105 metody computed<\/code>(). Mo\u017cliwe jest r\u00f3wnie\u017c wywo\u0142ywanie efekt\u00f3w ubocznych, gdy warto\u015b\u0107 sygna\u0142u si\u0119 zmienia, rejestruj\u0105c odpowiedni callback w metodzie effect()<\/code>. W dowolnym momencie mo\u017cemy odczyta\u0107 warto\u015b\u0107 sygna\u0142u wywo\u0142uj\u0105c go jak funkcj\u0119. Sygna\u0142y mog\u0105 by\u0107 aktualizowane za pomoc\u0105 metod set<\/code>(), update<\/code>() i mutate<\/code>(). W du\u017cym uproszczeniu, to wszystko co musicie wiedzie\u0107 o sygna\u0142ach. Je\u015bli jeste\u015bcie natomiast ciekawi jak dzia\u0142aj\u0105 poszczeg\u00f3lne bebechy, to po\u015bwi\u0119cili\u015bmy temu tematowi ca\u0142\u0105 132 edycj\u0119 naszego przegl\u0105du<\/a>.<\/p>\n\n\n\n
@Component({\n  selector: 'my-app',\n  standalone: true,\n  template: `\n    {{ fullName() }} <button (click)="setName('John')">Click<\/button>\n  `,\n})\nexport class App {\n  firstName = signal('Jane');\n  lastName = signal('Doe');\n  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);\n\n  constructor() {\n    effect(() => console.log('Name changed:', this.fullName()));\n  }\n\n  setName(newName: string) {\n    this.firstName.set(newName);\n  }\n}<\/code><\/pre>\n\n\n\n
Opr\u00f3cz nowego prymitywu zesp\u00f3\u0142 Angulara pracuje te\u017c nad szeregiem wbudowanych w framework integracji. Dostaniemy wi\u0119c narz\u0119dzia do wygodnej integracji z sygna\u0142\u00f3w z strumieniami, API frameworka zwracaj\u0105ce sygna\u0142y zamiast strumieni i reaktywne inputy oparte o sygna\u0142y. Szczeg\u00f3lnie te ostatnie wygl\u0105daj\u0105 wyj\u0105tkowo ciekawie.<\/p>\n\n\n\n
Skoro Signals<\/code> zachowuj\u0105 si\u0119 bardzo podobnie do BehaviurSubject<\/code>, to czy Angular na pewno potrzebuje kolejnego prymitywu zintegrowanego z frameworkiem? Po pierwsze Signal<\/code> to du\u017co prostsza abstrakcja ni\u017c Observable<\/code>. \u017beby sprawnie operowa\u0107 RxJS<\/code> musimy pozna\u0107 ca\u0142y szereg skomplikowanych zagadnie\u0144 takich jak zimne i gor\u0105ce strumienie, asynchroniczno\u015b\u0107 w JavaScript czy ponad 100 dost\u0119pnych w RxJS operator\u00f3w. Po drugie, wszystkie strumienie naturalnie grawituj\u0105 w kierunku zimnych strumieni (wystarczy na dowolnym BehaviourSubject<\/code> zastosowa\u0107 operator map<\/code>). Sprawia to, \u017ce nigdy nie mo\u017cemy by\u0107 pewni, \u017ce subskrypcja do strumienia synchronicznie zwr\u00f3ci warto\u015b\u0107. W efekcie nasze aplikacje zalane s\u0105 zb\u0119dnym i powtarzalnym kodem. Podsumowuj\u0105c, RxJS sprawdza si\u0119 \u015bwietnie, gdy potrzebujemy modelowa\u0107 z\u0142o\u017cone zdarzenia dziej\u0105ce si\u0119 na przestrzeni czasu, takie jak limitowanie zapyta\u0144 do backendu czy agregowanie klikni\u0119\u0107 myszk\u0105. Je\u015bli chodzi o zarz\u0105dzanie stanem komponent\u00f3w i aplikacji, RxJS ma wi\u0119cej wad ni\u017c zalet.<\/p>\n\n\n
\n
\"\"
\u0179r\u00f3d\u0142o: https:\/\/twitter.com\/t3dotgg\/status\/1626393874393595907\/<\/a><\/figcaption><\/figure><\/div>\n\n\n
Non-Destructive Hydration<\/h3>\n\n\n\n
Hydracja to proces podczas kt\u00f3rego wyrenderowany na serwerze HTML jest przejmowany przez framework po stronie klienta. Wi\u0119kszo\u015b\u0107 framework\u00f3w w trakcie tego procesu pod\u0142\u0105cza listenery do istniej\u0105cych w\u0119z\u0142\u00f3w DOM. Do wersji 16, Angular zamiast wykorzystywa\u0107 istniej\u0105c\u0105 struktur\u0119 DOM, bazowa\u0142 w ca\u0142o\u015bci na strukturze wygenerowanej po stronie klienta. Jak \u0142atwo si\u0119 domy\u015bli\u0107, od czasu do czasu powodowa\u0142o to drobne glitche i nie by\u0142o najbardziej optymaln\u0105 strategi\u0105. Od najnowszej wersji, po ustawieniu odpowiedniej flagi, Angular po stronie klienta b\u0119dzie w stanie operowa\u0107 na strukturze HTML wyrenderowanej na serwerze.<\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Vite + ESBuild = Speed<\/h3>\n\n\n\n
Je\u015bli nigdy nie narzekali\u015bcie na powolne budowanie Angulara to… prawdopodobnie nigdy nie pracowali\u015bcie z du\u017cym projektem w Angularze. Ju\u017c od kilku wersji Angular wprowadza spore usprawnienia je\u015bli chodzi o czas uruchomienia serwera deweloperskiego. Angular 16 ca\u0142kowicie migruje serwer deweloperski na Vite + ESBuild. Z jednej strony usprawnienia wydajno\u015bci ciesz\u0105, z drugiej rozjazd mi\u0119dzy narz\u0119dziami wykorzystywanymi na produkcji (gdzie wci\u0105\u017c aplikacj\u0119 buduje webpack) i lokalnie troch\u0119 martwi. <\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Vue 3.3<\/h2>\n\n\n\n
Na Vue 3.3 czekali\u015bmy od dawna. Ju\u017c w naszym grudniowym podsumowaniu roku<\/a> pisali\u015bmy, \u017ce kolejny Vue uka\u017ce si\u0119 za kilka tygodni. Po drodze zesp\u00f3\u0142 dowodzony przez Evana You napotka\u0142 sporo perturbacji i z stycznia zrobi\u0142 si\u0119 nagle maj. Nie dziwi wiec, \u017ce jednym z celi zespo\u0142u na kolejne miesi\u0105ce jest regularne dowo\u017cenie mniejszych, inkrementalnych wyda\u0144. Czas poka\u017ce, czy cel uda si\u0119 spe\u0142ni\u0107, ale zgodnie z zapowiedziami Vue 3.4 ma ukaza\u0107 si\u0119 najp\u00f3\u017aniej za 6 miesi\u0119cy.<\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
TypeScript, TypeScript, TypeScript<\/h3>\n\n\n\n
Motywem przewodnim Vue 3.3 jest lepsza integracja z TypeScript. Zacznijmy od wsparcia z\u0142o\u017conych typ\u00f3w w funkcjach defineProps<\/code> i defineEmits<\/code>. Je\u015bli nigdy nie korzystali\u015bcie z Vue, to funkcje te s\u0142u\u017c\u0105 do definiowania schematu wej\u015b\u0107 i wyj\u015b\u0107 z komponentu. Vue w procesie kompilacji wykorzystywa\u0142 typ danych przekazanych do generycznych metod, co ogranicza\u0142o zakres mo\u017cliwo\u015bci do prostych typ\u00f3w zdefiniowanych w tym samym pliku co komponent. Wraz z Vue 3.3 ograniczenia te znikaj\u0105 ca\u0142kowicie i do defineProps<\/code> i defineEmits<\/code> mo\u017cemy teraz przekazywa\u0107 dowolne typy – czy to importowane z innych plik\u00f3w, czy to Union Types, czy to zaawansowane potworki wykorzystuj\u0105ce Utility Types.<\/p>\n\n\n\n
<script setup lang="ts">\nimport type { Props } from '.\/foo'\n\n\/\/ imported + intersection type\ndefineProps<Props & { extraProp?: string }>()\n<\/script><\/code><\/pre>\n\n\n\n
Kolejn\u0105 nowo\u015bci\u0105 w Vue 3.3 s\u0105 generyczne komponenty. Pr\u00f3bowa\u0142em dogrzeba\u0107 si\u0119 do informacji, w jaki spos\u00f3b deweloperzy Vue radzili sobie z generycznymi komponentami do tej pory. Okazuje si\u0119, \u017ce albo rezygnowali oni ca\u0142kowicie ze sprawdzania typ\u00f3w, albo skazani byli na pokraczne i skomplikowane rozwi\u0105zania<\/a>. Na szcz\u0119\u015bcie, od teraz rozs\u0105dne rozwi\u0105zanie jest ju\u017c wbudowane w framework.<\/p>\n\n\n\n
<script setup lang="ts" generic="T">\ndefineProps<{\n  items: T[]\n  selected: T\n}>()\n<\/script><\/code><\/pre>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
Inne usprawnienia<\/h3>\n\n\n\n
Opr\u00f3cz usprawnionej integracji z TypeScript, Vue 3.3 to te\u017c ma\u0142a paczka drobnych usprawnie\u0144. Dostali\u015bmy na przyk\u0142ad nowe, zdecydowanie schludniejsze API dla metody <code>defineEmits<\/code><\/code>.<\/p>\n\n\n\n
\/\/ BEFORE\nconst emit = defineEmits<{\n  (e: 'foo', id: number): void\n  (e: 'bar', name: string, ...rest: any[]): void\n}>()\n\n\/\/ AFTER\nconst emit = defineEmits<{\n  foo: [id: number]\n  bar: [name: string, ...rest: any[]]\n}>()<\/code><\/pre>\n\n\n\n
Poza tym dostali\u015bmy now\u0105 metod\u0119 defineSlots<\/code>, kt\u00f3ra b\u0119dzie s\u0142u\u017cy\u0142a do zdefiniowania typ\u00f3w slot\u00f3w w komponencie. Na ten moment  kompilator weryfikuje tylko zgodno\u015b\u0107 schematu komponentu, przez co nie da si\u0119 na przyk\u0142ad zdefiniowa\u0107 sko\u0144czonej listy akceptowanych komponent\u00f3w. Rozwi\u0105zanie nie jest te\u017c wspierane przez Volar<\/code>, czyli  Language Server wykorzystywany przez Vue, dzi\u0119ki kt\u00f3remu w VSCode mo\u017cemy korzysta\u0107 z podpowiadania sk\u0142adni i innych podobnych dobrodziejstw. Pomimo drobnych ogranicze\u0144, defineSlots<\/code> wydaje si\u0119 krokiem w dobrym kierunku i na pewno ucieszy wszystkich pracuj\u0105cych na co dzie\u0144 z Vue. <\/p>\n\n\n\n
<script setup lang="ts">\ndefineSlots<{\n  default?: (props: { msg: string }) => any\n  item?: (props: { id: number }) => any\n}>()\n<\/script><\/code><\/pre>\n\n\n\n
Przysz\u0142o\u015b\u0107 Vue<\/h3>\n\n\n\n
Por\u00f3wnuj\u0105c nowo\u015bci z Vue do tych z Angulara i React, nie spos\u00f3b nie odnie\u015b\u0107 wra\u017cenia, \u017ce s\u0105 one troch\u0119 mniej ekscytuj\u0105ce. Vue mierzy si\u0119 w\u0142a\u015bnie z migracj\u0105 swoich u\u017cytkownik\u00f3w z wersji 2 na 3. Oznacza to, \u017ce zesp\u00f3\u0142 nie mo\u017ce skupi\u0107 si\u0119 ca\u0142kowicie na rozwoju nowych funkcjonalno\u015bci. Poprzednio wydana wersja Vue, to w ko\u0144cu nie Vue 3.2, a Vue 2.7, kt\u00f3re portowa\u0142o nowo\u015bci z Vue 3 do Vue 2. Wszystko wskazuje na to, \u017ce sytuacja wkr\u00f3tce ulegnie zmianie. Po pierwsze, Vue 2 dokona swojego \u017cywota wraz z ko\u0144cem tego roku. Po drugie, na tegorocznej konferencji Vuejs Amsterdam, Evan You uchyli\u0142 r\u0105bka tajemnicy i zdradzi\u0142, \u017ce zesp\u00f3\u0142 pracuje nad nowym wydajnym kompilatorem na wz\u00f3r SolidJS. Po trzecie, Vue to nie tylko Vue. W ostatnich miesi\u0105cach narz\u0119dzia zbudowane wok\u00f3\u0142 Vue (np. Vite, Volar) zacz\u0119\u0142y szturmem zdobywa\u0107 popularno\u015b\u0107 r\u00f3wnie\u017c poza matczynym frameworkiem i to w\u0142a\u015bnie tutaj dzieje si\u0119 teraz najwi\u0119cej.<\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
PS Je\u015bli na co dzie\u0144 pracujecie z Vue i jeszcze nie widzieli\u015bcie prezentacji Evana, to najwy\u017cszy czas to nadrobi\u0107. <\/p>\n\n\n\n
\n