Jeg studerer faktisk fluksmønsteret og det er noe jeg ikke kan forstå angående lagrer .
Hva er de nøyaktig?
Jeg har lest mange artikler, og det ser ut til at det gjelder domene.
Betyr det at dette er den «abstrakte» delen relatert til api-samtaler eller backend-samtaler?
Det er ikke veldig klart for meg.
Rediger: Kan det være det samme som vinkelfabrikken? Henter eksterne data, lager en forretningsoppgave eller lagrer noen apptilstander (for eksempel nåværende bruker koblet til)?
Kommentarer
- En lenke til hva akkurat du ' å snakke om vil være nyttig. Mener du dette " fluksmønster "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # content
- Flux er ikke noe mer som publiserings- / abonnementsmønsteret med en begrensning at alle data først går gjennom avsenderen. Det garanterer at dataene ikke går bakover (og forårsaker forvirring). Ting som " Lagre ", " Handling " etc er bare en annen måte å si komponenter på systemet, og dataene som blir sendt videre.
Svar
OK, la meg forklare deg fra trinn for trinn
1 Hva er Flux?
- Et mønster
- Sentralisert utsender
- Enveis datastrømmer
- Listeelement
De kaller det også Flux av en grunn.
Fluximplementeringer
- Facebooks Flux
- Alt
- Reflux
- Flummox
- NuclearJS
- Fluxible
En prat med Flux
Reager : Hei handling, noen klikket på denne “Lagre Cour se ”-knapp.
Handling : Takk Reager! Jeg registrerte en action-skaper hos utsenderen, så utsenderen skulle sørge for å varsle alle butikkene som bryr seg.
Dispatcher : La meg se hvem som bryr seg om et kurs som blir lagret. Ah! Det ser ut til at butikken har registrert en tilbakeringing hos meg, så jeg skal gi henne beskjed.
Lagre : Hei dispatcher! Takk for oppdateringen! Jeg oppdaterer dataene mine med nyttelasten du sendte. Så sender jeg ut en hendelse for React-komponentene som bryr seg.
Reager : Ooo! Skinnende nye data fra butikken! Jeg oppdaterer brukergrensesnittet for å gjenspeile dette!
Flux API
register (funksjon tilbakeringing) – «Hei dispatcher, kjør meg når handlinger skjer. -Store ”
avregistrere (streng-id) -» Hei dispatcher, slutte å bekymre deg for denne handlingen. -Store ”
waitFor (array ids) -“ Oppdater denne butikken først. –Store ”
utsendelse (objektnyttelast) -“ Hei dispatcher, fortell butikkene om denne handlingen . -Aksjon ”
isDispatching () -» Jeg er opptatt med å sende tilbakeringinger akkurat nå. «
så spørsmålet reiser i tankene våre er
So Flux Is a Publish-Subscribe Model?
Ikke helt.
Skiller seg på to måter:
1. Hver nyttelast sendes til alle registrerte tilbakeringinger.
2.Tilbakeringing kan vente på andre tilbakeringinger
Sammendrag
Flux er et mønster for ensrettet dataflyt Handlinger innkapsler hendelser Dispatcher er et sentralt knutepunkt som holder tilbakeringing Butikker holder apptilstand Mange implementeringer
Kommentarer
- Mitt første problem er at staten tillater at applikasjonen har forskjellige data fra de eksterne api-enhetene: – /
- hva mener du med tilstanden tillater? uansett hvor det kalles ut endring, vil det kalles React View og igjen kalt state change method
- Innrømmer at jeg bygger et program med flyt. Jeg har å gjøre med et API, og deretter lagrer jeg dataene i butikkene mine. Hva om brukere endrer eksterne data? Jeg vil ha en forskjell mellom både klient og server
- nå, hvor kan jeg finne hvorfor. Hvis alt senderen og butikken skal gjøre, er videresendt til visning, hvorfor kan ' ikke oppdatere visningen direkte.hvorfor det er mellommenn
- @MuhammadUmer: Dispatcher er en for applikasjonen og butikken er basert på komponent i applikasjonen, så for å fjerne overflødigheten mellomledd ble introdusert
Svar
Slå opp et enkelt eksempel ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), «Butikker administrerer applikasjonstilstanden for et bestemt domene i applikasjonen.» Det vil si at de inneholder data om tilstanden til et aspekt av applikasjonen og all koden for å endre den. Hver gang det er en ny oppdatering fra Dispatcher, ser alle butikkene det, de bestemmer seg for hvordan de skal oppdatere dataene sine som svar, og deretter varsler de Visningene om at dataene er endret. I eksemplene inneholder butikkene ting som “usett trådliste” (der utsenderen varsler dem om at en ny melding har kommet eller at en gammel er lest, og visningene viser meldingstrådene til brukeren) og “gjeldende avspillingstid og tilstand. ”
Mer teknisk: de er det mellomliggende laget i rammeverket som registrerer tilbakeringing til Dispatcher for å motta oppdateringer, og varsler deretter Visningene når tilstanden til dataene endres. (Visningene kan da sende handlinger tilbake til Dispatcher.) Det er et abstrakt grensesnitt de implementerer, der hver butikk registrerer en tilbakeringing med Dispatcher og sender hendelser til Views, men hver Store ser ut til å representere et bestemt domene på en konkret måte. (Er det moteksempler?)
Svar
Butikker er områder av koden som lagrer applikasjonstilstand og kompleks logikk. En grunn for dem er at flere visninger sannsynligvis vil bruke de samme dataene, men vise dem på en annen måte, eller vise noen, men ikke alle data for et bestemt domene. For eksempel logger en bruker inn og du mottar fornavn, etternavn, e-post, bilde, by, adresse, telefonnummer osv. Denne informasjonen vises i separate visninger. I stedet for å duplisere data på tvers av visninger, kan vi bruke en butikk kalt UserStore som lagrer dataene for brukeren. Dette forenkler systemet ved å gi ett sted å gjøre endringer når logikken eller dataene som er lagret må endres. Det er mange andre grunner til å bruke en butikk, men det er den mest åpenbare jeg tror.