Jaka jest odpowiednia szczegółowość dla widoków Backbone.js?

Question

Używam Backbone.js do renderowania małego rogu z existing large web app. Jeśli wszystko pójdzie dobrze, widzę, że Backbone.js rozwija się, aby objąć całą aplikację, nadając bardzo potrzebną strukturę organicznej aplikacji. To jest wstęp. Teraz za problem:

Mam pole wyboru, które pozwala użytkownikowi wybrać plan czytania. Po zmianie wyboru widok aktualizuje opisowy tekst, interfejs kalendarza i mały widżet do oznaczania dzisiejszych odczytów jako zakończonych. Widżet będzie miał pole wyboru dla każdego odczytu (jednego lub więcej) we współczesnym wpisie oraz przycisk do kontynuowania czytania następnego dnia. (Bieżąca wersja tego interfejsu bez szkieletu (bez schematu zakończenia) jest widoczna po prawej stronie: the existing app.

Jaka jest odpowiednia szczegółowość dla każdego widoku? Zidentyfikowaliśmy następujące "skrzypce" bity ".

• sam Tab, który obejmuje wszystkie zawarte kontrole
• polu Wybierz
• tekst opisowy, który reaguje na pole zaznaczania
• kalendarz, który reaguje na select pole
• Widget odczytów, który odpowiada na pole wyboru i zawiera:
  • Opcjonalnie, przycisk "Start", który aktywuje bieżący plan.
  • Po aktywowaniu jedno lub więcej pól wyboru odpowiadających poszczególnym odczytom w dzisiejszym wpisie.
  • Po aktywowaniu przycisku "Dalej", który uzupełnia dzisiejszy wpis i wyświetla następny.

Gdyby każdy z tych punktach dostać swój własny pogląd? Tylko główne elementy (zakładka, pole wyboru, widget)? Pierwsze da kilka widoków. Pierwsze wydaje się, że może to prowadzić do zbyt skomplikowanych implementacji widoku. Co jest najlepsze?

Uwaga: Zdaję sobie sprawę, że można to interpretować jako niezwykle subiektywne pytanie, ale wciąż zawijam głowę wokół wzorów Backbone.js i Javascript/DOM MVC, i mam nadzieję, że istnieje wąski "to jest to, co jest zamierzone/działa najlepiej" od bardziej doświadczonych praktyków Backbone.js. Dzięki!

Answer 1

Nie ma jednoznacznej odpowiedzi na twoje pytanie. Możesz rzucić okiem na ziarnistość kiełków dla przykładów.

Możesz również obejrzeć http://vimeo.com/17186379, gdzie Yehuda Katz ilustruje trudności z aktualizacją różnych fragmentów strony.

Jednym ze sposobów patrzenia na to byłoby sprawdzenie, która część powinna zostać odświeżona przy różnych zmianach modelu/zdarzeniach i spróbuj zminimalizować ponowne renderowanie.

Niestety nie ma dobrych odpowiedzi, jak pan zauważył;)

Answer 2

Ogólnie ziarnistość widokach będzie zależeć na znalezieniu równowagi pomiędzy złożonością konkretnego kawałka UI i nadmiernej fragmentacji widokiem na mały sztuk. Prawdopodobnie nie użyłbym widoku na coś tak małego jak przycisk (klasa CSS to wszystko, czego naprawdę potrzebujesz).

W tym konkretnym przypadku prawdopodobnie wyświetli się widżet kalendarza - aby można go było łatwo ponownie wykorzystać w innych miejscach w aplikacji - oraz widok dla całej karty Oddania. Resztę można wykonać poprzez wiązanie zdarzeń.

Jeśli chodzi o aktualizacje modelu i ponowne renderowanie, cały pomysł z kręgosłupem polega na oddzieleniu tego problemu od widoków. Modele emitują zdarzenia "zmiany", gdy zmieniają się ich atrybuty, a niezależnie od tego, które widoki są na stronie w danym czasie i wyświetlają dane danego modelu, zostaną powiadomione o zmianie i mogą się same zaktualizować.