Amazon Simple Storage Service (S3) to platforma chmurowa oferująca bezpieczne i skalowalne przechowywanie obiektów. Jest to popularny wybór do hostowania statycznych stron internetowych, aplikacji internetowych, a nawet obrazów i filmów. S3 słynie z prostoty użytkowania, niskich kosztów i niezawodności.

Dlaczego warto hostować Angulara na AWS S3?

• Prostota: S3 jest niezwykle łatwy w konfiguracji i użytkowaniu. Wystarczy utworzyć bucket, przesłać pliki aplikacji i skonfigurować adres URL.
• Skalowalność: S3 może automatycznie skalować się w górę lub w dół w zależności od potrzeb aplikacji. Bez względu na to, czy obsługujesz ruch z kilku osób, czy z milionów użytkowników, S3 poradzi sobie z tym bez problemu.
• Niskie koszty: S3 oferuje darmowy plan, który obejmuje 5 GB pamięci masowej i 20 000 żądań miesięcznie. To świetne rozwiązanie do testowania i hostowania małych aplikacji. Nawet po wyczerpaniu darmowego poziomu, S3 nadal oferuje konkurencyjne ceny.
• Wysoka dostępność: S3 replikuje dane w wielu centrach danych na całym świecie, co zapewnia wysoką dostępność i odporność na awarie.
• Bezpieczeństwo: S3 oferuje szereg funkcji bezpieczeństwa, które chronią Twoje dane przed nieautoryzowanym dostępem.

Praca z AWS to nie tylko ułatwienie hostingu, ale również doskonała okazja do rozwoju zawodowego. AWS jest niezwykle popularny na rynku IT, a umiejętność jego obsługi to cenny atut w CV każdego dewelopera. Znajomość S3 może ułatwić Ci znalezienie nowej pracy, awans zawodowy, a nawet przejście do roli DevOpsa, gdzie umiejętność zarządzania infrastrukturą chmurową jest wysoko ceniona.

1. Zakładanie nowego konta na AWS

Wchodzimy na stronę rejestracyjną AWS:  https://portal.aws.amazon.com/billing/signup

Będziemy potrzebowali potwierdzić kilka danych w procesie rejestracji:

• E-mail
• Numer telefonu
• Dane karty kredytowej (można użyć tymczasowej np. Revolut)

Pierwsze logowanie i wstępne ustawienia

Po poprawnej rejestracji logujemy się do panelu adresem e-mail i hasłem.

Na początku dobrze sobie wybrać lokalizację, w której będą tworzone nasze usługi.

Dostępne lokalizacje widoczne są w prawym górnym rogu panelu.

Domyślnie będzie lokalizacja gdzieś w Stanach Zjednoczonych. Żeby mieć trochę lepsze pingi (czasy odpowiedzi serwera) polecam ustawić lokalizacje usługi na coś bliżej nas lub grupy docelowej aplikacji.

W przypadku Polski, polecam ustawić Frankfurt, albo inny region zaczynający się od eu.

Z kolei w lewym górnym rogu możemy zapoznać się z dostępnymi serwisami, wyszukać konkretnej usługi i dodać je do ulubionych.

W tym celu klikamy w pole wyszukania, wpisujemy S3 i klikamy gwiazdkę, aby dodać usługę do paska ulubionych. Dzięki temu szybciej dostaniemy się do naszych najważniejszych usług w przyszłości.

2. Tworzenie nowego bucketu S3

Wchodzimy w usługę S3 (z pasku na górze) i klikamy utworzenie nowego bucketa - czyli przestrzeni w której przechowywana będzie nasza zbudowana aplikacja Angularowa.

W części głównej konfiguracji nowego bucketa wpisujemy nazwę, która musi być unikatowa. Resztę pozostawiamy bez zmian.

W sekcji 'Object Ownership' zostawiamy domyślne ustawienia, czyli 'ACLs disabled' - nie będziemy korzystali z tej opcji.

Następnie mamy część z ustawieniami dostępu. Tutaj musimy odznaczyć opcję 'block all public access', ponieważ chcemy aby nasza aplikacja była dostępna publicznie.

Pozostałe sekcje:
- Bucket Versioning,
- Tags,
- Default encryption
zostawiamy bez zmian.

Ustawienia zaawansowane również w tym przypadku nas nie dotyczą.

Przechodzimy na sam dół strony i klikamy w prawym dolnym rogu 'Create bucket'

Po tym zabiegu przeniesie nas do listy bucketów, na której zobaczymy nowo utworzony kontener

3. Konfiguracja AWS S3 pod Web Hosting

Mamy utworzony nowy bucket i jest do niego publiczny dostęp, ale potrzebujemy dodać jeszcze kilka reguł i przede wszystkim — aktywować na nim usługę Web Hostingu.

Aktywowanie usługi Web Hostingu na S3:

Na liście bucketów, klikamy w nasz nowo utworzony, następnie przechodzimy w zakładkę "Properties"

Zjeżdżamy na sam dół strony i klikamy "Edit" w sekcji "Static website hosting"

W ekranie edycji:

• aktywujemy opcje "Static website hosting"
• upewniamy się, że mamy zaznaczoną opcję "Host a static website"
• Ustawiamy w polach "Index document" oraz "Error document" tą samą wartość: index.html

Zapisujemy zmiany i jeżeli wszystko jest dobrze wypełnione, zostaniemy przekierowani na detale naszego bucketa, do zakładki "Properties".

Ponownie przechodząc na sam dół strony, powinniśmy widzieć informacje o aktywowanym Static website hostingu oraz link do naszej publicznej witryny

Jednak gdy spróbujemy przejść na dedykowany adres URL, dostaniemy błąd 403 - brak dostępu. Dlatego musimy jeszcze przypisać odpowiednie reguły dostępowe.

Określenie reguł dostępowych

Ciągle będąc w widoku detalu naszego bucketa, przechodzimy do zakładki "Permissions" i klikamy "Edit" w sekcji "Bucket policy".

W polu tekstowym wpisujemy następującą konfiguracje:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Principal": "*",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::nazwa-bucketa/*"
      ]
    }
  ]
}

W naszym przykładowym bucketcie, pełna prawidłowa konfiguracja wygląda tak:

Zapisujemy zmiany. Przechodzimy do zakladki "Properties", zjeżdżamy na sam dół strony i jeszcze raz próbujemy wejść na dedykowany dla tego bucketa adres URL.

