Aplikacja Render Backbone.js na serwerze I klienta

Question

Przypuśćmy, że mam aplikację internetową zbudowaną za pomocą Backbone.js i Handlebars. Jako serwer używam Node.js. Teraz chcę renderować na obu końcach, tj. Na serwerze i kliencie.

Gdy trasa jest żądana po raz pierwszy, serwer wykonuje renderowanie (głównie ze względu na wydajność). Następnie wszystkie następujące czynności będą powodować renderowanie po stronie klienta.

Oznacza to, że muszę być w stanie renderować dowolną stronę na kliencie i na serwerze, za każdym razem w ten sam sposób. Oba końce muszą obsługiwać ten sam rodzaj tras.

Jak mogę wykonać to zadanie?

W tej chwili rzuciłem okiem na projekt AirBnb: rendr, ale to zdecydowanie wiąże mnie z Backbone.js (nie jestem pewien, czy chcę trzymać się Backbone.js przez cały czas), i wydaje mi się, że nie jestem jeszcze perfekcyjnie wykończony. Przynajmniej AirBnb nie poleca go jeszcze do użytku produkcyjnego.

Jakieś inne pomysły, jak to zrobić?

Jako pod-pytanie mogę również zapytać: Jaki jest preferowany sposób udostępniania kodu JavaScript między serwerem a klientem? W tym celu znam także piler, ale mogę sobie wyobrazić, że mogą istnieć lepsze rozwiązania.

Jakieś wskazówki?

Answer 1

Cóż, buduję aplikację, która to robi. Jeśli nie chcesz korzystać z rendr, będziesz musiał kodować własne wersje niektórych rzeczy, którymi się zajmują. AFAIK w momencie, gdy Twoje wybory są gotowe lub są w domu. Oto kilka porad dla misc.

• Używamy cheerio dla operacji po stronie serwera, dominacja, więc kiedy widoki czynią na serwerze, this.$el jest instancją elementem cheerio. W przeglądarce jest to jQuery.
• Nie potrzebujesz delegowania zdarzeń i wiązania po stronie serwera. Nasz kod technicznie to robi w tej chwili, ale nie ma sensu, a czystsze rozwiązanie pozwoli uniknąć go na serwerze.
• Po wyświetleniu kodu HTML renderowanego przez serwer w przeglądarce, potrzebujesz sposobu na podłączenie dużych zagnieżdżonych instancji widoku drzewa do odpowiadających im elementów w dużym drzewie DOM zagnieżdżonym. Mamy do tego domowe rozwiązanie, ale kluczem jest Backbone.View.setElement i trzeba napisać kod, aby to się stało.
• W tej chwili ponownie wyświetlamy w przeglądarce, chociaż prawdopodobnie jest to najtrudniejszy sposób instancja widoku, dodaj kilka opcji w konstruktorze, w tym wstępnie renderowanym węźle DOM, i uzyskaj poprawne okablowanie bez ponownego renderowania. To jednak ćwiczenie dla czytelnika. :-)
• Wysyłamy również surowe dane, które potrzebujemy jako JSON w tagu <script>, więc mamy zarówno renderowany przez serwer HTML (dla postrzeganej wydajności), jak i surowe dane dostępne jako JSON, dzięki czemu możemy uzyskać nasze modele szkieletowe i widoki utworzone i operacyjne. Ponownie, będziesz musiał wymyślić jakiś kod, aby poradzić sobie z tą sytuacją.
• Używamy browserify do pakowania i udostępniania kodu między serwerem a przeglądarką. Wszystkie nasze JavaScript są kodowane jako moduły CommonJS.
• Mamy podstawową funkcję isBrowser() w naszym widoku klasie nadrzędnej, dzięki czemu wiemy, kiedy należy uruchamiać kod przeglądarkowy dla powiązań zdarzeń itp.

W każdym razie, po tym jak przez wiele miesięcy pracowałem w ten sposób, nie wydaje mi się, żeby szkielet dobrze pasował do tego paradygmatu. Wiele podstawowych pojęć z kręgosłupa jest w porządku, ale nie nadaje się do mapowania instancji widoków do wstępnie renderowanych węzłów DOM. Bootstrapping modeli i kolekcji z JSON jest łatwiejszy, ale warstwa widoku prawdopodobnie wymaga znacznego widelca do czystego działania w tym stylu.