Zarys
W mojej aplikacji używam React i Reflux i mam hierarchiczną konfigurację w odniesieniu do moich danych. Próbuję rozbić elementy mojej aplikacji w oddzielne sklepy, aby móc poprawnie powiązać zdarzenia i rozdzielić wątpliwości.Jak radzić sobie z danymi hierarchicznymi z magazynami Reflux?
Mam następujący przepływ danych:
Workspaces -> Placeholders -> Elements
W tym scenariuszu, gdy obszar roboczy jest utworzony domyślny zastępczy musi z kolei być utworzony z referencyjnym (ID) do nowo utworzonego obszaru roboczego. To samo dotyczy relacji zastępczej do elementu.
kłucia
refluks sposób wydaje się sugerować PlaceholderStore słucha wyzwalaczy z WorkspaceStore, dodając nowo utworzony identyfikator this.trigger().
Reflux zezwala tylko na pojedyncze zdarzenie uruchamiane ze sklepów; w ten sposób zapobiega się, aby zewnętrzne komponenty mogły rozpoznawać działania. Oznacza to, że jeśli jeden wyzwalacz w sklepie wyśle identyfikator jako argument[0], kolejne wyzwalacze powinny zrobić to samo (zachować spójność). Jest to problem dla składników, które szukają aktualizacji dla wielu obszarów roboczych (na przykład ponownego zamawiania/aktualizacji masowych).
rozwiązanie Niepożądane
myślałem dodać w koncepcji StoreActions; Akcje, które tylko przechowują, mogą tworzyć, które inne sklepy będą następnie nasłuchiwały (skutecznie odrzucając pierwotny czynnik uruchamiający ze sklepów). Dzięki temu komponentom/sklepom można słuchać określonych zdarzeń, a argumenty przekazane do wspomnianych zdarzeń można dostosować bez obaw. Wydaje się, że to niewłaściwy sposób na nadużywanie systemu zdarzeń Reflux.
Pomoc
Czy powinienem próbować podzielić powiązane dane? Czy istnieje lepszy sposób na uporządkowanie danych?
Czytałem o zbiorczych sklepach, ale nie widziałem żadnych implementacji do analizy. Czy oferują one rozwiązanie, łącząc ze sobą dane z wielu sklepów, a jeśli tak, to co jest odpowiedzialne za tworzenie zdarzeń, których komponenty odpowiedzi mogą słuchać?
Wielkie dzięki za pomoc/wgląd każdemu może zaoferować!
* Jestem nowy w Reflux *. Uważam, że tworzenie wielu '' 'sklepów' 'jest złe. Wolałbym pojedynczą akcję dla wielu '' 'sklepu'' (powiedzmy * CRUD *), a następnie przesłać w dół' '' fn''' ('' 'onTodoItemCreate''') jeden moduł (powiedzmy część "create") dla użytkownika), a następnie jeden główny plik dla tego modułu (dla wszystkich składników lub jego programu '' 'route handler''' lub template) przechodzący przez' '' store handler''' (lub '' triggers''') aż do komponentów, które byłyby potrzebne dla mniejszych podkomponentów. – srph
Nowość także w Refluksie. Łatwiej będzie utrzymać jeden sklep, który zarządza odpowiednio złożonymi modelami w obrębie. Tak właśnie robię to obecnie w mojej aplikacji React/Reflux. Jednak rozmiar danych rośnie, może zajść potrzeba podzielenia danych i przechowuje się, jak próbujesz to zrobić. Chodzi mi o to, że możesz zacząć od prostszej struktury i ulepszyć ją tylko w razie potrzeby (przez rzeczywiste użycie, które tego wymaga). –