Jak obecnie w nowych projektach powinno się traktować część frontendową? Wracam po jakimś czasie do railsów (z typowo frontendowej roboty - nie railsowej) i trochę się pozmieniało jeśli chodzi o to frontend (SPA itp). Zastanawiam się jakie są opcje w rails i jakie są plusy/minusy każdej z nich. Guides nadal piszą o UJS, dołączaniu response ręcznie itp.
Pomysły jakie widzę na teraz to:
Osobny projekt oparty na jakimś MV* typu Angular czy Ember, który jest pakowany do /public i rails serwujący JSONa?
Wszystko w /app/assets, serwowanie partiali AJAXem i podmienianie z palca?
Wszystko w /app/assets ale podparte jakimś Angularem czy innym Emberem itp
Jak to jest z rzeczami typu pomocniki do formularzy np. remote: true itp? Używacie tego? Nie lepiej jest takie rzeczy zakodować ręcznie w jakimś ustrukturyzowanym JS?
Zastanawiam się jak to się teraz robi w nowych projektach. Będę wdzięczny za wszelkie informacje, ewentualne linki do dobrych rzeczy na ten temat (ale nie jak zrobić TODO list w combo rails+angular).
Mam do zrobienia projekt od zera i nie wiem w którą stronę iść, czy np robić typową SPA, czy pozwolić railsom serwować layouty dla poszczególnych sekcji appki (np. admin, entries, groups) a żeby każda taka sekcja była osobną mini-SPA…
Jeżeli projekt jest hobbystyczny, to naucz się czegoś nowego i spróbuj pojechać z Emberem albo Angularem (oraz: ich pliki jak najbardziej do assets/, nie ruszaj public/ w ogóle).
Jeśli projekt jest komercyjny to rób to co umiesz. Czyli html renderowany i serwowany przez aplikację.
Wszystko zależy od tego jak bardzo skomplikowaną aplikację chcesz mieć. Czy na pewno potrzebujesz SPA? Może wystarczy “grubszy” JS w kilku kluczowych miejscach w aplikacji, a reszta po staremu? Bo mam wrażenie, że możesz mylić pojęcia. Dodanie dynamiki na stronie nie powoduje, że staje się ona SPA!
Wg mnie najgorszym możliwym podejściem jest serwowanie całych partiali AJAXem - wprowadza to zawsze bałagan.
remote: true to wygodny skrót, gdy na stronie mało co się dzieje można się pokusić o użycie. W przypadku skomplikowanych aplikacji wprowadzi niepotrzebny bałagan.
Przy tworzeniu 100% SPA można się pokusić o robienie frontentdu całkowicie niezależnie od Railsów - w końcu frontend to tylko 1 albo kilka plików HTML + templaty HTML + JS. Nie stosowałem jeszcze takiego podejścia, ale wydaje się być całkiem sensowne.
Pamiętaj też, że robienie SPA ma swoje konsekwencje - np. indeksowanie strony do Google’a jest dużo trudniejsze.
Ale najważniejsze: w przypadku SPA naprawdę trzeba wiedzieć co się robi i znać bardzo dobrze JS.
Podejście klasyczne - serwowanie HTML + dodawanie JS (nawet ciężkiego i skomplikowanego) na pewno powoduje mniejsze komplikacje i jest bezpieczniejsze w przypadku małego doświadczenia.
Ja od siebie dodam tylko tyle, że wszystko zależy od aplikacji. Jeśli aplikacja, ma być przeznaczona na komputery, tablety, komórki, to po zastosowaniu rozwiązania client side, trzeba się trochę natrudzić, żeby prawidłowo wszystko działało na każdym tablecie, telefonie (dużo zależy do systemy operacyjnego jak i jego wersji).
Dzięki za info. Czyli tak jak sądziłem - albo SPA, albo JS z palca, a rzucanie HTML’em w JSON jest passe dzieki bogu
To czy “potrzebuję” SPA to jak zwykle jest dyskusyjne, wydaje mi się że niekoniecznie, chociaż nie boję się tego - siedzę w tym od jakiegoś czasu (na części typowo frontowej).
Co do dodawania JSa ręcznie, jak rozwiązujecie problem kodu dla konkretnej “sekcji” strony? Tzn. kod dla /admin osobno, kod dla /groups osobno itp. Pakujecie to wszystko w jeden application.js sciągany na starcie i cacheowany czy jakoś inaczej? No i jak z odpalaniem odpowiedniego fragmentu kodu dla odpowiedniej sekcji? Widziałem gdzieś patenty typu<body data-controller='CONTROLLER_NAME'>...</body> i podpinanie kodu przez sprawdzanie czy CONTROLLER_NAME jest odpowiedni.
Podejście z data-controller w body + mini routerek w JS jest całkiem sensowne,
Ewentualnie w kodzie strony dodawać mały snippet JS typu: <script>new GroupsView();</script>. W zasadzie oba podejścia są równoważne, z tym że drugie jest bardziej explicite.
Jeżeli zakładasz, że użytkownik będzie się poruszał po wszystkich stronach typu /admin, /groups itd. to wrzuć do jednego application.js. Ale jeśli są moduły aplikacji, gdzie użytkownik na pewno nie wejdzie (np. /admin) to najlepiej wydzielić dodatkowe pliki - po co zwykłemu użytkownikowi assety do panelu admina.
Jeżeli aplikacja jest bardzo modularna to nic nie stoi na przeszkodzie, żeby wydzielić sobie np common.js i kilka plików JS do poszczególnych modułów. Nie trzeba wszystkiego ładować w jeden plik.
Tak, ale zakładam że nie robię SPA z Emberem czy Angularem. Tam wiem jak to się robi - nie ma problemu. Chodzi mi o sytuację gdzie JS jest częścią railsowej aplikacji, a nie osobnym klockiem który tylko puka do serwera po dane. Czyli gdzie masz application.js z wszytkim, ale chcesz część kodu mieć podpiętą kiedy jesteś w sekcji /admin a część jeśli np w sekcji /profile itp.
Ostatnio u nas Krzysiek i Artur pożenili Embera z jQuery-Mobile i działa jak złoto. Gdyby nie mieli dedlajnu na karku to bym ich nakłonił do napisania blognotki i prezentacji na WRUGu, ale może w grudniu się uda
Przecież napisałem że to zależy od aplikacji i co w aplikacji się używa. Znaczna większość scenariuszy działa prawidłowo. Jednak w niektórych przypadkach wykonywania share (popup) do serwisów społecznościowych, czy odtwarzania video/audio iOS i Android działają z grubsza w odmienny sposób.