Jeżeli wszystko zrobiliśmy dobrze, to teraz powinien nam się wyświetlić błąd 404:

Co oznacza, że dostępy są dobrze skonfigurowane. Błąd wynika z tego, że nie wrzuciliśmy jeszcze plików aplikacji na nasz hosting S3.

Jeżeli wrzucilibyśmy jakiś plik index.html, to już prawidłowo się wyświetli.

No ale przejdźmy teraz do aplikacji Angularowej.

4. Tworzenie nowej aplikacji

Zapewne posiadasz już jakąś aplikację napisaną w Angularze, ale na wszelki wypadek zacznijmy od początku, czyli utworzenia podstawowej aplikacji zgodnie z dokumentacja dostępną na oficjalnej stronie angular.io.

W wielkim skrócie:

1. Instalujemy node.js wraz z npm (najlepiej przez nvm)
2. Instalujemy globalnie Angular CLI poleceniem w terminalu:
   npm install -g @angular/cli
3. Inicjujemy nowy projekt Angular poleceniem:
   ng new my-app
   i odpowiadamy na pojawiające się pytania zgodnie z naszymi preferencjami.
4. Dla pewności uruchamiamy aplikację przez:
   npm run start
   i sprawdzamy w przeglądarce czy aplikacja prawidłowo się wyświetla pod adresem http://localhost:4200

W przypadku Angular v17 domyślna strona powinna wyglądać ta:

5. Budowanie aplikacji

Gdy jesteśmy już pewni, że posiadamy działającą aplikację, możemy przejść do procesu budowania.

W tym poradniku będziemy budowali aplikacje lokalnie, a wynik budowania przerzucimy na AWS S3.

W kolejnym poście zautomatyzujemy ten proces z wykorzystaniem GitHub Actions. Subskrybuj, aby być na bieżąco z aktualnościami

Budowanie aplikacji odbywa się standardowo, przez wywołanie polecenia npm run build.

Po zakończonym procesie budowania powinniśmy zobaczyć w naszym projekcie nowy folder o nazwie dist, w którym znajduje się nasza zbudowana aplikacja, a konkretnie:

my-app/
├─ dist/
│  ├─ my-app/
│  │  ├─ browser/

Proces budowania i wygenerowane pliki powinny wyglądać przykładowo w taki sposób:

Tak wygenerowane pliki, możemy już wrzucać na nasz skonfigurowany bucket S3.

6. Wrzucenie zbudowanej aplikacji na AWS S3

To już ostatni krok, żeby osiągnąć nasz cel.

Wchodzimy ponownie na stronę z detalami naszego skonfigurowanego bucketa. Przechodzimy do zakładki "Objects" i klikamy w przycisk "Upload"

Klikamy "Add files" i dodajemy wszystkie pliki z naszej zbudowanej aplikacji Angular, czyli w naszym przypadku zawartosc folderu my-app/dist/my-app/browser/

Po dodaniu plików upewniamy się, że lista plików zgadza się z tym co mamy lokalnie na komputerze.

Jeżeli wszystko jest ok, nic więcej nie zmiemiamy, tylko klikamy "Upload" w prawym dolnym rogu

Zostaniemy następnie poinformowani, czy wszystkie pliki wgrały sie prawidłowo.

I na tym koniec!

Pozostaje ponownie odwiedzić nasz dedykowany adres URL i cieszyć się z opublikowanej aplikacji Angularowej 👏

Podsumowanie

W tym artykule poznaliśmy prostą i skuteczną metodę hostowania aplikacji Angulara na AWS S3.
Przeszliśmy przez 6 kroków, które obejmowały konfigurację konta AWS, utworzenie bucketa S3, skonfigurowanie hostingu statycznego, ustawienie reguł dostępu i wgranie zbudowanej aplikacji.

Warto również wspomnieć, że AWS S3 doskonale nadaje się nie tylko do hostowania aplikacji Angulara. Możemy tam również umieszczać aplikacje napisane w React.js, Astro czy proste strony statyczne.
Dzięki temu zyskujemy uniwersalną platformę hostingową, która spełni potrzeby wielu projektów webowych zarówno hobbystycznych, jak i komercyjnych.

Dodatkowe linki:

• Oficjalna strona AWS S3: https://aws.amazon.com/s3/
• Oficjalna dokumentacja Angulara: https://angular.io/
• Oficjalna dokumentacja React.js: https://react.dev/

W części 1 artykułu przedstawiliśmy podstawowe informacje o sygnałach w Angularze 16. W tej części omówimy bardziej szczegółowo działanie sygnałów i ich zastosowanie w praktyce.

Działanie sygnałów

Sygnały działają na zasadzie obserwowalności (observable). Każdy sygnał ma swoją własną kolejkę zdarzeń, do której dodawane są emitowane wartości. Komponenty, które są subskrybowane na sygnale, są automatycznie informowane o nowych wartościach w kolejce zdarzeń.

Wartości emitowane przez sygnały mogą być dowolnego typu danych. Mogą to być liczby, tekst, obiekty, listy, czy mapy.

Subskrypcja na sygnały

Aby subskrybować się na sygnał, należy użyć metody subscribe(). Metoda subscribe() przyjmuje funkcję jako parametr. Funkcja ta jest wykonywana po zmianie wartości sygnału.

Metoda subscribe() może przyjmować również inne parametry, takie jak:

• next(): parametr ten jest używany do przekazywania wartości sygnału do funkcji.
• error(): parametr ten jest używany do przekazywania błędów do funkcji.
• complete(): parametr ten jest używany do informowania o zakończeniu subskrypcji.

Kiedy stosować sygnały

Sygnały mogą być używane w różnych sytuacjach w aplikacjach Angularowych. Oto kilka przykładów zastosowania sygnałów:

• Komunikacja pomiędzy komponentami
  sygnały mogą być używane do przekazywania danych pomiędzy komponentami.
• Wydawanie zdarzeń
  sygnały mogą być używane do emitowania zdarzeń, które mogą być obsługiwane przez inne komponenty lub usługi.
• Podtrzymanie stanu aplikacji
  sygnały mogą być używane do podtrzymywania stanu aplikacji.

Kiedy nie stosować sygnałów

Sygnały to potężne narzędzie, ale nie powinno się ich używać w każdym przypadku. Oto kilka sytuacji, w których nie należy stosować sygnałów:

