- \n
- React Server Components to nowa architekura nad kt\u00f3r\u0105 zesp\u00f3\u0142 pracuje ju\u017c od 2020 roku. Nadal s\u0105 one w fazie bety, ale obecnie s\u0105 g\u0142\u00f3wnym priorytetem zespo\u0142u. Z React Server Components mo\u017cemy korzysta\u0107 ju\u017c na przyk\u0142ad w Next.js czy Gatsby. Je\u015bli chcecie nadrobi\u0107 temat React Server Components, to najlepszym \u017ar\u00f3d\u0142em b\u0119dzie artyku\u0142 opublikowany na blogu Plasmic „How React server components work: an in-depth guide”<\/a>.<\/li>\n\n\n\n
- Od czasu publikacji ostatniej aktualizacji, ustabilizowana zosta\u0142a konwencja oznaczania serwerowych oraz klienckich komponent\u00f3w. Zamiast rozszerze\u0144
.server.tsx<\/code> i.client.tsx<\/code> u\u017cywa\u0107 b\u0119dziemy shebanguse client<\/code> iuse server<\/code>. <\/li>\n\n\n\n- Do przodu posun\u0119\u0142y si\u0119 r\u00f3wnie\u017c prace nad RFC dotycz\u0105cym obs\u0142ugi async\/await. Serwerowe komponenty b\u0119d\u0105 mog\u0142y bezpo\u015brednio korzysta\u0107 z sk\u0142adni JavaScript, natomiast komponenty klienckie b\u0119da mog\u0142y odpakowa\u0107 Promisy przy pomocy nowego hooka
use(Promise)<\/code>. Wi\u0119cej o tym jak b\u0119dzie dzia\u0142a\u0142 nowy hook mo\u017cecie przeczyta\u0107 w 109 edycji naszego przegl\u0105du<\/a>.<\/li>\n\n\n\n- Najwi\u0119ksz\u0105 nowo\u015bci\u0105 dotycz\u0105c\u0105 React Server Components s\u0105 prace nad Server Actions. Umo\u017cliwi\u0105 one klienckim komponentom wykonywanie operacji bezpo\u015brednio na serwerze. Szczeg\u00f3\u0142owego RFC mo\u017cemy spodziewa\u0107 si\u0119 ju\u017c wkr\u00f3tce.<\/li>\n\n\n\n
- Zesp\u00f3\u0142 aktualnie pracuje nad integracj\u0105 komponentu
<Suspense \/><\/code> z \u0142adowaniem zasob\u00f3w – np. plik\u00f3w CSS i zewn\u0119trznych skrypt\u00f3w. Szczeg\u00f3\u0142owego RFC mo\u017cemy spodziewa\u0107 si\u0119 ju\u017c wkr\u00f3tce.<\/li>\n\n\n\n- Kolejn\u0105 funkcjonalno\u015bci\u0105 nad kt\u00f3r\u0105 aktualnie pracuje zesp\u00f3\u0142 jest obs\u0142uga
<title><\/code> i<meta><\/code>. Co prawda obecnie istniej\u0105 rozwi\u0105zania umo\u017cliwiaj\u0105ce manipulacj\u0119 tymi parametrami (np. Helmet<\/a>), ale wymagaj\u0105 one wyrenderowania ca\u0142ej aplikacji po stronie serwera. Takie zachowanie k\u0142\u00f3ci si\u0119 z ide\u0105 React Server Components i z tego powodu zesp\u00f3\u0142 zdecydowa\u0142 si\u0119 przygotowa\u0107 specjalne API wbudowane w bibliotek\u0119. Szczeg\u00f3\u0142owego RFC r\u00f3wnie\u017c mo\u017cemy spodziewa\u0107 si\u0119 ju\u017c wkr\u00f3tce.<\/li>\n\n\n\n- React Forget to zapowiedziany w 2021 kompilator, kt\u00f3ry ma automatycznie zajmowa\u0107 si\u0119 memonizacj\u0105 (
useCallback<\/code> iuseMemo<\/code>). Prace nad kompilatorem znacz\u0105co si\u0119 przed\u0142u\u017cy\u0142y, ale jest on ju\u017c u\u017cywany w pierwszych projektach wewn\u0105trz Mety. Kiedy tylko kompilator zacznie dzia\u0142a\u0107 wystarczaj\u0105co dobrze, to zostanie on upubliczniony. Je\u015bli omin\u0105\u0142 Was temat React Forget, to nadal najlepszym \u017ar\u00f3d\u0142em na jego temat jest oryginalna prezentacja React without memo<\/a>.<\/li>\n\n\n\n- Ostatni\u0105 funkcjonalno\u015bci\u0105 wspomnian\u0105 w notatce jest Offscreen Rendering, czyli jak opisuj\u0105 tw\u00f3rcy, odpowiednik
content-visiblity: hidden<\/code> dla Reactowych komponent\u00f3w. Jak donosz\u0105 tw\u00f3rcy, pierwsza implementacja jest ju\u017c wykorzystywana przez Met\u0119 w React Native, ale na pe\u0142noprawne RFC przyjdzie nam jeszcze troch\u0119 poczeka\u0107.<\/li>\n<\/ul>\n\n\n\n2. Starszyzna zn\u00f3w obraduje – co ciekawgo przynios\u0142o kolejne spotkanie TC39 Meeting<\/h2>\n\n\n\n
W minionym tygodniu po raz kolejny miejsce mia\u0142o TC39 Meeting, czyli zebranie JavaScriptowej starszyzny na kt\u00f3rym omawiane s\u0105 nowe funkcjonalno\u015bci j\u0119zyka. Jak zwykle omawiane by\u0142o kilka ciekawych nowo\u015bci, ale zanim przejdziemy do konkret\u00f3w, pokr\u00f3tce przypomnijmy czym jest TC39 i jak w szczeg\u00f3\u0142ach wygl\u0105da proces standaryzacyjny.<\/p>\n\n\n
\n![\"\"](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/03\/grid_0-1-1024x683.png\")
Obrady TC39 – koloryzowane<\/figcaption><\/figure><\/div>\n\n\n TC39 to grupa zajmuj\u0105ca si\u0119 standaryzacj\u0105 j\u0119zyka JavaScript na kt\u00f3r\u0105 sk\u0142adaj\u0105 si\u0119 przedstawiciele najwa\u017cniejszych udzia\u0142owc\u00f3w – np. deweloperzy Chrome, Safari, Firefox, Node czy Babel. Sam proces sk\u0142ada si\u0119 z 4 etap\u00f3w. Zanim nowa funkcjonalno\u015b\u0107 zostanie przedstawiona na spotkaniu TC39, stworzony zostaje dobrze opisany Proposal oraz wybierany jest tak zwany Champion, czyli osoba odpowiedzialna za Proposal na kolejnych etapach standaryzacji. Je\u015bli dana funkcjonalno\u015b\u0107 trafi do pierwszego etapu standaryzacji, to znaczy, \u017ce komisja uzna\u0142a funkcjonalno\u015b\u0107 za interesuj\u0105c\u0105 i pragnie dalej zg\u0142\u0119bi\u0107 temat. Kiedy funkcjonalno\u015b\u0107 przebija si\u0119 do drugiego etapu, oznacza to, \u017ce jest ona ju\u017c dobrze przemy\u015blana, a samo API bliskie jest finalizacji. Po przebiciu si\u0119 do trzeciego etapu, API bardzo rzadko si\u0119 zmienia. Na tym etapie przygotowywane jest r\u00f3wnie\u017c pierwsza implementacja oraz niezb\u0119dne pollyfille. Je\u015blu funkcjonalno\u015b\u0107 trafia do etapu czwartego, to oznacza to, \u017ce trafi ona do najbli\u017cszej specyfikacji j\u0119zyka, kt\u00f3ra publikowana jest zazwyczaj w pierwszym kwartale ka\u017cdego roku.<\/p>\n\n\n\n
Poni\u017cej znajdziecie kilka wybranych przez nas funkcjonalno\u015bci omawianych na ostatnim spotkaniu TC39 meeting. Je\u015bli jeste\u015bcie zainteresowani pe\u0142n\u0105 list\u0105, to mo\u017cecie j\u0105 znale\u017a\u0107 tutaj<\/a>.<\/p>\n\n\n\n
Stage 3 – import assertions<\/h3>\n\n\n\n
Powszechnie uznaje si\u0119, \u017ce je\u015bli dana funkcjonalno\u015b\u0107 trafi do trzeciego etapu standaryzacji, to na 90% trafi wkr\u00f3tce do standardu j\u0119zyka. Funkcjonalno\u015b\u0107 import assertions znalaz\u0142a si\u0119 w nieszcz\u0119\u015bliwych 10% i na poprzednim spotkaniu TC39, ze wzgl\u0119du na kilka istotnych w\u0105tpliwo\u015bci, zosta\u0142a cofni\u0119ta do etapu drugiego. Teraz wraca ona z powrotem do etapu trzeciego. <\/p>\n\n\n\n
O co chodzi z import assertions? Je\u015bli funkcjonalno\u015b\u0107 ta trafi do j\u0119zyka, b\u0119dziemy mogli bez problemu importowa\u0107 pliki JSON czy WebAssembly bezpo\u015brednio z poziomu JavaScriptu. Je\u015bli co\u015b Wam to przypomina, to podobne zachowanie mo\u017cna osi\u0105gn\u0105\u0107 przez odpowiedni\u0105 konfiguracj\u0119 webpacka.<\/p>\n\n\n\n
import json from ".\/foo.json" with { type: "json" };\nexport val from '.\/foo.js' with { type: "javascript" };\nnew Worker("foo.wasm", { type: "module", with: { type: "webassembly" } });<\/code><\/pre>\n\n\n\nTC39 Proposal – Import Attributes<\/a><\/p>\n\n\n\n
Stage 2 –
Iterator.range()<\/code><\/h3>\n\n\n\nNa pewno staneli\u015bcie kiedy\u015b przed potrzeb\u0105 wygenerowania listy liczb z odpowiedniego zakresu. J\u0119zyki takie jak Python czy Scala oferuj\u0105 tak\u0105 funkcjonalno\u015b\u0107 w bibliotece standardowej. Niestety do tej pory JavaScrtipt nie by\u0142 wyposa\u017cony w takie luksusy i skazani byli\u015bmy albo na korzystanie z zewn\u0119trznych bibliotek (np. lodash<\/a> lub underscore<\/a>) albo na kilka pokr\u0119tnych hack\u00f3w (w\u0105tek na Stackoverflow<\/a> sugeruje ponad 20 mo\u017cliwych rozwi\u0105za\u0144!). Na szcz\u0119\u015bcie TC39 ju\u017c pracuje nad rozwi\u0105zaniem tego problemu. Co ciekawe nowa funkcja zwraca\u0107 b\u0119dzie iterator, co pozwoli nam w \u0142atwy spos\u00f3b operowa\u0107 na niesko\u0144czonych zbiorach.<\/p>\n\n\n\n
\/\/ odd number from 1 to 99\n[...Iterator.range(1, 100, 2)] \n\n\/\/ numbers from 1 to 1000 that are divisible by 3\nIterator.range(0, Infinity)\n .take(1000)\n .filter((x) => !(x % 3))\n .toArray();\n\n\/\/ generator function yielding even numbers infinitely\nfunction* even() {\n for (const i of Iterator.range(0, Infinity)) if (i % 2 === 0) yield i\n};<\/code><\/pre>\n\n\n\nTC39 Proposal – Range<\/a><\/p>\n\n\n\n
Stage 1 – Class method and consturcor decorators<\/h3>\n\n\n\n
Niespe\u0142na kilka tygodni temu w naszym przegl\u0105dzie opisywali\u015bmy histori\u0119 dekorator\u00f3w w TypeScript i JavaScript<\/a>, a w tym tygodniu pojawi\u0142y si\u0119 nowy Proposal w tym temacie. Zgodnie z aktualnym Proposalem znajduj\u0105cym si\u0119 w trzecim etapie standaryzacji<\/a>, dekorowane mog\u0105 by\u0107 tylko klasy i metody. Mocno ogranicza to tw\u00f3rc\u00f3w framework\u00f3w, bo dekorowanie parametr\u00f3w cz\u0119sto wykorzystywane jest w celu dostarczenia dodatkowego kontekstu dla Dependency Injection (np.
@Optional()<\/code> lub@Inject(TOKEN)<\/code>) lub do automatycznej walidacji danych wej\u015bciowych (np.@ValidateEmail()<\/code> lub@NotEmpty()<\/code>). Omawiany na tym spotkaniu Proposal dodaje tak\u0105 w\u0142a\u015bnie mo\u017cliwo\u015b\u0107.<\/p>\n\n\n\nclass UserManager {\n createUser(@NotEmpty username, @NotEmpty password, @ValidateEmail emailAddress) { }\n}<\/code><\/pre>\n\n\n\n - Od czasu publikacji ostatniej aktualizacji, ustabilizowana zosta\u0142a konwencja oznaczania serwerowych oraz klienckich komponent\u00f3w. Zamiast rozszerze\u0144