Gdzie przechowywać stan przejściowy interfejsu użytkownika w Ember 2.0

Question

Ember 2.0 bardzo się starał, aby wszystko było komponentem. Niedługo pojawią się komponenty rutowane, prawdopodobnie również kontrolery zostaną wycofane.

Kontekst

Jednak nie jest powracającym problemem zmierzyć podczas tworzenia interfejsu użytkownika, który nie mam satysfakcjonujące wzór do tej pory: stan interfejsu użytkownika.

Co robię?

• stan Wybór
• Obecny nacisk
• Składane/stan rozłożony w jakimś wyświetlaczu drzewa

Zasadniczo każde państwo, które nie jest częścią rzeczywistych danych, ale musi być śledzone na zasadzie osobno dla każdego obiektu. W przeszłości robiono to z Controllers, działając jako proxy dla modeli. Takie podejście jest już przestarzałe. Nowe podejście to Components wszędzie, na lepsze. Component wykonuje księgowość, śledzi stan przejściowy i otrzymujesz akcje z powrotem.

Typowy wzór, jaki mam, jest jednak ze stanem współdzielonym, na przykład lista z elementami do wyboru.

Kwestia

Budowanie składnik List z następującymi wymaganiami:

• można wybrać każdy element.
• Stan zaznaczenia zmienia DOM (niektóre powiązania klas).
• Użytkownik może narysować prostokąt w komponencie listy, aby zaznaczyć kilka pozycji jednocześnie.
• Idealnie, całe zachowanie może zostać wyabstrahowane jako mixin.

Pytanie: gdzie znajduje się flaga wyboru?

Próby

1) wszystko to jest komponentem.

Każdą pozycję robię jako podkomponent, powiedzmy {{moja-lista-pozycji}}. Komponent śledzi stan zaznaczenia. Problem: w jaki sposób składnik listy może zaktualizować stan zaznaczenia?

2) Przenieś stan z podkomponentów.

Umieść go na komponencie listy. W oddzielnej tablicy stanów obok listy pozycji. Plusy: lista ma cały stan, którego potrzebuje. Wady: to koszmar, aby utrzymać synchronizację, gdy elementy są dodawane lub usuwane z listy. Oznacza to, że podkomponent nie ma dostępu do stanu. A może mógłbym przekazać je jako wartość powiązaną?

3) Ponowne wprowadzenie serwerów proxy.

Pomyśl o tym, jest sposób, aby podzielić się pewnym stanem: umieścić go na modelach.Cóż, nie w rzeczywistych modelach, aby nie zanieczyszczać ich lokalnym stanem, ale poprzez ustawienie ArrayProxy, które zwróci pewną liczbę ObjectProxy dla każdego elementu, aby utrzymać stan.

Zalety: to jedyne rozwiązanie, które udało mi się całkowicie wdrożyć. Minusy: enkapsulacja i dekapitacja przedmiotów to kłopot. Ponadto po kilku warstwach przekazu, get i set muszą przejść przez 4 ou 5 serwerów proxy, które, jak się obawiam, będą stanowić problem z wydajnością.

Ponadto nie działa dobrze w przypadku miksów. Czy chcę wyodrębnić niektóre mixy HasSelection i mixin HasFoldableItems i mixin Sortable, wszystkie one potrzebują jakiegoś stanu.

Powrót do deski kreślarskiej

Czy jest jakiś lepszy wzorzec nie znalazłem?

znalazłem następujące istotne pytania, ale to doprowadziło mnie nigdzie:

• Ember.js - where should interface state be stored? (2012, sugeruje coś podobnego do mojego # 3 powyżej)
• Road to Ember 2.0 - High level Ember app structure feedback? (niektóre z kluczowych pytań, na liście są istotne do tego)

Answer 1

Świetne pytanie - rzeczywiście poszedłem do jednego z członków głównego zespołu Ember, aby dowiedzieć się, a odpowiedź brzmi obecnie usługi. Ponieważ składnik najlepiej pozostawić bezstanowy (w przeważającej części) można wykorzystać usługę do utrzymania tego stanu, który nie pasuje do modelu utrwalonego na serwerze.

Tutaj jest doskonałym przykładem, że Stef Penner ułożyła pokazując jak można zapisać projekt „e-mail” w aplikacji ember (to nie jest utrwalane backend)

https://github.com/stefanpenner/ember-state-services

Przykład elementem odniesienia (z powyższego projektu github)

export default Ember.Component.extend({ 
    tagName: 'form', 
    editEmailService: Ember.inject.service('email-edit'), 
    state: Ember.computed('email', function() { 
    return this.editEmailService.stateFor(this.get('email')); 
    }).readOnly(), 

    actions: { 
    save() { 
     this.get('state').applyChanges(); 
     this.sendAction('on-save', this.get('email')); 
    }, 

    cancel() { 
     this.get('state').discardChanges(); 
     this.sendAction('on-cancel', this.get('email')); 
    } 
    } 
});