8 komentářů k článku Firebase: krátké seznámení:

  1. steida

    API
    Firebase je super, používám skoro rok. Ale pár věcí mi pije krev. Třeba budeš vědět.

    1) Nemožnost rozlišit client a server update. Rozumím, že je to by design, ale stejně. Měl jsem aplikaci, ve které se ukládal a propagoval app state do localStorage. Tohle zajišťuje sync mezi taby. Rozedituješ jeden formulář, a v druhém okně máš ten samý stav. Nakonec jsem musel použít škaredý hack. Dokonce jsem to řešil s vývojáři, stačil by malý bool fromServer, ale bohužel mají jiné priority.

    2) on/off. Pokud chci něco začít poslouchat a později to zase vypnout, chtělo by to nějakou toggle metodu, nakonec jsem si taky musel napsat.

    1. Ondřej ŽáraAutor příspěvku

      Re: API
      1) Rozumím. Taky vidím v odlišení vzdálených a lokálních změn trochu problém, ale na druhou stranu se dá symetricky prohlásit, že si to dovede rozlišit i ta komponenta sama.

      Tedy pokud mám řekněme formulářové pole, tak při jeho změně uživatelem se provede propagace změny do Firebase, zatímco při změně zvenčí (tj. v důsledku události „value“) se jen aktualizuje UI a nevznikne tak nekonečný cyklus „set -> firebase change -> ui change -> set -> …“.

      Pokud není vhodné UI updatovat ve chvíli, kdy by se jednalo o NOOP, pak bude nutné přidat detekci tohoto stavu (remote data se shodují s lokálními) a update ignorovat.

      Mimochode, v tomhle popsaném případě jsem úplně nepochopil tu localStorage. Proč synchronizovat stav aplikace mezi záložkami pomocí localStorage, když se pro to (zároveň) může použít Firebase? Nejsou to dvě (kolidující) technologie pro tu samou úlohu?

      Co tak koukám, tak mi Firebase obecně přijde méně vhodná tam, kde mnoho klientů šahá na ta samá data. Její síla leží spíš v inkrementálních updatech, kdy každý klient vloží nový záznam. Drží si tak posluchače v rodiči na „child_added“, sám volá push() a dovede tento lokální update detekovat tím, že nově přidané dítě odpovídá výsledku volání push. Koneckonců to odpovídá i těm neměnným datovým strukturám, které poslední dobou tolik frčí :-)

      2) Ano, řešení „rozděl a panuj“ popsané v druhém komentáři mi přijde jako správná cesta. U on/off se mi zdá trochu nepohodlné, že si musím ten callback někde držet, abych ho mohl následně odebrat (off lze volat také bez parametru a zruší to všechny posluchače, ale to nemusí vždy vyhovovat). Upřednostil bych spíš něco typu interface EventListener, kde bych předal this a měl tak navíc zadarmo (i v ES5) bind.

      1. steida

        Re: API
        Ad „Proč synchronizovat stav aplikace mezi záložkami pomocí localStorage, když se pro to (zároveň) může použít Firebase?“

        Jsou a kolidují, ale důvod přesto existuje – Pokud automaticky okamžitě promítáš stav appky do localStorage, nikdy nejpřijdeš o rozeditovaná data, ani při náhodném zavření prohlížeče nebo výpadku elektriky nebo chybě. Zároveň je velmi praktické, aby všechny taby jedné aplikace sdíleli ta samá data, protože to předchází problém typu omylem jsem v jednom tabu něco smazal a v druhém to dal editovat. Firebase zůstala na půli cesty, funguje pouze pokud je dostupné spojení a nepoužívá localStorage tak, jak jsem popsal. Propojit tyhle dvě technologie bez smyčky je možné, ale pár dnů mi to zabralo. Model appky prostě dle mého patří do localStorage nebo jiného úložiště, pak můžeš pracovat s appkou i offline. Tohle Firebase nepodporuje a je to škoda. Jak si říkal, porovnávat data, to moc nelze v případě lokálně dočasně nastaveného server time, tam ti Firebase prostě dá číslo, a ty nikdy nevíš, jaké. Existuje jediný možný a velmi škaredý hack, a to je pomocí setTimeout. Psal jsem si kvůli tomu s vývojaři, ale mají bohužel zcela jiné priority.

    2. VirtualSkiper

      Re: API
      Jasne ze je technicky mozne privazat input policko primo do FireBase, ale proc bys to sakra delal? Krome online editace stejneho dokumentu to snad ani nedava smysl. Proste si z modelu nactes vetu do objektu formulare, delas na nem vstupni kejkle, validujes vstupy a kdyz mas cely objekt v kupe posles ho do FireBase (zaznam na serveru zamknes jednoduchym bullem). Vyhnes se tak problemum, ktere popisujes, nakrasne si muzes data ulozit na lokale a kdyz se bude aplikaci darit jednoduse jednou vymenis FireBase za jinou databazi. FireBase neni jedina cesta k three-way-data/bindingu. Porad mas k dispozici Meteor, a/nebo Pouch/Couch dvojce. Osobne na Firebasi pisu jenom prototyp a jakmile se trochu utrese struktura modelu, prepisuju servisy na Mongo/CouchDB (podle zadani). Abych pak nemusel prepsat celou apku tak stejne i v pripade FireBase pisu jednoduchou factory.

      Firebase je super pro mobilni aplikace, Zrovna pisu takovej proof of concept ktery z FireBase cte nejen data ale i kod. a sablony. Jako prvni se nacte popis aplikace, UI-router objekt (Angular), a OAuth. Diky zatracovanym angular modulu jsou vsechny controlery a servisy vlastne jenom objekty, kterym se extenduje master module, takze na mobilu bezi vpodstate jenom runtime, ktery si vsechno ostatni dotahne. Kdyz to vezmes ad absurdum, tak ti na mobilu bezi apka, ktera se meni s tim, jakej kod ti parta pankacu live uklada do Firebase ;))

  2. steida

    Firebase A React component lifecycle model
    Ad 2) Tak teď mne napadla děsivá myšlenka – asi jsem to dělal blbě. Takhle, podle routy jsem různě konfiguroval nahrávání různých dat z Firebase, a ručně jsem je zase přestával poslouchat. Jenže, když se podívám na Facebook Relay, tohle je věc user interface, které se v čase dost mění, a udržovat bokem co se má kdy nahrávat je dost komplikované. Pokud ale u každé React komponenty deklarativně označím, co se má na componentDidMount na Firebase registrovat, a co na componentWillUnmount deregistrovat, pak za mne React elegantně řeší celou správu on/off, takže z tohoto pohledu je Firebase api asi naprosto v pořádku. Člověk se furt učí.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=14554