Redux: lokalizowania Selektory z Reduktory

Question

W tym Redux: Colocating Selectors with Reducers egghead samouczku Dan Abramov sugeruje użycie selektorów, które akceptują drzewa państwowej pełny zamiast plasterków państwa, do hermetyzacji wiedzy o stanie dala od komponentów. Twierdzi, że to ułatwia zmianę struktury państwa, ponieważ komponenty nie mają o tym pojęcia, z czym całkowicie się zgadzam.

Jednak sugeruje podejście, że dla każdego selektora odpowiadającego konkretnemu wycinkowi stanu, definiujemy go ponownie obok reduktora głównego, aby mógł zaakceptować pełny stan. Z pewnością to obciążenie związane z implementacją podważa to, co próbuje osiągnąć ... upraszczając proces zmiany struktury państwa w przyszłości.

W dużej aplikacji z wieloma reduktorami, z których każdy ma wiele selektorów, czy nie będziemy nieuchronnie napotykać na nazwy kolizji, jeśli definiujemy wszystkie nasze selektory w pliku reduktora root? Co jest nie tak z importowaniem selektora bezpośrednio z powiązanego z nim reduktora i przejściem w stan globalny zamiast odpowiadającego fragmentu stanu? na przykład

const todos = (state = [], action) => { 
    switch (action.type) { 
    case 'ADD_TODO': 
     return [...state, todo(undefined, action)]; 
    case 'TOGGLE_TODO': 
     return state.map(t => todo(t, action)); 
    default: 
     return state; 
    } 
}; 

export default todos; 

export const getVisibleTodos = (globalState, filter) => { 
    switch (filter) { 
    case 'all': 
     return globalState.todos; 
    case 'completed': 
     return globalState.todos.filter(t => t.completed); 
    case 'active': 
     return globalState.todos.filter(t => !t.completed); 
    default: 
     throw new Error(`Unknown filter: ${filter}.`); 
    } 
}; 

Czy jest jakaś wada, aby zrobić to w ten sposób?

Answer 1

Po popełnieniu tego błędu osobiście (nie w Redux, ale w podobnym wewnętrznym środowisku Flux), problem polega na tym, że sugerowane podejście łączy selektory z lokalizacją powiązanego stanu reduktora w ogólnym drzewie stanu. Powoduje to problemy w kilku przypadkach:

• Chcesz mieć reduktor w wielu lokalizacjach w drzewie państwowe (np bo powiązany komponent pojawia się w wielu częściach ekranu lub jest wykorzystywany przez wielu niezależnych ekranów Twoje zgłoszenie).
• Chcesz ponownie użyć reduktora w innej aplikacji, a struktura stanu tej aplikacji różni się od pierwotnej aplikacji.

Dodaje również domniemaną zależność od reduktora rootera do selektorów każdego modułu (ponieważ muszą oni wiedzieć, w jakim kluczu są, co jest naprawdę obowiązkiem reduktora root).

Jeśli selektor potrzebuje stanu z wielu różnych reduktorów, problem można powiększyć. Idealnie, moduł powinien wyeksportować czystą funkcję, która przekształca wycinek stanu na wymaganą wartość, i to do plików modułu root aplikacji, aby go podłączyć.

Jedną z dobrych sztuczek jest posiadanie pliku, który eksportuje tylko selektory, a wszystkie pobierają wycinek stanu. W ten sposób mogą być obsługiwane w partii:

// in file rootselectors.js 
import * as todoSelectors from 'todos/selectors'; 
//... 
// something like this: 
export const todo = shiftSelectors(state => state.todos, todoSelectors); 

(shiftSelectors ma prostą implementację - Podejrzewam, że biblioteka Reselect ma już odpowiednią funkcję).

Zapewnia to również odstępy między nazwami - selektory todo są dostępne pod eksportem "todo". Teraz, jeśli masz dwie listy todo, możesz łatwo wyeksportować todo1 i todo2, a nawet zapewnić dostęp do dynamicznych, eksportując funkcję zapamiętaną, aby utworzyć je dla określonego indeksu lub id, powiedzmy. (np. jeśli możesz wyświetlić dowolny zestaw list rzeczy do zrobienia na raz). Na przykład.

export const todo = memoize(id => shiftSelectors(state => state.todos[id], todoSelectors)); 
// but be careful if there are lot of ids! 

Czasami selektory wymagają stanu z wielu części aplikacji. Ponownie, unikaj łączenia przewodów z wyjątkiem korzenia.W module, musisz:

export function selectSomeState(todos, user) {...} 

a następnie plik selektorów korzeniowe, które można importować i eksportować ponownie wersję, że przewody w górę „todos” i „użytkownik” w odpowiednich częściach drzewa państwowej .

Tak więc, dla małej, jednorazowej aplikacji, prawdopodobnie nie jest to zbyt użyteczne, a po prostu dodaje zestaw znaków (szczególnie w JavaScript, który nie jest najbardziej zwięzłym językiem funkcjonalnym). W przypadku dużego zestawu aplikacji wykorzystującego wiele współdzielonych komponentów, będzie on pozwalał na wielokrotne użycie i będzie utrzymywał jasne obowiązki. Ułatwia także selekcjonowanie modułów, ponieważ nie muszą one najpierw sprowadzać się do odpowiedniego poziomu. Ponadto, jeśli dodasz FlowType lub TypeScript, unikniesz naprawdę złego problemu, który będzie musiał zależeć od rodzaju twojego podrzędnego typu (w zasadzie, domniemana zależność, o której wspomniałem, staje się wyraźna).