Jeg studerer faktisk fluxmønsteret, og der er noget, jeg ikke kan forstå vedrørende gemmer .
Hvad er de præcist?
Jeg har læst mange artikler, og det ser ud til, at det vedrører domæne.
Betyder det, at dette er den “abstrakte” del relateret til api-opkald eller backend-opkald?
Det er ikke særlig klart for mig.
Rediger: Kunne det være den samme som den kantede fabrik? Henter fjerndata, laver en forretningsopgave eller gemmer nogle apptilstande (f.eks. Den nuværende bruger er tilsluttet)?
Kommentarer
- Et link til hvad præcist du ' at tale om ville være nyttigt. Mener du dette " fluxmønster "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # indhold
- Flux er intet mere end udgivelses- / abonnementsmønsteret med en begrænsning om, at alle data først går gennem afsenderen. Det garanterer, at dataene ikke går baglæns (og forårsager forvirring). Ting som " Gem ", " Handling " etc er bare en anden måde at sige Systemets komponenter og de data, der bliver videregivet.
Svar
Ok, lad mig forklare dig fra trin for trin
1 Hvad er Flux?
- Et mønster
- Centraliseret afsender
- Envejs datastrømme
- Listeelement
De kalder det også Flux af en grund.
Fluximplementeringer
- Facebooks Flux
- Alt
- Reflux
- Flummox
- NuclearJS
- Fluxible
En chat med Flux
Reager : Hej handling, nogen klikkede på denne “Gem Cour se ”-knap.
Handling : Tak Reager! Jeg registrerede en handlingsskaber hos afsenderen, så afsenderen skulle sørge for at underrette alle de butikker, der varetager.
Dispatcher : Lad mig se, hvem der holder af et kursus, der gemmes. Ah! Det ser ud til, at butikken har registreret et tilbagekald hos mig, så jeg giver hende besked.
Gem : Hej afsender! Tak for opdateringen! Jeg opdaterer mine data med den nyttelast, du har sendt. Så udsender jeg en begivenhed for de React-komponenter, der er interesserede.
Reager : Ooo! Skinnende nye data fra butikken! Jeg opdaterer brugergrænsefladen, så den afspejler dette!
Flux API
register (funktion tilbagekald) – “Hej afsender, kør mig, når handlinger sker. -Store ”
unregister (string id) -” Hej afsender, stop med at bekymre dig om denne handling. -Store ”
waitFor (array ids) -“ Opdater denne butik først. –Store ”
forsendelse (objektnyttelast) -“ Hej afsender, fortæl butikkerne om denne handling . -Aktion ”
isDispatching () -” Jeg har travlt med at sende tilbagekald lige nu. “
så spørgsmålet, der rejses i vores sind, er
Så Flux er en Publish-Subscribe Model?
Ikke helt.
Afviger på to måder:
1.Hvert nyttelast sendes til alle registrerede tilbagekald.
2. Callbacks kan vente på andre tilbagekald
Oversigt
Flux er et mønster for ensrettet datastrømme Handlinger indkapsler begivenheder Dispatcher er et centralt knudepunkt, der holder tilbagekald Butikker holder apptilstand Mange implementeringer
Kommentarer
- Mit første problem er den tilstand, der tillader, at applikationen har forskellige data om de eksterne api-enheder: – /
- hvad mener du med tilstanden tillader? uanset hvor der udsendes ændring, kaldes det React View og igen kaldet state change method
- Indrømmer at jeg bygger et program med flux. Jeg har at gøre med en API, og derefter gemmer jeg dataene i mine butikker. Hvad hvis en bruger ændrer fjerndataene? Jeg vil have en forskel mellem både klient og server
- nu hvor kan jeg finde hvorfor. Hvis alt afsender og butik vil gøre, er at se fremad, hvorfor kan ' t-opdateringsvisning direkte vises.hvorfor der er mellemmænd
- @MuhammadUmer: Dispatcher er en til applikationen, og butikken er baseret på komponent i applikationen, så for at fjerne de overflødige mellemmænd blev introduceret
Svar
Ser et simpelt eksempel op ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), “Butikker administrerer applikationstilstanden for et bestemt domæne i applikationen.” Det vil sige, de indeholder data om tilstanden for et aspekt af applikationen og al den kode, der skal ændres. Når der er en ny opdatering fra Dispatcher, ser alle butikkerne det, de beslutter, hvordan de skal opdatere deres svar som svar, og derefter underretter de visningerne om, at dataene er ændret. I eksemplerne indeholder butikkerne ting som “uset trådliste” (hvor afsenderen underretter dem om, at en ny besked er ankommet, eller en gammel er blevet læst, og visningerne viser beskedtrådene til brugeren) og “aktuel afspilningstid og tilstand. ”
Mere teknisk: de er det mellemliggende lag i rammen, der registrerer tilbagekald hos Dispatcher for at modtage opdateringer, og giver derefter Visningerne besked, når datatilstanden ændres. (Visningerne kan derefter sende handlinger tilbage til Dispatcher.) Der er en abstrakt grænseflade, de implementerer, hvor hver butik registrerer et tilbagekald med Dispatcher og sender begivenheder til visningerne, men hver butik ser ud til at repræsentere et specifikt domæne på en konkret måde. (Er der modeksempler?)
Svar
Butikker er områder af koden, der gemmer applikationstilstand og kompleks logik. En grund til dem er, at flere visninger sandsynligvis bruger de samme data, men viser dem på en anden måde eller viser nogle, men ikke alle data for et bestemt domæne. For eksempel logger en bruger ind, og du modtager deres fornavn, efternavn, e-mail, foto, by, adresse, telefonnummer osv. Disse oplysninger vises i separate visninger. I stedet for at duplikere data på tværs af visninger kan vi bruge en butik kaldet UserStore, der gemmer dataene for brugeren. Dette forenkler systemet ved at give et sted at foretage en ændring, når logikken eller de gemte data skal ændres. Der er mange andre grunde til at bruge en butik, men det er den mest åbenlyse, synes jeg.