Wpis z mikrobloga

@moon_bluebird: nie ma problemu, chciałem tylko zwrócić uwagę na odmienne od (głównie) Reacta podejście do sprawy + prawdopodobnie najlepsze dla dużych aplikacji tego typu.
  • Odpowiedz
@5z7k9: Wadą takiego podejścia jest tylko konieczność utrzymywania osobnej porcji kodu per docelowy klient API (przy założeniu, że klientami są nie tylko aplikacje webowe)
  • Odpowiedz
  • 0
@Marmite: rozumiem, choć zakładając, że tworzymy aplikację typu Twitter, to jest jeden klient + osobne API JSONowe dla innych aplikacji.
Jeszcze jakieś wady/zalety? Chętnie usłyszę. :)
  • Odpowiedz
@5z7k9: plusem reacta jest dobra implementacja virtual dom. Przy większości zastosowaniach nie widać takiej różnicy, ale prawdziwego kopa widać na przykład w sytuacji gdy masz dużo danych aktualizowanych websocketami
  • Odpowiedz
w XHR2 można ustawić responseType na 'document' i pobierać Document object prosto z serwera, i nie trzeba wtedy ręcznie parsować HTML.
  • Odpowiedz
@Marmite: nie dostrzegam tu wady, może to spaczenie korporacyjne ale mam z tym do czynienia na codzień. Webaplikacje muszą serwować zupełnie inne szablony w zależności od urządzenia, na tle różne w wyglądzie i zachowaniu, że przez frameworki mobile first jest to nie do ogarnięcia.
  • Odpowiedz
@5z7k9: Wcale nie jest jakieś egzotyczne podejście. Nie ma w tym nic nowego.
Przy okazji react-a ... można oczywiście użyć kodu renderującego html-a po stronie klienta i serwera również w tym scenariuszu.
  • Odpowiedz
@5z7k9: No normalnie... Skrypt w PHP ci zwraca HTML, a przeglądarka mieli to automatycznie bez żadnego ręcznego parsowania w document object. Wydaje mi się to szybsze tak samo, jak za pomocą responseType można pobierać JSON bez parsowania.
  • Odpowiedz