• Do przekazywania danych, które nie są zmienne: jeśli dane nie są zmienne, to nie ma potrzeby ich przekazywania za pomocą sygnałów. W takim przypadku można po prostu użyć właściwości komponentu.
• Do przekazywania danych, które są używane tylko w jednym komponencie: jeśli dane są używane tylko w jednym komponencie, to nie ma potrzeby ich przekazywania za pomocą sygnałów. W takim przypadku można po prostu użyć właściwości komponentu lub innej metody dostępu do danych.
• Do przekazywania danych, które są używane tylko w jednym cyklu detekcji zmian: jeśli dane są używane tylko w jednym cyklu detekcji zmian, to nie ma potrzeby ich przekazywania za pomocą sygnałów. W takim przypadku można po prostu użyć właściwości komponentu lub innej metody dostępu do danych.

Kilka dodatkowych wskazówek, które pomogą Ci zdecydować, czy użyć sygnału

• Jeśli nie jesteś pewien, czy użyć sygnału, to lepiej go nie używać.
• Jeśli musisz przekazać dane pomiędzy komponentami, to sygnał jest dobrym wyborem.
• Jeśli musisz emitować zdarzenia, to sygnał jest dobrym wyborem.
• Jeśli musisz podtrzymywać stan aplikacji, to sygnał jest dobrym wyborem.

Przykład zastosowania sygnału do podtrzymywania stanu aplikacji i inkrementacji

// Komponent emitujący sygnał
@Component({
  selector: 'my-component',
  templateUrl: './my-component.component.html',
  styleUrls: ['./my-component.component.css']
})
export class MyComponent {

  @Output() mySignal = new EventEmitter();

  constructor() {
    this.myState = 10;
  }

  onIncrement() {
    this.myState++;
    this.mySignal.emit(this.myState);
  }

}

// Komponent subskrybujący się na sygnał
@Component({
  selector: 'my-subscriber',
  templateUrl: './my-subscriber.component.html',
  styleUrls: ['./my-subscriber.component.css']
})
export class MySubscriber {

  constructor(private readonly myComponent: MyComponent) {
    this.myComponent.mySignal.subscribe((value) => {
      console.log(value);
    });
  }

}

// HTML

<div class="my-component">
  <button (click)="myComponent.onIncrement()">+</button>
</div>

W tym przykładzie sygnał jest używany do podtrzymywania stanu liczbowego komponentu MyComponent. Kiedy użytkownik kliknie przycisk +, wartość stanu komponentu zostanie zwiększona o 1. Sygnał mySignal zostanie również wyemitowany, aby poinformować inne komponenty o zmianie stanu.

Podsumowanie

Sygnały to potężne narzędzie, które może znacząco ulepszyć wydajność i responsywność aplikacji Angularowych. Jeśli jeszcze nie korzystasz z sygnałów, warto się z nimi zapoznać.

Angular 16 wprowadził szereg nowości, z których jedną z najbardziej znaczących jest wprowadzenie sygnałów. Sygnały to nowy sposób przekazywania danych pomiędzy komponentami, który jest bardziej reaktywny i wydajny niż tradycyjne metody.

Zalety sygnałów

Sygnały oferują szereg korzyści w porównaniu do tradycyjnych metod przekazywania danych:

• Są bardziej reaktywne: sygnały automatycznie wykrywają zmiany i propagują je do komponentów, które są na nich subskrybowane. Dzięki temu dane są zawsze aktualne, bez konieczności stosowania jawnych subskrypcji.

W tradycyjnych metodach przekazywania danych, takich jak przekazywanie właściwości lub metod, należy jawnie subskrybować się na zmianę wartości. Oznacza to, że komponent musi wykonać dodatkową operację, aby sprawdzić, czy wartość się zmieniła. Sygnały eliminują tę potrzebę, automatycznie informując komponenty o zmianach.

• Są bardziej wydajne: sygnały nie wymagają tworzenia obiektów obserwowalnych, co może znacząco poprawić wydajność aplikacji.

Obiekty obserwowalne są używane do przekazywania danych pomiędzy komponentami w tradycyjnych metodach. Są one obiektami, które monitorują zmiany wartości i informują o nich subskrybentów. Sygnały nie wymagają tworzenia obiektów obserwowalnych, ponieważ mogą same monitorować zmiany wartości.

• Są bardziej elastyczne: sygnały mogą być używane do przekazywania dowolnego typu danych, w tym obiektów, list i map.

Obiekty obserwowalne są ograniczone do przekazywania danych typu obiektu. Sygnały nie mają tej ograniczenia i mogą być używane do przekazywania dowolnego typu danych.

Jak używać sygnałów

Użycie sygnałów jest bardzo proste. Aby utworzyć sygnał, należy użyć adnotacji @Output():

@Output() mySignal = new EventEmitter();

Adnotacja @Output() tworzy obiekt EventEmitter, który jest używany do emitowania wartości sygnału.

Aby subskrybować się na sygnał, należy użyć metody subscribe():

component.mySignal.subscribe((value) => {
  // Wykonaj akcję po zmianie wartości sygnału.
});

Metoda subscribe() przyjmuje funkcję jako parametr, która jest wykonywana po zmianie wartości sygnału.

Przykład zastosowania sygnałów

Poniżej znajduje się przykład zastosowania sygnałów:

// Komponent emitujący sygnał
@Component({
  selector: 'my-signal-component',
  templateUrl: './my-signal-component.component.html',
  styleUrls: ['./my-signal-component.component.css']
})

export class MySignalComponent {

  @Output() mySignal = new EventEmitter();

  constructor() {
    this.mySignal.emit(10);
  }

}

// Komponent subskrybujący się na sygnał
@Component({
  selector: 'my-subscriber',
  templateUrl: './my-subscriber.component.html',
  styleUrls: ['./my-subscriber.component.css']
})

export class MySubscriber {

  constructor(private readonly mySignalComponent: MySignalComponent) {
    this.mySignalComponent.mySignal.subscribe((value) => {
      console.log(value);
    });
  }

}

Wynik działania tego kodu:

10

W tym przykładzie komponent MyComponent emituje wartość 10 za pomocą sygnału mySignal. Komponent MySubscriber subskrybuje się na sygnale mySignal i wyświetla wartość w konsoli po jej zmianie.

Kontynuacja w części 2

W części 2 artykułu omówimy bardziej szczegółowo działanie sygnałów i ich zastosowanie w praktyce.

