Frontend Thursday vol. 75 - Vue 3 domyśnlą wersją Vue, nowa biblioteka do zarządzania stanem od yahoo

Vue 3 staje się domyślną wersją Vue

Vue 3 trafiło w maju 2021 roku. Kiedy kolejna duża wersja frameworka od Evana You po raz pierwszy ujrzała światło dzienne nie była jeszcze gotowa, aby w pełni zastąpić poprzednią wersję. Co prawda rdzeń biblioteki był już w pełni gotowy, ale narzędzia ułatwiające migrację dopiero raczkowały, a zdecydowana większość bibliotek rozwijanych przez społeczność wymagała wprowadzenia znaczących modyfikacji.

W czerwcu 2021 doczekaliśmy się Vue 3.1, które dostarczyło programistom wszystko czego potrzebowali, aby sprawnie migrować swoje aplikacje. Po pół roku od pojawienia się niekompatybilnych zmian sporo bibliotek zdążyło już przejść się do Vue 3, ale wciąż daleko było jeszcze do osiągnięcia masy krytycznej.

W wrześniu 2021 zobaczyliśmy Vue 3.2, ale wydanie to skupiało się głównie na usprawnieniach wydajności i Developer Experience. Z czasem do grona rozwiązań wspierających Vue 3 zaczęło dołączać coraz więcej bibliotek.

W ten sposób dotarliśmy do dnia dzisiejszego. Po prawie półtora roku od wydania Vue 3, Evan You na oficjalnym blogu Vue ogłosił, że stanie się ona domyślną wersją tego frameworka. Konsekwencji tej decyzji jest kilka. Po pierwsze tag latest na npm wskazywał będzie od teraz na wersję 3.2, a nie jak do tej pory na 2.6. Dokumentacja również domyślnie przenosić będzie do najnowszej wersji, a archiwalna wersja dostępna będzie po dodaniu do adresu przedrostka v2. Podobnie repozytoria na GitHubie zmieniły domyślne branche, a kilka z nich pozbyło się przyrostka next. Rzecz jasna wszystkie te zmiany dotyczą nie tylko samego Vue, ale również jego ościennych bibliotek, takich jak Vuex czy Vue Router.

Z ciekawości próbowałem dokopać się w internecie do informacji na temat procentu projektów czy deweloperów, którzy zmigrowali się do Vue 3. Najlepsze dane jakie znalazłem to liczba pobrań z npm. W ciągu ostatniego tygodnia Vue 2 został pobrany 3 615 168 razy, natomiast Vue 3 pobrano 797 572 razy. Vue 3 pobierany jest więc 3 razy rzadziej niż Vue 2. Pamiętajcie jednak, że projektom w Vue 2 grunt nie pali się jeszcze pod nogami, bo zbliżające się wydanie 2.7 będzie wersją LTS z 18 miesięcznym wsparcie. Ponadto twórcy zapewniają, że nawet po tym okresie Vue 2.7 otrzymywać będzie krytyczne łatki bezpieczeństwa. Czy Vue podzieli losy Pythona i jeszcze przez długie lata będzie podzielone na dwie niezależne społeczności? Trzymam kciuki, żeby tak się nie stało.

Ostatni Python 2 to Python 2.7. Ostatnie Vue 2 to Vue 2.7. Przypadek?

Źródła:

https://blog.vuejs.org/posts/vue-3-as-the-new-default.html

2. Babel 7.17 dodaje wsparcie dla nowych dekoratorów

W minionym tygodniu doczekaliśmy się kolejnej wersji Babela. Zanim przejdziemy do konkretów wróćmy na chwilę do tematu finansowania projektu. Jeśli czytacie nasze przeglądy regularnie to na pewno pamiętacie mały skandal wokół budżetu na rozwój biblioteki (jeśli o całej spawie nigdy nie słyszeliście to gorąco zachęcam do powrotu do 37 edycji naszego przeglądu). Z ciekawości postanowiłem zerknąć na Open Collective i okazuje się, że przewidywany budżet projektu wciąż nie jest wystarczający dla utrzymania 3 deweloperów. Jestem ciekaw na jak długo starczą jeszcze zaoszczędzone w lepszych czasach pieniądze i czy ostatecznie projekt zmuszony będzie do redukcji zatrudnienia.

Udało nam się zdobyć unikalne nagranie z siedziby zespołu rozwijającego Babel

Przejdźmy jednak do sedna i przyjrzymy się pokrótce nowościom w Babelu 7.17. Gdybym najnowszej wersji musiał nadać podtytuł to byłoby to Babelu 7.17 i wsparcie dla funkcjonalności z Stage 2 ECMA Proposal, bo do najnowszej wersji trafiły aż trzy takie funkcjonalności: dekoratory, RegExp set notation oraz wsparcie dla @@ i ^^ w pipe operator.

Największe zainteresowanie wzbudziło oczywiście wsparcie dla dekoratorów. Pamiętajcie jednak, że dekoratory te nie są w pełni kompatybilne ani z tymi znanymi z TypeScript, ani z tymi znanymi z poprzednich wersji Babela. Aż ciężko uwierzyć, że saga związana z dekoratorami trwa już ponad 5 lat i raczej szybko nie ujrzymy jej zakończenia (o ile kiedykolwiek do takowego dojdzie).

