Chciałem tylko dodać kilka pragmatycznych różnic od czasu, gdy tworzyłem kod RxJS inspirowany Redux.
Każdy typ akcji odwzorowałem na instancję Subject. Każdy składnik stanowy będzie miał Subject, który jest następnie mapowany na funkcję redukującą. Wszystkie strumienie reduktora są łączone z, merge
a następnie scan
wyprowadzają stan. Wartość domyślna jest ustawiana startWith
tuż przed scan
. Użyłem publishReplay(1)
dla stanów, ale mogę go później usunąć.
Funkcja reaktora czystego renderowania będzie polegała tylko na tym, aby umieścić dane zdarzenia, wysyłając wszystkich producentów / tematy.
Jeśli masz komponenty potomne, musisz opisać, jak te stany są łączone w twoje. combineLatest
może być do tego dobrym punktem wyjścia.
Istotne różnice we wdrożeniu:
Brak oprogramowania pośredniego, tylko operatorzy rxjs. Myślę, że to największa siła i słabość. Nadal możesz pożyczać koncepcje, ale trudno jest mi uzyskać pomoc od siostrzanych społeczności, takich jak redux i cycle.js, ponieważ jest to kolejne niestandardowe rozwiązanie. Dlatego muszę w tym tekście napisać „ja” zamiast „my”.
Brak przełącznika / przypadku lub ciągów dla typów akcji. Masz bardziej dynamiczny sposób rozdzielania działań.
rxjs może być używany jako narzędzie w innym miejscu i nie jest zawarty w zarządzaniu stanem.
Mniejsza liczba producentów niż typów działań (?). Nie jestem tego pewien, ale możesz mieć wiele reakcji w komponentach nadrzędnych, które słuchają komponentów potomnych. Oznacza to mniej imperatywnego kodu i mniejszą złożoność.
Jesteś właścicielem rozwiązania. Żadne ramy nie są potrzebne. Dobry i zły. W końcu i tak napiszesz własny framework.
Jest to znacznie bardziej fraktalne i możesz łatwo subskrybować zmiany z poddrzewa lub wielu części drzewa stanu aplikacji.
- Zgadnij, jak łatwo jest robić epiki tak, jak robią to redux-obseravable? Naprawdę proste.
Pracuję również nad znacznie większymi korzyściami, w których komponenty podrzędne są opisywane jako strumienie. Oznacza to, że nie musimy w reduktorach uzupełniać stanu rodzica i dziecka, ponieważ możemy po prostu („tylko”) rekurencyjnie łączyć stany na podstawie struktury komponentu.
Myślę też o pominięciu reagowania i przechodzenia ze snabbdom lub czymś innym, dopóki React lepiej nie poradzi sobie ze stanami reaktywnymi. Dlaczego mielibyśmy budować nasz stan w górę tylko po to, aby ponownie go rozbić za pomocą rekwizytów? Więc spróbuję stworzyć wersję 2 tego wzorca za pomocą Snabbdom.
Oto bardziej zaawansowany, ale mały fragment, w którym plik state.ts buduje strumień stanu. To jest stan komponentu ajax-form, który pobiera obiekt pól (danych wejściowych) z regułami walidacji i stylami CSS. W tym pliku używamy po prostu nazw pól (kluczy obiektów), aby połączyć wszystkie stany dzieci w stan formularza.
export default function create({
Observable,
ajaxInputs
}) {
const fieldStreams = Object.keys(ajaxInputs)
.map(function onMap(fieldName) {
return ajaxInputs[fieldName].state.stream
.map(function onMap(stateData) {
return {stateData, fieldName}
})
})
const stateStream = Observable.combineLatest(...fieldStreams)
.map(function onMap(fieldStreamDataArray) {
return fieldStreamDataArray.reduce(function onReduce(acc, fieldStreamData) {
acc[fieldStreamData.fieldName] = fieldStreamData.stateData
return acc
}, {})
})
return {
stream: stateStream
}
}
Chociaż kod może nie mówić wiele w izolacji, pokazuje, jak można budować stan w górę i jak z łatwością tworzyć dynamiczne zdarzenia. Cena do zapłacenia polega na tym, że musisz zrozumieć inny styl kodu. Uwielbiam płacić tę cenę.