1. Vue 3 będzie wspierać eksport komponentów jako Custom Elements

Web Components na papierze są świetną koncepcją. Zamiast tworzyć bibliotekę podstawowych komponentów w wybranym frameworku, możemy postawić na webowy standard i w efekcie nie uzależniać się od jednego konkretnego rozwiązania na najbliższych kilka lat. Niestety Web Components do dzisiaj nie zyskały (IMO) należnej im popularności i nie zmieniły tego nawet biblioteki takie jak Stencil.js, czy lit-elements, które naprawiały większość problemów ze standardowym API. W moim sercu rośnie jednak ziarnko nadziei, bo zarówno Angular, jak i Vue coraz przychylniej patrzą na ten standard. Angular umożliwia eksportowanie komponentów jako Custom Elements już od wersji 6, a Vue 2 posiadało podobną opcje przy wykorzystaniu biblioteki `@vue/web-component-wrapper`. W tym tygodniu natomiast twórca Vue podzielił się na Twitterze informacją, że wsparcie dla Web Components zmierza do Vue 3 i będzie ono częścią biblioteki standardowej.

Jak pewnie zauważyliście, do pełni szczęścia brakuje nam jeszcze wsparcia największego gracza z wielkiej trójki, czyli Reacta. Co prawda już teraz przy odrobinie zaparcia da się zapakować reactowe komponenty w Custom Elements, ale fajnie byłoby zobaczyć bardziej natywne podejście. A no i samo wykorzystanie Custom Elements w Reactie mogłoby być trochę łatwiejsze.

2. Angular Team rozpoczął pracę nad samodzielnymi komponentami

Jeśli śledzicie nowości dotyczące roadmapy Angulara, to mogliście spodziewać się tej informacji: rozpoczęte zostały prace nad komponentami działającymi bez angularowych modułów. Na razie mamy do czynienia ze spikiem rozwiązania, więc przed nami jeszcze ustalenie ostatecznego API i prawdopodobnie RFC do społeczności. Oznacza to, że samodzielnych komponentów raczej nie zobaczymy w Angularze 13, ale ich pojawienie się w w wersji 14 jest jak najbardziej realne. Osobiście czekam z niecierpliwością, bo moduły od zawsze były dla mnie zbędnym kodem do utrzymania (szczególnie irytującym, że w Vived stosujemy konwencję jeden moduł - jeden komponent).

Źródła:

https://github.com/angular/angular/pull/42831

3. Dlaczego npm audit nie działa

Sezon ogórkowy trwa w najlepsze, dlatego mam dla Was kolejną nienewsową rekomendację, do przeczytania przy kawie. Przyznajcie się, kiedy po raz ostatni analizowaliście podatności, jakie wypisuje npm przy instalacji zależności? Jeśli tak samo jak ja dawno nauczyliście się je ignorować, to podlinkowany artykuł przypomni wam nie tylko jak zły jest "developer experience" npm, ale też jakie kara może się wiązać z tego typu zaniechaniem. Warto przeczytać, chociażby po to, aby przy kolejnym audycie lepiej wytłumaczyć się z setek wyświetlanych na czerwono podatności.

Źródła:

https://overreacted.io/npm-audit-broken-by-design/


Pamiętajcie, żeby spróbować Vived, jeśli chcesz otrzymywać tego typu treści spersonalizowane pod Ciebie!