Bitbucket, poza tym, że jest serwisem na którym możemy trzymać swoje repozytoria GIT, pozwala nam także na odpalanie Pipeline'ów.

Podobną funckjonalność oferują inne popularne hostingi GITa, takie jak Github (Actions) czy Gitlab (Pipelines). Poza tym, mamy możliwość korzystania z dedykowanych aplikacji zewnętrznych, aby osiągnąć ten sam cel - możemy tutaj wymienić między innymi takie narzędzia jak Circle CI, Travis czy Jenkins.

Uruchomianie Pipeline'ów ma na celu automatyzacje pewnych czynności, takich jak uruchamianie testów, sprawdzanie jakości kodu czy deployment. W skrócie, te akcje, nazywamy CI / CD i stanowią one już pewnego rodzaju standard przy budowaniu nowoczesnych aplikacji. Więcej na ten temat napiszemy w innym poście.

Na tą chwilę, ważne żebyś wiedział, każdy dostawca CI / CD, jak to w życiu bywa, ma zarówno pewne zalety jak i wady. Bitbucket nie jest tutaj wyjątkiem. Dzisiaj postaramy się rozwiązać jeden z problemów, którym jest zdalne odpalanie pipelinów.

Po co nam zdalny dostęp do Pipelines?

Zazwyczaj, konkretny Pipeline, czyli konkretne akcje, wykonywane są po wykryciu zdefiniowanej czynności w repozytorium GIT. Najczęściej jest to Pull Request do repozytorium lub wykrycie zmian w kodzie, na konkretnym branchu.

W innych przypadkach, możemy również ustawić odpalanie Pipeline'a w określonym czasie, cyklicznie. Może być to przydatne przy odpalaniu testów End-to-End, aby sprawdzać, czy nie ma regresji i kluczowe funkcjonalności naszej aplikacji działają jak należy.

Zdalny dostęp może się jednak przydać, gdy chcemy aby Pipeline wystartował w momencie wystąpienia jakichś zmian poza naszym repozytorium GIT. Konkretny use case na który ostatnio natrafilem:

• Wykorzystując frontendowe frameworki takie jak Gatsby czy Next.js, budujemy aplikację frontendową, składa się ona ze statycznych plików HTML
• Statyczne pliki budowane są na podstawie zawartości zewnętrznego CMSa (np Wordpress, Strapi)
• Ktoś wprowadzi zmiany w panelu administracyjnym, doda nowy wpis, edytuje lub usunie już istniejący
• Aplikacja frontendowa powinna się przebudować, aby wygenerować dane zgodne z aktualną zawartością znajdującą się w CMSie.

Dzięki temu, w automatyczny sposób możemy zautomatyzować proces deploymentu mega szybkiej aplikacji, która nie będzie potrzebowała łączenia się z zewnętrznymi serwerami w celu pobierania danych do wyświetlenia. Jest to fajna opcja na prowadzenie niewielkiego bloga czy rzadko aktualizowanej strony, którą jednak chcemy zarządzać z poziomu panelu.

W takim właśnie przypadku, chcielibyśmy poinformować Bitbucket'a o tym, że doszło do jakichś zmian wymagających odpalenia Pipeline'a - w tym przypadku odpowiadającego za przebudowanie aplikacji i deployment.

Ograniczenia i możliwości Bitbucketa

Niektóre aplikacje umożliwiają stworzenie webhooka, którego wystarczy podpiąć w odpowiednie miejsce i aplikacja frontowa może się nam przebudować. Przykładem jest tutaj Strapi CMS + Vercel, w którym możemy sobie wygenerować klucz i podpiąć go w CMSie pod odpowiednie czynności, takie jak dodanie nowego wpisu. Dzięki temu zabiegowi, konkretne zmiany będą automatycznie odpalały budowanie się aplikacji. Super fajne!

Bitbucket Pipeline nie ma możliwości, aby w ultra prosty sposób odpalić dowolny Pipeline. Nie możemy 'wyklikać' sobie linku, pod który po prostu strzelimy i konkretny Pipeline się odpali.. Znaczy, uderzać pod pewien endpoint musimy, ale nie jest to aż takie proste.

Dodatkowo, Bitbucket Pipelines zachowują się domyślnie w sposób, który w tym przypadku stwarza dodatkowe problemy. Otóż jeżeli konkretny Pipeline jest już uruchomiony i trwa, to kolejny, tak samo zdefiniowany Pipeline, automatycznie przechodzi w stan pauzy i możemy go uruchomić ponownie tylko ręcznie. My natomiast chcemy, aby nowy Pipeline powodował zatrzymanie wcześniejszego i rozpoczynał swoją pracę. Niestety, musimy ten przypadek również obsłużyć ręcznie.

Na szczęście, Bitbucket oferuje dość szerokie możliwości za pośrednictwem dedykowanego API. Możemy dzięki temu komunikować się z naszymi Pipeline'ami  (i nie tylko) z zewnątrz.

Tak więc.. do dzieła!

Strapi CMS + Bitbucket Pipeline

W naszym konkretnym przypadku, będziemy bazowali na Strapi CMS - który odpowiada za dostarczanie treści do aplikacji frontowej. Po dokonaniu zmian w panelu CMSa, odpalimy konkretny Pipeline Dodatkowo,  chcemy zastopować poprzedni, jeżeli nadal trwa.

No ale po kolei:

1. Gdy nasze repozytorium na Bitbucket jest prywatne, musimy wygenerować sobie hasło aplikacji - aby móc autoryzować nasze strzały do API. Jeżeli jest publiczne, pomiń ten krok.
2. W aplikacji backendowej (Strapi), definiujemy podstawową konfiguracje, uwzględniając między innymi headery czy właśnie dane dostępowe. Wykorzystamy w tym celu bibliteke Axios:

baseUrl = "https://api.bitbucket.org/2.0/repositories/<workspace>/<repository>/"

// Default axios settings for BitBucket connections
export const BitBucketClient = axios.create({
  baseURL: baseUrl,
  timeout: 2000,
  headers: {
    "Content-Type": "application/json",
  },
  auth: {
    username: "username",
    password: "bitbucketAppPassword",
  },
})

baseUrl - jest głównym adresem, pod którym będziemy sie komunikować z Bitbucket'em. Najprościej wejść w konkretne repozytorium w przeglądarce i w URLu pojawi się nam podobny zapis, z którego będziemy mogli przekleić <workspace> oraz <repository>.

