React udaje, że SPA nie istnieją | Frontend Weekly vol. 130

1. Czy React udaje, że SPA nie istnieją?

W poprzedniej edycji naszego raportu podrzucaliśmy Wam link do nowej dokumentacji Reacta. Prawie pod wszystkimi względami jest ona lepsza od starej dokumentacji. Jest napisana z myślą o hookach, zawiera interaktywne przykłady i pokrywa wiele tematów, których brakowało w poprzedniej wersji.

Premiera nowej dokumentacji nie obyła się jednak bez kontrowersji. Wielu użytkowników narzeka na brak pokrycia tak ważnych tematów jak testy czy acessability. Najwięcej dyskusji wzbudziła jednak strona “Start a New React Project”. Zgodnie z oczekiwaniami społeczności, nie wspomina ona już o przestarzałym i niewspieranym Create React App. Zamiast tego opisuje ona jak wystartować projekt z Next.js, Remix czy Gatsby. I w tym miejscu zaczynają się kontrowersje. Dokumentacja sprowadza aplikacje napisane bez frameworku do nielicznych i bardzo specyficznych przypadków brzegowych. Ba! Gdzie tylko to możliwe dokumentacja odradza rozwijanie aplikacji w ten sposób.

Z jednej strony podejście takie może wydawać się rozsądne. Nowe funkcjonalności Reacta takie jak React Server Components nie będą działać bez wsparcia frameworku. Podadto, framewrki wprowadzają ustandaryzowane rozwiązania dla problemów takich jak routing czy pobieranie danych. Dzięki temu początkowa konfiguracja staje się dużo prostsza i nie wymaga podjęcia wielu trudnych technicznych decyzji.

Z drugiej strony, React od lat szczycił się byciem tylko biblioteką do której odpowiednie klocki można dokładać wedle własnych potrzeb. Wielu zwraca też uwagę, żę wykorzystanie skomplikowanego frameworku do stworzenia na przykład prostego dashboardu, to strzelanie z armaty do muchy. Inaczej mówiąc, Reactowa aplikacja bez frameworku to wciąż popularny przypadek użycia, a nie tylko specyficzny przypadek brzegowy.

Jeśli chcecie zagłębić się w argumenty tej drugiej strony, to CEO .wasp (fullstackowy framework oparty o Reacta) opublikował w tym tygodniu świetny post w którym zagłębia się w temat.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Angular dodaje wsparcie dla required Inputs!

Angular na przestrzeni ostatniego roku zaczął rozwijać się z zadziwiającą prędkością i po kolei adresuje największe bolączki deweloperów. Począwszy od Standalone Components, przez Strictly Typed Forms i Functional Router Guards, po drobne usprawnienia jak Self Closing Tags czy Default Module Exports. Wszystko wskazuje na to, że Angular 16 będzie kontynuował ten trend. Do najnowszej wersji frameworka oprócz opisywanych przez nas kilka tygodni temu Signals, trafią też Required Inputs.

@Component({
  selector: 'app-test',
  template: '<h2>Hello {{name}}</h2>',
  standalone: true,
})
class MyComponent {
  @Input({required: true}) name: string;
}

W przypadku kiedy oznaczymy @Input() jako required, a następnie w dowolnym miejscu w naszej aplikacji zapomnimy przypisać mu wartość, kompilator wyrzuci adekwatny błąd. Do tej pory podobne zachowanie można było przez kilka sprytnych hacków, ale zdecydowanie nie było to ani rozwiązanie intuicyjne, ani czytelne.

@Component({
  selector: 'app-test[name]',
  template: '<h2>Hello {{name}}</h2>',
  standalone: true,
})
class MyComponent {
  @Input() name: string;
}

Być może Required Inputs nie są rewolucją na miarę React Server Components, ale to właśnie na braku takich podstawowych funkcjonalności Angular cierpiał najbardziej. Patrząc holistycznie na zmiany zachodzące w Angularze trzeba przyznać, że framework wreszcie zaczyna zmierzać w odpowiednim kierunku.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

Bonus: Hooki, których prawdopodobnie nie potrzebujesz

Jako, że miniony tydznień nie obfitował w newsy, mamy dla Was mały bonus: listę hooków, których prawdopodobnie nie będziecie potrzebować. Artykuł przygotowany przez Brada Westfalla w detalach opisuje wszystkie małopopularne hooki i wyjaśnia kiedy możecie ich potrzebować. Jeśli szukacie lektury, do sobotniej porannej kawy, to zdecydowanie polecam!

Hooki, których prawdopodobnie nie będziecie potrzebować:
🔴 useDebugValue()
🔴 useInsertionEffect()
🔴 useImperativeHandle()
🟠 useSyncExternalStore()
🟠 useDeferredValue()
🟢 useEffect()
🟢 useLayoutEffect()

🔴 Prawdopodonie nigdy nie użyjesz tego hooka
🟠 Tego hooka użyjesz w kilku rzadkich przypadkach
🟢 Tego hooka powinienieś/powinnaś zacząć używać na codzień

Hooks You Probably Don’t Need