@defineElement("button")
class Button {
  @reactive accessor enabled = true; // class auto accessors

  @event("onClick") #handleClick() { // decorator on a private method
    console.log("clicked!");
  }
}

Ciekawie wygląda też wsparcie dla RegExp set notation. Dzięki wykorzystaniu tej funkcjonalności możliwe będzie dodanie odpowiedniej flagi do wyrażenia regularnego i odfiltrowywanie dużych liter czy Emoji.

"Did you see the 👩🏿‍❤️‍💋‍👩🏾 emoji?".match(/\p{RGI_Emoji}/v). // ["👩🏿‍❤️‍💋‍👩🏾"]

Nowe funkcjonalności wyglądają ciekawie, ale mnie mocno zastanawia dla kogo zostały one przygotowane. Trochę ciężko mi uwierzyć, że deweloperzy w swoich projektach zdecydują się na korzystanie z funkcjonalności, których API nie jest jeszcze ustabilizowane. Jeśli macie odmienne zdanie i wykorzystujecie takie wczesne wsparcie w swoich projektach to z chęcią zapoznam się z waszymi komentarzami.

Przyznajcie szczerze, kto jeszcze ekscytuje się kolejnymi wydaniami Babela?? Bo ja czytając release notes wyglądam jak Bart w gifie powyżej.

Źródła:

https://babeljs.io/blog/2022/02/02/7.17.0

3. behaviour-graph, czyli nowa biblioteka do zarządzania stanem od yahoo

Jak to mówią: tydzień bez nowej frontendowej biblioteki to tydzień stracony. Ten zaś uratowali deweloperzy z yahoo, którzy zaprezentowali nową bibliotekę do zarządzania stanem – behaviour-graph.

Ku mojemu zaskoczeniu czytając dokumentację tego najnowszego cudeńka poczułem pewien powiew świeżości, bo dawno w świecie zarządzania stanem na frontendzie nie widziałem tak nieszablonowego podejścia. Niezależnie od tego czy sama biblioteka mi się podoba czy nie za ten wyczyn twórcom behaviour-graph należą się brawa.

Podstawową jednostką w bibliotece są Behaviours, które mogą przyjmować dowolną liczbę wejść (demands) i odpowiedzialne są za maksymalnie jedno wyjście (supply). Jak się pewnie domyślacie wyjścia jednego behaviour mogą być wejściami kolejnego, co prowadzi do powstania grafu zależności. Myślę, że bardzo dobrze pokazuje to przykład z termostatem zaciągnięty z dokumentacji, który znajdziecie poniżej.

Prosty na papierze koncept po przeniesieniu do kodu nie jest już niestety, aż tak przejrzysty. Korzystanie z biblioteki zaczynamy od stworzenia grafu, który odpowiedzialny będzie za zapewnienie zasad wspomnianych w poprzednim akapicie, za propagację zmian do kolejnych behaviours. Dzięki metodzie action graf umożliwia również aktualizowanie tych pól, które nie są supply, żadnego z behaviours. Stan, czyli zarówno behaviours jaki same pola przechowywane będą w klasie, która rozszerzać musi dostarczaną przez bibliotekę klasę Extent. Pola odpowiedzialne za przechowywane stanu zainicjalizować należy w konstruktorze wykorzystując metodę state(“name‘). Konstruktor jest również dobrym miejscem do umieszczenia definicji behaviours. Wszystkie aktualizacje pól odbywać się muszą poprzez metodę update, która zwróci błąd jeśli zostanie wywołana w złym kontekście (np. przez behaviour, który nie zadeklarował jej jako supply).

import * as bg from "https://cdn.skypack.dev/behavior-graph";

let g = new bg.Graph();

class PersonExtent extends bg.Extent {
  constructor(graph) {
    super(graph);
    
    this.personName = this.state("Nobody");
    this.personSurname = this.state("Nobody");
    this.personFullName = this.state(“Nobody Nobody”)

    this.behavior()
      .supplies(this.desiredTemperature)
      .demands(this.personName, this.personSurname)
      .runs(() => {
        this.personFullName.update(this.personName.value + " " + this.personSurname.value);
      });

  this.behaviour()
    .demands(this.personFullName)
    .runs(() => {
       this.sideEffect(() => {
         document.querySelector('#name).innerText = this.personFullName.value;
       });
    });
  }
}

let e = new PersonExtent(g);

e.addToGraphWithAction();

g.action(() => {
  e.personName.update("Tomek");
  e.personSurname.update(“Brzęczyszczykiewicz”);
})

Jeśli moje tłumaczenie wydaje się Wam zawiłe to zachęcam Was do zerknięcia do dokumentacji podlinkowanej w źródłach. Zrozumienie tego mentalnego modelu było dla mojego mózgu świetnym ćwiczeniem, a im dłużej przyglądałem czytałem o nowym rozwiązaniu tym bardziej mnie ono przekonywało. Jako fan DDD w Behaviours widzę mocne odniesienia do Worklfows znanych z funkcyjnego podejścia do DDD, a w wymuszonym podziale odpowiednik Bounded Contexts. Niestety w dokumentacji nie znajdziecie nawet najmniejszej wzmianki o integracji z Reactem, Vue czy Angularem. Dopóki ktoś nie pokusi się o przygotowanie odpowiednich integracji, nie wróżę bibliotece świetlanej przyszłości.