Pytanie Najlepsza praktyka: ładowanie renderowanego html lub json?


Cześć, mam pytanie, które wydaje się głupie, ale nie mogę powiedzieć dlaczego.

Tło:

Wyobraź sobie internetową aplikację z użytkownikami i tagami. Użytkownicy oznaczają się nawzajem.

Mam jedną stronę w aplikacji, która wyświetla szczegóły dotyczące pojedynczego tagu w odniesieniu do pojedynczego użytkownika. Powiedzmy, że użytkownik "pion"i tag"footag". Na tej stronie wyświetlam dwie listy: wszystkie osoby oznaczone tagiem "footag" i wszystkie osoby oznaczone jako "footag". nazwijmy to <div id="received'> i <div id="sent"> 

Powiedzmy, że URL tego widoku jest /users/bob/tags/footag

Oczywiście, te listy są długie - nie chcę ładować całej listy po odsłonięciu strony. Więc ładuję pierwszą dziesiątkę za każdą.

Pytanie

Teraz mogę zapewnić dynamiczne stronicowanie dla każdej z list na jeden z dwóch sposobów:

  1. Pobierz dane dla kolejnych 10 użytkowników jako json. Napisz js, aby wyrenderować te dane, zastępując zawartość pliku div.
  2. Zdobywaj "renderowany" fragment html z innego dobrze zdefiniowanego adresu URL na moim serwerze /users/bob/tags/footag/received?page=1. Pobieram to asynchronicznie i po prostu zastępuję zawartość odpowiedniego <div>.

Tak więc w jednym przypadku pobieram dane i renderuję je za pomocą JS w przeglądarce, drugi pobieram renderowane dane i po prostu umieszczam je hurtowo w dokumencie.

Czy jest jakikolwiek powód, aby nie używać # 2? Nie mogę sobie tego wyobrazić, ale przypuszczam, że mogą istnieć aspekty bezpieczeństwa, których nie rozważam, czy wydajność, czy coś innego. Wolałbym robić # 2, ponieważ znacznie upraszcza moje życie.

Dzięki!


15
2017-07-17 20:29


pochodzenie


O ile "długie" nie oznacza więcej niż 1000 wpisów, głosuję za załadowaniem całej listy. Paginacja jest do dupy. - Instance Hunter
@InstanceHunter Zgadzam się, ale możesz załadować więcej treści, gdy użytkownik przewinie dalej. Tak jak na przykład Facebook. - Jonas Stensved


Odpowiedzi:


Mam taką aplikację - używam obu metod.

Używam Twojej metody nr 1 do aktualizowania pól, które nie sąsiadują ze sobą (np. Pola wprowadzania w całym miejscu), ale używam Twojej Metody nr 2 do aktualizacji danych tabelarycznych, takich jak twoje listy.

Trzymałbym się # 2 dla twojej sprawy.


4
2017-07-17 20:58





pójdę z numerem 1, więc naprawdę otrzymasz dane, a nie tylko HTML ... to po prostu zwięzła struktura obiektów JavaScript, a nie jakiś ciąg znaków, więc możesz dowolnie oceniać dane, buforować je, używaj go do wyszukiwania itp. ... im więcej pracy wykonujesz po stronie klienta, a im jest to mądrzejsze, tym lepiej Twoja aplikacja skaluje się ... masz 1 serwer, a może 2-10, lub nie. wiesz, ale masz 10-10000 więcej klientów ...

greetz

back2dos


2
2017-07-17 20:52





Osobiście użyłbym metody nr 2. Po co marnować czas na analizę po stronie klienta, która mogłaby być łatwiejsza i lepsza, za pomocą języka po stronie serwera? Zamiast tworzyć tablicę, a następnie konwertować ją do json, lepiej byłoby po prostu przejrzeć wyniki i wygenerować kod HTML.


1
2017-07-17 20:33



To bardzo mylące. Kiedy wysyłasz HTML w odpowiedzi na żądanie AJAX, przeglądarka / musi / musi ponownie przeanalizować (i ponownie renderować). - Matthew Flaschen
Nie sądzę, że Salty miał na myśli przeglądarkę, a raczej kod javascript, który musiałbyś napisać, który uruchamia stronę klienta, aby przekonwertować ("parsować") JSON z powrotem na HTML lub wstrzyknąć go w razie potrzeby. - RedFilter
OrbMan jest poprawny. :) - Salty


Porównałbym go w kilku przeglądarkach, ale podejrzewam, że numer 1 (przekazywany jako JSON) może okazać się szybszy. Za pomocą tej metody można po prostu zastąpić wartości dla istniejących węzłów DOM. Na przykład. (bardzo uproszczona) zmiana (bezpośrednio przy użyciu manipulacji DOM):

<li>foo</li>
<li>bar</li>
<li>baz</li>

do:

<li>foo2</li>
<li>bar2</li>
<li>baz2</li>

kiedy otrzymasz JSON:

["foo2", "bar2", "baz2"]

W ten sposób niepotrzebnie nie tworzysz nowych węzłów DOM. Kolejną zaletą jest to, że interfejs JSON API jest bardziej "apetyczny", jeśli później zdecydujesz się go upublicznić w jakiejś formie.


1
2017-07-17 20:45



Wydaje mi się, że trzaskanie w jednym kawałku HTML jest znacznie szybsze niż iteracyjne dodawanie kodu HTML przy użyciu javascriptowego parsowania JSON. Również kompresja gzip (która jest dobrym pomysłem, aby włączyć, jeśli obawiasz się o wydajność) prawdopodobnie zmniejszy dane na tyle, że różnice w wydajności między HTML i JSON są minimalne. - RedFilter
OrbMan, nie mówię o dodawaniu HTML (z innerHTML lub czymś), ale raczej zastępowaniu tekstu wewnątrz / istniejących / węzłów HTML. gzip ma znaczenie tylko dla przepustowości. Nie ma nic wspólnego z kosztem tworzenia nowych węzłów HTML. - Matthew Flaschen


cóż, poza nieznacznym obciążeniem formatowania ładowanego z serwera, które może sprawić, że będzie trochę wolniej dla dużej ilości danych, nie widzę żadnych wad. A ponieważ renderowanie w języku javascript byłoby prawdopodobnie zbyt wolne, poleciłbym # 2.


0
2017-07-17 20:34





Mówię # 1 dla większości przypadków. Jeśli chcesz dodać przycisk strony "next / prev" poza aktualizowanym div, możesz użyć JS, aby określić, kiedy je włączyć / wyłączyć. Używanie # 1 daje ci większą elastyczność i dodatkowo oddziela dane od prezentacji.

Wydajność i "łatwość rozwoju" jest moim zdaniem znikoma. Wydajność nie jest już zbyt duża dla mniejszych "kawałków" danych (zakładając, że twój JS w sferze zdrowia psychicznego) i "łatwości rozwoju" nie ma większego znaczenia, biorąc pod uwagę, że jest to łatwiejsze do utrzymania.


0
2017-07-17 21:09