Czy jest to zgodne ze sztuką? - PHP, Ajax

pytanie zadane 2 stycznia w JavaScript przez szpon12 Obywatel (1,220 p.)

Cześć piszę aplikację webową przy użyciu PHP, Javascript - nasuwa mnie się pytanie, otóż wiem że jest to wykonalne i działa, ale czy zgodne ze sztuką jest przesyłanie AJAXem wygenerowanego przez backend HTMLa i wyświetlanie go użytkownikowi? Zwykle przesyłałem dane w JSONie i sklejałem je po stronie klienta, lecz chciałbym wiedzieć czy poprostu metoda wysyłania wyrenderowanych widoków jest "etyczna".

Pozdrawiam.

komentarz 2 stycznia przez VBService Ekspert (253,400 p.)

W grze online anocris.com, kod do okien informacyjnych jest przesyłany przez fetch w postać html-a widać to w DEVTools na request-ach . Sama gra jest "rysowana" w <canvas> albo <img> z <map>, duża część kodu html (nawet po kilka KB na 1 request) jest fetch-owana (jak już pisałem powyżej ) i śmiga to przyzwoicie.

2 odpowiedzi

odpowiedź 2 stycznia przez Wiciorny Ekspert (270,190 p.)

Nie wiem co napiszą koledzy, ale generowanie HTMLA z backendu, w ogóle nie będzie dobra praktyką, pomijam fakt jak ogromny PAYLOAD danych to musi być na request, już abstrahując od tego, czy jest to robione AJAXem, czy inną technologią np. intefejsu fetch, API czy jakiś XMLHttpRequest

Dlaczego cały HTML leci do sklejenia w requeście? Dlaczego trzymasz HTML na backendzie, w ogole jak w takim razie to aktualizujesz?

Widok renderuje się na frontendzie, może być związany z bazą ale sama warstwa Klienta, odpowiada za kontent

komentarz 2 stycznia przez szpon12 Obywatel (1,220 p.)

Troche nieprezycyjnie się wyraziłem, szablony widoków generuję na zasadzie podobnej do BLADE'a używanego w Laravelu.

A o sklejaniu po stronie klienta miałem na myśli generowanie dodatkowego kontentu za pomocą funkcji Javascriptu. Tj. klient odbiera JSONa z danymi i na podstawie tych danych generowany jest odpowiedni szablon widoku. tj. okno modalne czy inne powiadomienie.

Proszę wybaczyć nieprezycyjne słownictwo lecz nie mam z kim dyskutować na temat takich spraw, także pojęcia którymi się posługuje nie oddają często tego co mam na myśli.

komentarz 2 stycznia przez Comandeer Guru (601,590 p.)

@Wiciorny,

Widok renderuje się na frontendzie, może być związany z bazą ale sama warstwa Klienta, odpowiada za kontent

No nie, pełny rendering po stronie klienta od wieków jest uznawany za mniej wydajny. Dlatego praktycznie każdy framework JS-owy w ostatnich 2-3 latach wynalazł SSR na nowo. Stąd zresztą mamy rozwiązania fullstackowe pokroju Next.js.

komentarz 2 stycznia przez Wiciorny Ekspert (270,190 p.)
edycja 2 stycznia przez Wiciorny

ja to zrozumiałem w inny sposób, że "kontent dynamiczny" jest renderowany z bazy i o to mi chodziło, a nie np model SSG, gdzie mamy częsci statyczne, lub backend renderuje dane na stronie w zależności od odp. ja to zrozumiałem jako przechowywanie czystego HTML w bazie i ładowanie tego na zasadzie requestu.
Co wydawało mi się absurdalne.

Rozumiem, że SSR sposób się zmienił? Gdyż przecież CSR znacznie później przyszedł niż model SSR, bo ten jest najstarszy i pierwszy.

komentarz 2 stycznia przez Comandeer Guru (601,590 p.)

To trzymanie gotowego HTML-a w bazie faktycznie jest kiepskie. Ale już przesyłanie HTML-a w odpowiedzi np. na Ajaksowe zapytanie jest obecnie normalną praktyką.

Rozumiem, że SSR sposób się zmienił? Gdyż przecież CSR znacznie później przyszedł niż model SSR, bo ten jest najstarszy i pierwszy.

Tak, ale wraz z nadejściem Angular.js i pierwszych wersji Reacta nagle o nim zapomniano i dopiero trzeba było kilku lat, żeby na nowo się pojawił.

komentarz 2 stycznia przez Wiciorny Ekspert (270,190 p.)

Okej dzieki, jednak dalej w praktyce zauważam, że wiele stron i projektów dalej leci na technologiach Angulara/Reacta0( chociaż ten drugi SSR może implementować dosyć czytelnie) i korzysta z rozwiązań CSR, nie zauważam popularności np. Next.js żeby od razu mówic o SSR