3.  Przygotujmy metodę, która pozwoli nam uderzać do Bitbucket, informując o konieczności ręcznego odpalenia Pipeline'a:

export const invokePipeline = async (): Promise<void> => {
  await BitBucketClient.post(`/pipelines/`, {
    target: {
      ref_type: "branch",
      type: "pipeline_ref_target",
      ref_name: "production", //Name of target branch
    },
  })
}

Na dobrą sprawę, tyle nam wystarczy, żeby zdalnie odpalić Pipeline. Teraz wystarczy tylko w odpowiednim miejscu wywołać funkcje invokePipeline. W przypadku Strapi CMS, jest to plik lifecycles.ts , w którym mamy dostęp do metod cykli życia kolekcji danych.

4.  Wywołanie funkcji invokePipeline

// lifecycles.ts

export default {
  afterCreate(event: { params: { data: Record<string, unknown> } }) {
    invokePipeline()
  },
  afterUpdate(event: { params: { data: Record<string, unknown> } }) {
    invokePipeline()
  },

  afterDelete(event: { params: { data: Record<string, unknown> } }) {
    invokePipeline()
  },
}

W ten sposób, nasz Pipeline, będzie się odpalał za każdym razem gdy dodamy, zaktualizujemy lub usuniemy jakąś stronę kolekcji.

W przypadku innych CMSów, trzeba po prostu znaleźć odpowiednie miejsce gdzie można się wpiąć.

Pamiętajmy jednak, że dobrze jest zamknąć trwający, wcześniejszy Pipeline - jeżeli ktoś przykładowo w krótkim czasie doda i edytuje wpis. Potrzebujemy do tego następujace funkcje

5. Najpierw musimy pobrać ostatnie Pipeline'y i sprawdzić, czy któryś z nich jest aktywny. Jeżeli tak, to zwracamy jego UUID - który jest unikalny identyfikatorem, potrzebnym, żeby w następnym kroku powiedzieć który Pipeline chcemy zatrzymać

const getActivePipelineUUID = async (): Promise<string | undefined> => {
  //Get pipelines by newest
  const res = await BitBucketClient.get(`/pipelines/?sort=-created_on`)
  if ([201, 200].indexOf(res.status) === -1) return

  //Only values of pipelines
  const pipelines = res.data.values

  if (pipelines && pipelines.length) {
  
    //Find pipeline data of our branch ("production")
    const latestBranchPipeline = pipelines.find((p: any) => p.target?.ref_name === "production")
    if (!latestBranchPipeline) return

    const triggeredManually = latestBranchPipeline.trigger.type === "pipeline_trigger_manual"
    const isInProgress = ["pipeline_state_in_progress", "pipeline_state_pending"].includes(
      latestBranchPipeline.state.type,
    )

    return triggeredManually && isInProgress ? latestBranchPipeline.uuid : undefined
  }
}

6. No i jeszcze potrzebujemy metodę stopującą pipeline

const stopPreviousPipeline = async (uuid: string): Promise<number> => {
  const res = await BitBucketClient.post(`/pipelines/${uuid}/stopPipeline`)
  return res.status
}

7.  Teraz możemy nasze pomocnicze metody sprawdzające, użyć w metodzie głównej invokePipeline

export const invokePipeline = async (): Promise<void> => {

  const activePipelineUUID = await getActivePipelineUUID()
  if (activePipelineUUID) await stopPreviousPipeline(activePipelineUUID)

  const res = await BitBucketClient.post(`/pipelines/`, {
    target: {
      ref_type: "branch",
      type: "pipeline_ref_target",
      ref_name: bitBucketBranch,
    },
  })
}

To tyle. Po wprowadzeniu tych zmian, za każdym razem gdy zmienimy coś w naszym źródle danych - CMSie, odpowiedni Pipeline odpali się powodując przebudowanie aplikacji.

Oczywiście dodatkowo polecam zabezpieczyć tą funkcjonalność o sprawdzenie, czy jesteśmy na wersji produkcyjnej - przez chociażby wykorzystanie zmiennych środowiskowych.

Bitbucket API daje nam dużo więcej możliwości, możemy między innymi odpalać konkretne commity, czyścić cache i wiele więcej. Po szczegóły zapraszam do oficjalnej dokumentacji API https://developer.atlassian.com/cloud/bitbucket/rest/api-group-pipelines/#api-group-pipelines

Nie będziemy się tutaj zbytnio rozpisywać na temat samego Ghost CMS. Natomiast, dobrze żebyś wiedział, o czym w ogóle piszemy i dlaczego.

Ghost CMS, najprościej mówiąc, jest alternatywą dla bardzo popularnego Wordpressa. Również powstał z myślą o autorach blogów, aby w prosty sposób mogli prowadzić swoje internetowe dzienniki.

Główną różnicą między tymi systemami jest to, Ghost jest napisany w JSie (Node.js), natomiast Wordpress w PHP.
Ghost jest nowocześniejszym rozwiązaniem, ale i mniej przeładowanym. Mimo ciągłego rozwoju, system ciągle skupia się na byciu platformą blogową, gdzie Wordpress już dawno stał się kombajnem, którego wielu używa do prowadzenia sklepów, stron szkoleniowych czy innych.. Często nawet pozbawionych głównej funkcji - czyli blogu.

Tyle wystarczy słowem wstępu, temat zgłębimy bardziej w osobnym wpisie, porównującym oba systemy.

Syntax highlighter

Wiemy już, że Ghost CMS może być ciekawym rozwiązaniem dla osób chcących prowadzić swój blog. Jednak jeżeli ma to być blog techniczny, jedną z głównych funkcjonalności jaką potrzebujesz do pisania rzeczowych postów, jest Syntax highlighter - czyli podświetlanie składni, kawałków kodu pisanych w różnych językach.

Ghost, domyślnie oferuje pisanie bloków kodu (również pełny Markdown), jednak nie ma wbudowania kolorowania składni. Funkcjonalność ta musi zostać przez nas dopisana. I możemy to zrobić na kilka sposobów.

We wszystkich opisanych poniżej sposobach, będziemy implementowali w tym celu bibliotekę PrismJS - która już od dawna znajduje się w ścisłej czołówce bibliotek oferujących kolorowanie składni dla wielu języków programowania.

Sposób 1 - Code Injection

