Zastanawiacie się co dzieje się z React Server Components i co stało się z obiecywanym od dawna kompilatorem React Forget? Jeśli tak, to w dzisiejszym raporcie znajdziecie odpowiedzi na te pytana. Poza tym dowiecie się jakie nowe funkcjonalności zmierzają do JavaScriptu i jak Microsoft przyśpieszył Teams prawie dwukrotnie.
1. Nad czym pracuje zespół Reacta?
W minionym tygodniu zespół Reacta podzielił się z nami zbiorczym podsumowaniem wszystkich inicjatyw mających miejsce w projekcie. Notatka naprawdę nie jest długa, dlatego każdemu polcam przeczytać ją osobiście. Natomiast dla wszystkich zbyt zajętych przedświątecznymi przygotowaniami mamy krótkie podsumowanie najważniejszych podpunktów.
- React Server Components to nowa architekura nad którą zespół pracuje już od 2020 roku. Nadal są one w fazie bety, ale obecnie są głównym priorytetem zespołu. Z React Server Components możemy korzystać już na przykład w Next.js czy Gatsby. Jeśli chcecie nadrobić temat React Server Components, to najlepszym źródłem będzie artykuł opublikowany na blogu Plasmic „How React server components work: an in-depth guide”.
- Od czasu publikacji ostatniej aktualizacji, ustabilizowana została konwencja oznaczania serwerowych oraz klienckich komponentów. Zamiast rozszerzeń
.server.tsx
i.client.tsx
używać będziemy shebanguse client
iuse server
. - Do przodu posunęły się również prace nad RFC dotyczącym obsługi async/await. Serwerowe komponenty będą mogły bezpośrednio korzystać z składni JavaScript, natomiast komponenty klienckie będa mogły odpakować Promisy przy pomocy nowego hooka
use(Promise)
. Więcej o tym jak będzie działał nowy hook możecie przeczytać w 109 edycji naszego przeglądu. - Największą nowością dotyczącą React Server Components są prace nad Server Actions. Umożliwią one klienckim komponentom wykonywanie operacji bezpośrednio na serwerze. Szczegółowego RFC możemy spodziewać się już wkrótce.
- Zespół aktualnie pracuje nad integracją komponentu
<Suspense />
z ładowaniem zasobów – np. plików CSS i zewnętrznych skryptów. Szczegółowego RFC możemy spodziewać się już wkrótce. - Kolejną funkcjonalnością nad którą aktualnie pracuje zespół jest obsługa
<title>
i<meta>
. Co prawda obecnie istnieją rozwiązania umożliwiające manipulację tymi parametrami (np. Helmet), ale wymagają one wyrenderowania całej aplikacji po stronie serwera. Takie zachowanie kłóci się z ideą React Server Components i z tego powodu zespół zdecydował się przygotować specjalne API wbudowane w bibliotekę. Szczegółowego RFC również możemy spodziewać się już wkrótce. - React Forget to zapowiedziany w 2021 kompilator, który ma automatycznie zajmować się memonizacją (
useCallback
iuseMemo
). Prace nad kompilatorem znacząco się przedłużyły, ale jest on już używany w pierwszych projektach wewnątrz Mety. Kiedy tylko kompilator zacznie działać wystarczająco dobrze, to zostanie on upubliczniony. Jeśli ominął Was temat React Forget, to nadal najlepszym źródłem na jego temat jest oryginalna prezentacja React without memo. - Ostatnią funkcjonalnością wspomnianą w notatce jest Offscreen Rendering, czyli jak opisują twórcy, odpowiednik
content-visiblity: hidden
dla Reactowych komponentów. Jak donoszą twórcy, pierwsza implementacja jest już wykorzystywana przez Metę w React Native, ale na pełnoprawne RFC przyjdzie nam jeszcze trochę poczekać.
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Starszyzna znów obraduje – co ciekawgo przyniosło kolejne spotkanie TC39 Meeting
W minionym tygodniu po raz kolejny miejsce miało TC39 Meeting, czyli zebranie JavaScriptowej starszyzny na którym omawiane są nowe funkcjonalności języka. Jak zwykle omawiane było kilka ciekawych nowości, ale zanim przejdziemy do konkretów, pokrótce przypomnijmy czym jest TC39 i jak w szczegółach wygląda proces standaryzacyjny.
TC39 to grupa zajmująca się standaryzacją języka JavaScript na którą składają się przedstawiciele najważniejszych udziałowców – np. deweloperzy Chrome, Safari, Firefox, Node czy Babel. Sam proces składa się z 4 etapów. Zanim nowa funkcjonalność 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śli dana funkcjonalność trafi do pierwszego etapu standaryzacji, to znaczy, że komisja uznała funkcjonalność za interesującą i pragnie dalej zgłębić temat. Kiedy funkcjonalność przebija się do drugiego etapu, oznacza to, że jest ona już dobrze przemyślana, a samo API bliskie jest finalizacji. Po przebiciu się do trzeciego etapu, API bardzo rzadko się zmienia. Na tym etapie przygotowywane jest również pierwsza implementacja oraz niezbędne pollyfille. Jeślu funkcjonalność trafia do etapu czwartego, to oznacza to, że trafi ona do najbliższej specyfikacji języka, która publikowana jest zazwyczaj w pierwszym kwartale każdego roku.
Poniżej znajdziecie kilka wybranych przez nas funkcjonalności omawianych na ostatnim spotkaniu TC39 meeting. Jeśli jesteście zainteresowani pełną listą, to możecie ją znaleźć tutaj.
Stage 3 – import assertions
Powszechnie uznaje się, że jeśli dana funkcjonalność trafi do trzeciego etapu standaryzacji, to na 90% trafi wkrótce do standardu języka. Funkcjonalność import assertions znalazła się w nieszczęśliwych 10% i na poprzednim spotkaniu TC39, ze względu na kilka istotnych wątpliwości, została cofnięta do etapu drugiego. Teraz wraca ona z powrotem do etapu trzeciego.
O co chodzi z import assertions? Jeśli funkcjonalność ta trafi do języka, będziemy mogli bez problemu importować pliki JSON czy WebAssembly bezpośrednio z poziomu JavaScriptu. Jeśli coś Wam to przypomina, to podobne zachowanie można osiągnąć przez odpowiednią konfigurację webpacka.
import json from "./foo.json" with { type: "json" };
export val from './foo.js' with { type: "javascript" };
new Worker("foo.wasm", { type: "module", with: { type: "webassembly" } });
TC39 Proposal – Import Attributes
Stage 2 – Iterator.range()
Na pewno staneliście kiedyś przed potrzebą wygenerowania listy liczb z odpowiedniego zakresu. Języki takie jak Python czy Scala oferują taką funkcjonalność w bibliotece standardowej. Niestety do tej pory JavaScrtipt nie był wyposażony w takie luksusy i skazani byliśmy albo na korzystanie z zewnętrznych bibliotek (np. lodash lub underscore) albo na kilka pokrętnych hacków (wątek na Stackoverflow sugeruje ponad 20 możliwych rozwiązań!). Na szczęście TC39 już pracuje nad rozwiązaniem tego problemu. Co ciekawe nowa funkcja zwracać będzie iterator, co pozwoli nam w łatwy sposób operować na nieskończonych zbiorach.
// odd number from 1 to 99
[...Iterator.range(1, 100, 2)]
// numbers from 1 to 1000 that are divisible by 3
Iterator.range(0, Infinity)
.take(1000)
.filter((x) => !(x % 3))
.toArray();
// generator function yielding even numbers infinitely
function* even() {
for (const i of Iterator.range(0, Infinity)) if (i % 2 === 0) yield i
};
Stage 1 – Class method and consturcor decorators
Niespełna kilka tygodni temu w naszym przeglądzie opisywaliśmy historię dekoratorów w TypeScript i JavaScript, a w tym tygodniu pojawiły się nowy Proposal w tym temacie. Zgodnie z aktualnym Proposalem znajdującym się w trzecim etapie standaryzacji, dekorowane mogą być tylko klasy i metody. Mocno ogranicza to twórców frameworków, bo dekorowanie parametrów często wykorzystywane jest w celu dostarczenia dodatkowego kontekstu dla Dependency Injection (np. @Optional()
lub @Inject(TOKEN)
) lub do automatycznej walidacji danych wejściowych (np. @ValidateEmail()
lub @NotEmpty()
). Omawiany na tym spotkaniu Proposal dodaje taką właśnie możliwość.
class UserManager {
createUser(@NotEmpty username, @NotEmpty password, @ValidateEmail emailAddress) { }
}
TC39 Proposal – Class method and consturcor decorators
Stage 1 – Promise.withResolvers
Standardowym sposobem na stworzenie obiektu Promise jest przekazanie do konstruktora odpowiedniego callbacka.
const myPromise = new Promise((resolve, reject) => {
/* Some code */
if(result) {
resolve("Ok")
} else {
reject(new Error("Rejected"))
}
})
Na problem napotykamy w momencie, kiedy Promise chcemy obsłużyć spoza poziomy callbacka. Jest to oczywiście możliwe, ale wymaga napisania kawałka niezbyt ładnego kodu.
let resolve;
let reject;
const myPromise = new Promise((resolve_, reject_) => {
resolve = resolve_;
reject = reject_;
})
/* Some code */
if(result) {
resolve("Ok")
} else {
reject(new Error("Rejected"))
}
Nowo zaproponowane API oferować ma czytelniejsze rozwiązanie tego problemu.
const { promise, resolve, reject } = Promise.withResolvers();
/* Some code */
if(result) {
resolve("Ok")
} else {
reject(new Error("Rejected"))
}
TC39 Proposal – Promise.withResolvers
3. Generyki zmierzają do Vue Single File Components
Vue 3.3 zbliża się wielkimi krokami i powoli zaczynają do nas spływać informacje o zmierzających do niego funkcjonalnościach. W tym tygodniu Evan You zdradził, że do najnowszej wersji frameworka trafią generyczne komponenty. Jest to jedna z dłużej wyczekiwanych funkcjonalności Vue, bo pierwsze dyskusje na jej temat miały miejsce już w 2021 roku!
<script
setup
lang="ts"
generic="Clearable extends boolean, ValueType extends string | number | null | undefined"
>
defineProps<{
clearable?: Clearable;
value?: ValueType;;
}>
</script>
Zainstaluj teraz i czytaj tylko dobre teksty!
4. Microsoft zmigrował Teamsy do WebView2
Na zakończenie dzisiejszego przeglądu mamy dla Was Case Study od Microsoftu, który właśnie zakończył migrację Microsoft Teams z AngularJS do Reacta oraz z Electrona do WebView2. Dla przypomnienia WebView2, to w uproszczeniu technologia umożliwająca embedowanie w natywnych aplikacjach Microsoft Edge. Czym jest React i AngularJS chyba nikomu nie musimy przypominać.
Migracja przyniosła znaczącą poprawę zarówno jeśli chodzi o zużycie pamięci jak i procesora. Uaktualniona wersja zaczęła już trafiać do „regularnych klientów”, a wkrótce zacznie również trafiać do tych komercyjnych. Jeśli jesteście ciekawi jak wygląda teraz architektura Microsoft Teams i gdzie udało się ugrać najwięcej, to wszystkiego dowiecie się z notatki podlinkowanej poniżej.