2015-12-07 14 views
6

Używam Redux przez miesiąc i kiedy projekt staje się naprawdę duży, nie wydaje się konieczne, aby wystawić całą aplikację na wszystkie wartości każdego Reduktora. Czy istnieje dobry sposób na tworzenie tymczasowych stanów lub tworzenie indywidualnych stanów dla komponentów?Jak utworzyć tymczasowe stany w ReactRedux?

Czy myślę o tym wszystkim źle, czy jest to tak skonstruowane z jakiegoś powodu?

Odpowiedz

2

Zakładam, że przez "wartości każdego reduktora" odnosisz się do całego stanu aplikacji.

Możesz z pewnością podzielić swój stan i ujawnić tylko niezbędne elementy do konkretnych komponentów. Do tego służy metoda connect z powiązań connect. connect przyjmuje funkcję (np. mapStateToProps), która z kolei bierze cały stan aplikacji i eksponuje tylko elementy określone jako rekwizyty do komponentu, który "łączy" z redux.

Na przykład, załóżmy, że masz prosty React komponentu tak, że pokazuje, nazwisko i adres użytkownika:

var myComponent = React.createClass({ 
    render: function() { 
    return (
     <div>{Name from redux state goes here}</div> 
     <div>{Address from redux state goes here}</div> 
    ); 
    } 
}); 

Oczywiście nie trzeba wysłać cały stan aplikacji do tego elementu, po prostu kawałek z nazwą i adresem użytkownika. Więc użyć connect tak:

// the "state" param is your entire app state object. 
function mapStateToProps(state) { 
    return { 
    name: state.name, 
    address: state.address 
    } 
} 

var connectedComponent = connect(mapStateToProps)(myComponent); 

Owinięty myComponent teraz efektywnie wygląda następująco:

var myComponent = React.createClass({ 
    propTypes: { 
    name: React.PropTypes.string // injected by connect 
    address: React.PropTypes.string // injected by connect 
    }, 

    render: function() { 
    return (
     <div>{this.props.name}</div> 
     <div>{this.props.address}</div> 
    ); 
    } 
}); 
+1

Tak, już to robię. Próbuję uniknąć posiadania tak wielu plików reduktora. Jeśli potrzebuję tylko przechowywać 1 zmienną dla komponentu, to czuję się jak overkill do stworzenia reduktora dla tej trywialnej zmiennej, która zostanie użyta tylko w jednym miejscu. – tkiethanom

+6

Tak, aby poradzić sobie z tym problemem, wróciłem do przechowywania lokalnego, przejściowego stanu w samych komponentach i użycia 'setState'. Umieszczenie całego stanu aplikacji, w tym banalne rzeczy, takie jak to, czy wysuwany przycisk jest otwarty, w twoich reduktorach/sklepach brzmi świetnie w teorii, ale szybko odkryłem, że rzeczy stają się nieporęczne. Teraz używam tylko sklepów w stanie, który musi być udostępniony w całej aplikacji. –

+0

Tak, myślę, że również zacznę używać 'setState' dla komponentów, które nie muszą komunikować się z resztą aplikacji. – tkiethanom

2

Według Redux docs:

Stan całej aplikacji jest przechowywany w drzewie obiektów w ciągu jednego sklepu.

Jeden stan. Jeden sklep. to jest to! Możesz tworzyć lokalne stany w poszczególnych komponentach, które są informowane przez większy stan aplikacji, ale w tym momencie po prostu kopiujesz części większego stanu, który już istnieje.

Należy pamiętać, że w złożonej aplikacji nie udostępnisz całego stanu swoim "inteligentnym" komponentom. Nawet jeśli posiadasz 100 funkcji redukujących, po connect a component to the store możesz użyć mapStateToProps, aby wybrać tylko wybrane części aplikacji i utworzyć rekwizyty dla swojego komponentu. Więc nigdy nie zobaczysz wszystkich części stanu, z których nie korzystasz, nawet jeśli wiesz z głębi umysłu, że one istnieją.

To naprawdę świetny wzór architektoniczny. W jednym stanie masz single source of truth. Nie jest możliwe, aby jakakolwiek część Twojej aplikacji miała nieaktualne dane z tego powodu. Pamiętaj, że definiujesz tylko swój stan, struktury, gdy zainicjujesz swój stan aplikacji i nie ładujesz wszystkich danych . W związku z tym nie ma żadnego działania związanego z wydajnością poprzez zainicjowanie całej struktury na starcie. I znowu, nigdy nie będziesz ładować całego stanu aplikacji w jeden komponent tak czy inaczej (chyba że to wymaga), więc twoje rekwizyty będą zawsze możliwe do zarządzania.

+0

Tak staram się uniknąć tak wiele plików redukcyjne. Jeśli potrzebuję tylko przechowywać 1 zmienną, to czuję się jak overkill, aby stworzyć reduktor dla tej trywialnej zmiennej, która zostanie użyta tylko w jednym miejscu. – tkiethanom

+1

Cóż, to zależy od tego, czym jest banalna zmienna.Jeśli jest to coś w rodzaju flagi lub czegoś, co nie jest prawdziwymi danymi, nie ma nic złego w tworzeniu go jako lokalnego składnika. Pod koniec dnia wszystko to tylko javascript, więc możesz dodać dowolne warianty. Nie ma policji w Redux. Jednak za każdym razem, gdy masz do czynienia z rzeczywistymi * danymi *, ma to sens, aby spłynąć ze stanu aplikacji. Może wydawać się przesadą dla małej aplikacji, ale uwierz mi, to naprawdę dobrze się sprawdza i zapewnia, że ​​twoje dane zawsze muszą być świeże, ponieważ mogą pochodzić tylko z jednego miejsca. –

+1

Haha tak, nie ma policji w Redux, ale pomocne są sugestie dotyczące tego, co ludzie uważają za właściwy sposób. Tak więc prawdopodobnie użyję po prostu 'setState' w moich komponentach do tego. – tkiethanom

Powiązane problemy