Najprostszym sposobem, jest podpięcie biblioteki PrismJS bezpośrednio w Panelu Administracyjnym Ghost.

1. Logujemy się do Panelu Ghost
2. Wchodzimy w Settings > Code Injection
3. W sekcji Site Header wrzucamy link do CSSa ze stylami Prism, które najbardziej nam odpowiadają np Okaidia:

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/themes/prism-okaidia.min.css" integrity="sha384-qTzu9jz8wpyzFe5KLoZfw0CS5iY+kCoZlBd5ByJ3f0NUT9dgCIU19M1IQKj594Ei" crossorigin="anonymous" referrerpolicy="no-referrer">

4.  W sekcji Site Footer podpinamy niezbędne pliki JS:

<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/components/prism-core.min.js" integrity="sha384-MXybTpajaBV0AkcBaCPT4KIvo0FzoCiWXgcihYsw4FUkEz0Pv3JGV6tk2G8vJtDc" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/plugins/autoloader/prism-autoloader.min.js" integrity="sha384-Uq05+JLko69eOiPr39ta9bh7kld5PKZoU+fF7g0EXTAriEollhZ+DrN8Q/Oi8J2Q" crossorigin="anonymous" referrerpolicy="no-referrer"></script>

5.  Zapisujemy zmiany i kolorowanie składni już działa!

Podpięcie biblioteki powinno wyglądać tak:

Sposób 2 - Zmiany w szablonie (ręczne ściągnięcie plików)

Gdy mamy możliwość edycji naszego szablonu, z pewnością lepszym rozwiązaniem będzie podpięcie PrismJS bezpośrednio w kodzie. Najpierw zrobimy to w sposób bardziej manualny - czyli przez ręczne ściągnięcie potrzebnych plików.

1. Wchodzimy na oficjalną stronę PrismJS
2. Wybieramy tam szablon i języki jakie chcemy obsługiwać
3. Pobieramy wygenerowaną paczkę (JS i CSS)
4. Pobrany plik CSS wrzucamy do folderu assets/css w naszym szablonie Ghosta i importujemy go w pliku assets/css/screen.css

@import "prismjs/themes/prism.css"

5.  Pobrany plik JS przenosimy do folderu assets/js/lib - i to wszystko

6.  Restartujemy Ghost CMS / przebudowujemy szablon i cieszymy się eleganckim syntax highlightningiem.

Sposób 3 - Zmiany w szablonie (npm / yarn)

Jest to najbardziej zaawansowane rozwiązanie, ale jednocześnie najbezpieczniejsze i umożliwia łatwe podbijanie biblioteki PrismJS w przyszłości. Tym razem, zamiast ręcznie, bibliotekę do podświetlania składni będziemy pobierali za pomocą wybranego przez nas package managera.

1. W folderze szablonu, instalujemy PrismJS npm i -D prismjs
2. Jeżeli używamy TypeScripta, dociągamy również typy dla PrismJS - npm i -D @types/prismjs
3. Podobnie jak we wcześniejszym sposobie, dodajemy plik CSS z definicją kolorów do naszego głównego pliku CSS szablonu Ghost assets/css/screen.css np:

@import "prismjs/themes/prism-okaidia.css"

4. Dodajemy plik JS Prism'a, do procesu tworzenia szablonu:

'node_modules/prismjs/prism.js'

5. Przebudowujemy szablon Ghosta i mamy już wsparcie dla kolorowania składni.

Tym razem, nie mogliśmy podpiąć pliku prism.js po prostu wrzucając go do assets/js/lib - chyba, że przekopiujemy zawartość prism.js z node_modules - ale nie o to tu chodzi.
Plik JS musi zostać dodany do konfiguracji task managera, którego używamy do budowania naszego szablonu. Powinna tam już istnieć definicja innych plików wejściowych .js

Przykładowo, w przypadku Gulpa, zapis będzie wyglądał mniej więcej w taki sposób:

Bonus

Jeżeli szablon naszego blogu ma różne wersje kolorystyczne, uzależnione od preferencji systemowych użytkownika, możemy w prosty sposób dodać dwa różne szablony kolorowania składni.

W tym celu, w pliku /assets/css/screen.css - do którego importujemy nasz plik CSS z PrismaJS, dodajemy taki zapis:

@import "prismjs/themes/prism-okaidia.css" (prefers-color-scheme: dark);
@import "prismjs/themes/prism.css" (prefers-color-scheme: light);

Dzięki temu, jeżeli osoba odwiedzająca naszego bloga, ma preferowane kolory systemowe ustawione na ciemne, to serwowane mu będzie kolorowanie składni w stylu prism-okaidia . Natomiast jeżeli preferowane kolory są jasne, to nasz serwis zaprezentuje syntax highlighting w domyślnych, czyli jasnych barwach - prism.css.

Podobało się?

Na tym kończymy wpis o podświetlaniu składni.

Dajcie znać czy wpis był pomocny i czy nie mieliście problemów z implementacją tej funkcjonalności u siebie.

Jeżeli chcecie dowiedzieć się więcej na temat Ghost CMS, jak z nim pracować, tworzyć / modyfikować szablony - również jesteśmy do Waszej dyspozycji.

Nie ograniczajmy się już tylko do Wordpressa, który tak często jest nadużywany, oferujmy rozwiązania odpowiednie do potrzeb. Wpłynie to korzystnie na odbiór tworzonych przez nas aplikacji.

Next.js jest aktualnie jednym z najbardziej popularnych frameworków w świecie JavaScript.

Dużo osób i projektów, przechodzi ze standardowo używanego Create React App, właśnie na Nexta. Jednym z powodów jest to, że Next.js daje nam większą kontrolę nad sposobem generowania SPA.

Zacznijmy może od definicji podstawowych sposobów generowania aplikacji frontendowej. Możemy tutaj wymienić między innymi:

