{"id":11577,"date":"2022-10-28T14:50:48","date_gmt":"2022-10-28T12:50:48","guid":{"rendered":"https:\/\/vived.io\/?p=11577"},"modified":"2022-10-28T14:50:51","modified_gmt":"2022-10-28T12:50:51","slug":"przyszlosc-jest-dzisiaj-czyli-next-js-13-frontend-weekly-vol-110","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/przyszlosc-jest-dzisiaj-czyli-next-js-13-frontend-weekly-vol-110\/","title":{"rendered":"Przysz\u0142o\u015b\u0107 jest dzisiaj, czyli Next.js 13 | Frontend Weekly vol. 110"},"content":{"rendered":"\n

1. Next.js Conf \ud83d\ude80<\/h2>\n\n\n\n

Vercel to jedna z najlepiej dofinansowanych firm zbudowanych wok\u00f3\u0142 otwarto\u017ar\u00f3d\u0142owej technologii. Na przestrzeni ostatnich lat (i 4 rund finansowania), firma zgromadzi\u0142a na swoim koncie ponad 300 milion\u00f3w dolar\u00f3w<\/a>. Nale\u017cy przyzna\u0107, \u017ce pieni\u0105dze te zosta\u0142y dobrze zainwestowane. Next.js sta\u0142 si\u0119 w\u0142a\u015bciwie domy\u015blnym rozwi\u0105zaniem je\u015bli chodzi o renderowania Reacta po stronie serwera, a chmura oferowana przez firm\u0119 z roku na rok zyskuje coraz wi\u0119cej sympatyk\u00f3w.<\/p>\n\n\n

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

Sukces Next.js przyci\u0105gn\u0105\u0142 te\u017c na\u015bladowc\u00f3w. W\u015br\u00f3d najwi\u0119kszych rywali wymieni\u0107 nale\u017cy Hydrogen (framework do SSR rozwijany przez Shopify, dedykowany budowaniu sklep\u00f3w przy u\u017cyciu ich platformy) oraz Remix (framework do SSR rozwijany przez tw\u00f3rc\u00f3w react-router). Ten drugi pod wzgl\u0119dem modelu biznesowego mocno przypomina Next.js. R\u00f3wnie\u017c jest on rozwijany budowany wok\u00f3\u0142 otwarto\u017ar\u00f3d\u0142owych technologii (rect-router, Remix) i podobnie jak sw\u00f3j konkurent znalaz\u0142 inwestor\u00f3w wierz\u0105cych w jego sukces<\/a>. Patrz\u0105c realistycznie na sytuacj\u0119 nale\u017cy jednak zauwa\u017cy\u0107, \u017ce zar\u00f3wno pod wzgl\u0119dem adopcji jak i funduszy, Next.js od konkurencji dzieli przepa\u015b\u0107.<\/p>\n\n\n\n

Bior\u0105c pod uwag\u0119 popularno\u015b\u0107 i bud\u017cety Next.js, nie dziwi\u0105 oczekiwania jakie naros\u0142y wok\u00f3\u0142 Next.js Conf. Jak si\u0119 okaza\u0142o, nadzieje pok\u0142adane w konferencji zosta\u0142y spe\u0142nione z nawi\u0105zk\u0105. Opr\u00f3cz Next.js 13 i zupe\u0142nie nowego systemu routingu,  zaprezentowana zosta\u0142a alternatywa dla Webpack w postaci Turbopack i sporo wi\u0119cej.<\/p>\n\n\n

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

1.1 Nowy routing w Next.js<\/h3>\n\n\n\n

O RFC dotycz\u0105cym nowego routingu w Next.j<\/a>s informowali\u015bmy Was kilka miesi\u0119cy temu w Frontend Weekly vol. 89<\/a> (niestety tylko w j\u0119zyku polskim). Od tego czasu min\u0119\u0142o ju\u017c sporo czasu, do RFC trafi\u0142o kilka zmian, a pierwsza wersja nowego routera jest ju\u017c dost\u0119pna w Next.js 13. Z tego powodu, dzisiaj ponownie przyjrzymy si\u0119 temu tematowi.<\/p>\n\n\n\n

Do tej pory komponent Next.js dopasowywa\u0142 \u015bcie\u017ck\u0119 w pasku przegl\u0105darki do odpowiedniego katalogu, a nast\u0119pnie wy\u015bwietla\u0142 komponent zdefiniowany w pliku index.js. Nowy router zamiast pliku index.js szuka\u0142 b\u0119dzie pliku page.js. Najwi\u0119ksz\u0105 nowo\u015bci\u0105 jest jest fakt, \u017ce Next.js znajdzie r\u00f3wnie\u017c wszystkie pliku layout.js znajduj\u0105ce si\u0119 w \u015bcie\u017cce katalog\u00f3w i wy\u015bwietli je jako \u201copakowanie\u201d naszej strony. Co wa\u017cne, dane zar\u00f3wno dla strony jak i wszystkich layout \u0142adowane b\u0119d\u0105 r\u00f3wnolegle.<\/p>\n\n\n\n

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

Kolejn\u0105 nowo\u015bci\u0105 jest r\u00f3wnie\u017c pojawienie si\u0119 plik\u00f3w error.js i loading.js. Te pierwsze wykorzystywane b\u0119d\u0105, kiedy podczas pobierania danych lub renderowania wyst\u0105pi\u0142 nieoczekiwany b\u0142\u0105d. Te drugie wy\u015bwietlane b\u0119d\u0105 zanim wszystkie komponenty w poddrzewie zostan\u0105 wyrenderowane (pod spodem Next.js wykorzystuje usprawniony w React 18 Suspense).<\/p>\n\n\n\n

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

Fundamentaln\u0105 zmian\u0105 w nowym routingu jest r\u00f3wnie\u017c uczynienie React Server Components domy\u015blnym typem komponent\u00f3w. Oznacza, \u017ce tworz\u0105c komponenty uwa\u017ca\u0107 musimy na ograniczenia jakie React narzuca przy korzystaniu React Server Components (ze szczeg\u00f3lnym uwzgl\u0119dnieniem ogranicze\u0144 w mieszaniu ich z Client Components). Oznacza to te\u017c, \u017ce dop\u00f3ki nie zaczniemy definiowa\u0107 Client Components, ca\u0142o\u015b\u0107 naszej aplikacji renderowana b\u0119dzie po stronie serwera. Zachowanie to powinno sprawi\u0107, \u017ce paczka kodu JavaScript wysy\u0142ana do klienta b\u0119dzie ekstremalnie ma\u0142a. Niestety pierwsze testy przeprowadzane przez u\u017cytkownik\u00f3w tego nie potwierdzaj\u0105 i aplikacja renderowana w 100% po stronie serwera nadal wa\u017cy ca\u0142kiem sporo. W sieci nie natrafi\u0142em na oficjalne potwierdzenie, ale prawdopodobnie spora paczka spowodowana jest problemami wieku dzieci\u0119cego Next.js 13.<\/p>\n\n\n\n

\n

Circling back and re-testing the Hello World experience in the brand new @nextjs<\/a> 13. Still seeing a 272 kB baseline of client-side JavaScript \ud83d\ude2c (90 kB compressed).

The project waterfall starts at 88% JS \ud83d\udc40 pic.twitter.com\/xpwr0bErUT<\/a><\/p>— Zach Leatherman (@zachleat) October 25, 2022<\/a><\/blockquote>