Hejto.pl
Dodaj post

Wpisz coś do wyszukania (minimum 2 znaki)

#w3c

Inspirator

w Hydepark

1piorunów

Teraz chciałbym abyś się leciutko skupił.
Powiedz mi, czy rozumiesz taką koncepcję.

Ja nadal jestem za koncepcją: jedno okno, wiele kart przeglądarki internetowej.
Jako opcjonalne API do wykorzystania.
Że w ramach jednej domeny(?), zamiast tworzyć kolejnych okien w kolejnych kartach (na zasadzie jedno okno, jedna karta), otwierać tylko "wydmuszkę", pusty element GUI w przeglądarce, którego kliknięcie wywołuje callback w jednym jedynym oknie.
To by działało jak History API, tylko dla kart, że przełączanie między kartami tylko uruchamia callback, zamiast przeładowywać okna do viewport.
Analogia do History API: Z History API, nie ładuje się poprzedniego okna po kliknięciu wstecz, tylko odpala callback który przeładowuje samą treść, w tym samym oknie.

Z koncepcją Jedno Okno, Wiele Kart Przeglądarki Internetowej:
* Można tworzyć efekty przejścia, animacje, podczas przełączania się między kartami tej samej domeny - nawet View Transitions API tego nie potrafi sam z siebie.
* Masz mniej okien otwartych na raz, bo podmienia się tylko kontent w jednym jedynym oknie, a nie całe okno. Zajmuje mniej miejsca.
* Nie potrzeba specjalnej komunikacji między oknami (tej samej domeny), bo komunikacja i synchronizacja jest bezpośrednia i doskonała.
* Idealne pod Single Page Aplication - przełączanie kartami przeglądarki przełącza tylko stan aplikacji, zamiast przełączać między wieloma kopiami aplikacji
* Nowa karta szybciej się otworzy i załaduje, bo doładowuje się tylko niewielki kawałek treści, a nie cała strona.

Fenomen0piorunów

@fewtoast nic z tego nie rozumiem niestety.

Inspirator0piorunów

@Legitymacja-Szkolna A po tym będzie zrozumiale? Bo wiadomo, im więcej osób zrozumie, tym będzie łatwiej mi to gdzieś przepchnąć.

Jak znasz History API, używane np. w routingu, to chyba ułatwia.
Normalnie masz jeden `window` na jedną kartę przeglądarki Internetowej.
Ładuje się kolejny `window` przy każdej nowej karcie.
Tutaj byś miał że np. otwierasz dwie karty z hejto, to tak naprawdę ta druga karta nie tworzy drugiego window, tylko jest taką kartą wydmuszką, i tylko jak się kliknie na kartę (na element GUI przegladarki internetowej), to w tym pierwszym window wykona się callback, który przeładowuje tylko samą treść, np. sam wpis, a nie całą appkę hejto.
W viewport przeglądarki internetowej jest nadal ten pierwszy window, a tylko wykonuje się callback.
Czy klikniesz pierwszą kartę hejto, czy drugą, to nadal masz ten sam window w viewport. Jedyne co się zmienia, to url w pasku adresu przeglądarki, selekcja karty, i odpala się callback.

Pokaż więcej komentarzy (4)

Inspirator

w Hydepark

0piorunów

Powinno się pomyśleć nad rodzajem cookies/storage, które z założenia mogą być synchronizowane między urządzeniami, za pomocą Firefox Sync, konta Google do synchronizacji Chrome.

Bo wiadomo, że nie wszystkie dane z cookies/storage itd. warto synchronizować, ale niektóre by można, np. podstawowe preferencje, zalogowanie.

Tak jak w WebExtensions jest browser.storage.sync:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/sync

Zaleta, że robisz appke webową, i możesz olać kwestię synchronizacji pewnych danych, i masz to z automatu.

Taki odpowiednik tych usług z Google Play.

Tylko bardziej zdecentralizowane, bo oparte o przeglądarkę.

Może w ramach Project Fugu?