• CSR (Client Side Rendering) - czyli zbudowana przez nas aplikacja, posiada w sobie dużo skryptu JS, który odczytywany jest przez interpreter przeglądarki. Można powiedzieć, że cały tekst, obrazki i inne elementy strony, opakowane są w skrypt JavaScript. Może to powodować spore obciążenie po stronie przeglądarki użytkownika
• SSR (Server Side Rendering) - w tym przypadku, treści strony pobierane są z backendu. Wchodząc na taką aplikacje, zazwyczaj musimy poczekać chwilę, aż nasza przeglądarka wyśle zapytanie o treść do serwera, odbierze ją w formie responsa, a następnie wyświetli otrzymaną zawartość. Takie rozwiązanie powoduje, że przeglądarka użytkownika jest mniej obciążona, natomiast właściciel aplikacji, musi wyposażyć się w stosowny serwer i bazę danych, gdzie będą przechowywane wszelkie treści.
• SSG (Static Site Generator) - ostatnim rozwiązaniem, jest generowanie statycznych treści. Takie podejście było standardem wiele lat temu, gdzie serwowane były zwykłe, statyczne pliki HTML i CSS. Teraz ponownie wraca do łask ze względu na swoje liczne zalety, jednak nie musimy już pisać czystych HTML ręcznie, bo mamy właśnie od tego tryb 'generatora' w nowoczesnych frameworkach. Główną zaletą tego rozwiązania, jak można się domyślić, jest minimalne obciążenie zarówno przeglądarki użytkownika, jak i serwera właściciela aplikacji. Wszystko działa błyskawicznie szybko, a to dzięki temu, że użytkownik wchodząc na naszą stronę otrzymuje nic innego, jak zwykły plik HTML. Bardzo często te rozwiązania, są od razu wyposażone w systemy cache'owania czy prerenderingu - o czym opowiemy przy innej okazji.

Teraz, gdy znamy już podstawowe sposoby generowania aplikacji (bo nie wymieniliśmy wszystkich!), możemy przejść dalej.

Poczciwy 'Create React App', standardowo buduje aplikację w formie CSR (Client Side Rendering). Jak już wspomnieliśmy, oznacza to, że wchodząc na naszą aplikacje, bardzo dużo rzeczy potrafi być przetważane bezpośrednio w naszej przeglądarce. CRA nie ma możliwości łatwego przechodzenia między trybami generowania aplikacji. Tak działa i tyle.

Między innymi dlatego, pojawiła się przestrzeń dla innych frameworków takich jak Gatsby, czy tytułowy Next.js.

Aktualnie, Next.js oferuje możliwość budowania stron zarówno w formie CSR jak i SSR i SSG a także, od niedawna w formie ISR (Incremental Static Regeneration).

W oficjalnej specyfikacji Next.js wyczytać możemy, że rekomendowanym rozwiązaniem jest właśnie SSG, ze względu na to, że generuje nam statyczne pliki które błyskawicznie potrafią zostać obsłużone przez przeglądarkę, a dodatkowo można je serwować w formie CDNa.

SSR oczywiście również jest bardzo dobrym rozwiązanem, jednak powinien być używany głównie tam, gdzie prezentowana treść może się często zmieniać na backendzie. Mówimy tutaj np o serwisach nad którymi pracuje więcej osób i operują na różnych danych liczbowych, konfiguracjach itp. Natomiast jeżeli chodzi o zwykłe blogi, gdzie raz na jakiś czas dodajemy posta, to SSG powinien być wystarczający.
Tym bardziej że.. Mamy jeszcze wspomniany ISR.

ISR jest nowym 'wynalazkiem', który polega na pewnego rodzaju połączeniu technologii SSG i SSR. Czyli, generujemy statyczne pliki, natomiast możemy ustawić czas, po którym nasza zawartość może ulec ponownej weryfikacji - czyli mówiąc wprost, dane zaktualizują się na podstawie nowej zawartości otrzymanej z serwera. Co najlepsze, nie ma tutaj jakiejś skomplikowanej konfiguracji aby wykorzystać takie podejście. Wystarczy, że przy standardowej definicji pobierania danych dla SSG (czyli przez użycie getStaticProps użyjemy dodatkowej opcji revalidate: <number> - która to definiuje, po jakim czasie nasza strona ma ulec rewalidacji. <numer> jest tutaj liczbą, wyrażaną w sekundach.

Co ciekawe, zarówno SSG jak i SSR czy nawet ISR, możn używać na przemiennie w ramach jednej aplikacji. Dlatego wybierając Next.js możemy bez problemu dobierać najlepiej pasujące rozwiązania generowania treści dla każdej strony, a nawet każdego komponentu. W zależności od tego, czy jest to treść statyczna, aktualizowana sporadycznie, czy też treść która będzie ulegała częstym zmianą w bazie danych.

Na koniec dodatkowa uwaga:
Pamiętajcie, że przy użyciu Static Site Generatora, wszelkie requesty są pobierane w trakcie budowania aplikacji! Z tego powodu, czas budowania może być odrobinę dłuższy, ale za to wygenerowane pliki HTML mają już treść otrzymaną z serwera. Jeżeli dojdzie do jakichś zmian na serwerze, to nie zostaną one wyświetlone odwiedzającym nas użytkownikom, do momentu, aż nie przebudujemy naszej aplikacji.

Minęły już prawie 3 lata od kiedy React Hooksy po raz pierwszy zagościły w wersji React 16.8. Jedni pokochali je od razu, drudzy potrzebowali trochę czasu na oswojenie. W tym materiale przedstawię wam oraz spróbuje wytłumaczyć działanie najczęściej używanych hooksów z jakimi będziecie mieli do czynienia w projektach reactowych. Na początek zajmijmy się funkcją, która niezrozumiana może narobić trochę kłopotów początkującym programistom.

Pamiętaj proszę, że wszystkie przykłady które Ci zademonstruje w tym poście nie są przykładami produkcyjnymi. Zostały one maksymalnie uproszczone tak abyś skupił się na tym co ważne a nie zastanawiał się co robi akurat ten if i dlaczego został on tak napisany.

useEffect

O UseEffect'ie mówi się jak o zamienniku "starego" klasowego componentDidMount. Poniekąd jest to prawda chociaż nie tylko na tym kończy się jego rola.

useEffect( () => {

// do something

})

Hooka efektów używa się głównie do wykonania jakiejś czynności, jakiegoś side-effectu, po tym jak komponent się już zbuduje i "narysuje". Po wyrenderowaniu DOM'a zostanie wywołany nasz useEffect a ściśle rzecz biorąc funkcja którą do niego przekazaliśmy.

Dependency array

A co kiedy nie chcemy aby za każdym przeładowaniem naszego komponentu dany efekt się wywoływał? W tym przypadku dostaliśmy do dyspozycji tablice zależności - dependency array.

Żeby łatwiej zwizualizować sobie jak tak naprawdę zbudowany jest useEffect uprośćmy go sobie maksymalnie.

useEffect(funkcja, tablica zależności)

UseEffect jest przede wszystkim funkcją, której pierwszym argumentem jest kolejna funkcja, która wywoła nam jakiś efekt. Drugim argumentem jest tablica zależności, od których będzie zależało to czy nasza funkcja się wywoła czy nie.

W przypadku pierwszego argumentu tutaj nie mamy co dyskutować, należy zawsze podać, inaczej nie miałoby to żadnego sensu prawda? Natomiast w przypadku tablicy zależności, no tutaj sprawa ma się trochę inaczej. Szybkie spojrzenie na implementacje w pliku źródłowym daje nam cenną informację :

function useEffect(effect: EffectCallback, deps?: DependencyList): void;

Drugi argument przekazywany do hooka efektu jest opcjonalny, co oznacza że możemy go przesłać albo nie. Ale co to TAK NAPRAWDĘ oznacza? Co jeżeli go nie podam?

Deklarować dependency array czy nie?

Przede wszystkim nie powinieneś nie podawać tablicy zależności. Takie podejście jest przez wielu uważane za błędne i doprowadzające do zachowań, które nierzadko ciężko nam przewidzieć. Dlaczego? Otóż niepodanie tej tablicy będzie skutkowało tym, że za każdym przeładowaniem naszego komponentu wywoła się nasz efekt.

No ale co z tego? Mam małą funkcyjke, która sobie coś tam sprawdza i tyle, niech wykonuje się za każdym razem, nie bardzo mnie to boli. Warto zastanowić się czy tak naprawdę jest.

Wyobraź sobie, że mamy komponent Radio, który ma wszystkie cechy radia. Możemy słuchać muzyki, podgłaśniać i ściszać dźwięk, zmieniać stacje, ustawiać basy i robić wszystko to co możesz robić w swoim własnym radiu. W poniższym przykładzie chcemy zwiększyć głośność w momencie kiedy akurat leci nasza ulubiona piosenka - Parostatek na 80%. W innym wypadku niech głośność będzie ustawiona na 40%.

useEffect( () => {

 if(song === 'Parostatek') {
   setVolume(80) // 80 percent
  } else {
   setVolume(40) // 40 percent
  }
  
}, [song])

Powyższa funkcja nasłuchuje, przy każdym przerenderowaniu komponentu, czy wartość song się zmieniła porównując ją do poprzednio zapamiętanej wartości. Jeżeli wartość po przerenderowaniu jest inna niż ta którą pamięta, wywoła nam się nasz efekt.

Patrząc na powyższy przykład możesz zapytać dlaczego nie pozwolimy aby ten efekt wywoływał się za każdym razem? Przecież piosenki w radio zmieniają się raptem co pare minut, a ta funkcja nie robi nic wielkiego więc dlaczego nie wywalić tablicy zależności i pozwolić jej wywoływać się za każdym razem przy przeładowaniu komponentu?

Dobrze, a co jeżeli "wywołamy" inną funkcje związaną z używaniem radia? Czy chcemy aby nasza funkcja wywoływała się gdy ściszymy radio? Albo gdy zwiększymy basy? Nie. Dlatego jasno daliśmy Reactowi do zrozumienia, że chcemy aby nasza funkcja została odpalona tylko w momencie kiedy zmieni się wartość przechowywana w zmiennej song.

"Nowy" componentDidMount

Jak wspominałem wyżej, useEffect jest często nazywany funkcyjnym zamiennikiem jednego ze stanu cyklu życia komponentu klasowego jakim jest componentDidMount. Okej, potrzebujemy wywołać coś raz i tylko raz w momencie pierwszej inicjalizacji komponentu. Jak to napisać wykorzystując useEffect ?

useEffect( () => {

// do something only once when component is
// created for the first time

}, [] )

Odpowiedź brzmi: poprzez podanie pustej tablicy zależności. Powyższa funkcja wywoła nam się tylko i wyłącznie w momencie pierwszej inicjalizacji naszego komponentu i będzie ignorować wszelkie dalsze przeładowania.

Posprzątaj po sobie

Podczas cyklu życia naszej funkcji wielokrotnie ja przeładowujemy, zmieniamy wartości, wyświetlamy różne dane. W skrócie, robimy dużo "bałaganu". Jedną z rzeczy która potrafi narobić bałaganu jest subskrypcja. Po tym gdy nasz komponent "wyrazi chęć" na otrzymywanie w ramach subskrybcji nowych informacji, to w momencie kiedy nie będzie nam już potrzebny i będziemy chcieli go usunąć, należało by po sobie posprzątać i nacisnąć guzik "unsubscribe". W innym wypadku może dojść do bardzo niepożądanego wycieku pamięci.

Szybkie wprowadzenia co to jest subskrypcja w programowaniu. Upraszczając, pojęcie subskrypcji oznacza chęć na otrzymywanie powiadomień (nowych wartości) gdy coś co nas interesuje (czyli to do czego się subskrybujemy) się zmieni. Przykład z życia wzięty - macie swojego ulubionego youtubera który wypuszcza filmiki, subskrybujecie go aby dostawać powiadomienia za każdym razem gdy na jego kanale pojawi się nowy filmik. Tak to mniej więcej działa i tu.

useEffect( () => {

  ChartApi.subscribe()

},[])

Na przykładzie widzimy jak podczas pierwszego zbudowania się naszego komponentu subskrybujemy się do ChartAPI, która przypuśćmy podsyła nam co chwilę nowe wartości do wyświetlenia na naszym wykresie. W ten sposób nasz wykres "żyje", dostaje nowe świeże dane które użytkownik widzi na bieżąco. Fajna sprawa, ale wymaga od nas przygotowania się na sytuację w której nasz komponent, który się subskrybuje do ChartAPI, przestanie nam być potrzebny. Czyli co? Czyli trzeba po sobie posprzątać.

useEffect( () => {

  ChartApi.subscribe()
  
    // cleaning function
  return () => {
	ChartAPI.unsubscribe()
  }

},[])

Aby zrobić to prawidłowo należy wywołać funkcję return podając jej co ma stać się w momencie gdy nasz komponent zostanie 'odmontowany' (unmounted). W ten sposób zabezpieczamy się przed nierzadko tragicznym w skutkach wycieku pamięci, ponieważ mimo że komponent już nie istnieje w dalszym ciągu nasz subskrybent próbuje wysyłać mu nowe informacje.