Jag studerar faktiskt flödesmönstret och det finns något jag inte kan förstå angående lagrar .
Vad är de exakt?
Jag har läst många artiklar och det verkar som att det gäller domän.
Betyder det att det här är den ”abstrakta” delen relaterad till api-samtal eller backend-samtal?
Det är inte särskilt tydligt för mig.
Redigera: Kan det vara samma sak som vinkelfabriken? Hämta fjärrdata, göra en affärsuppgift eller lagra vissa apptillstånd (nuvarande användare ansluten till exempel)?
Kommentarer
- En länk till vad exakt du ' att prata om skulle vara till hjälp. Menar du detta " flödesmönster "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # content
- Flux är inget mer än publicerings- / prenumerationsmönstret med en begränsning att all data går igenom avsändaren först. Det garanterar att uppgifterna inte går bakåt (och orsakar förvirring). Saker som " Lagra ", " Åtgärd " etc är bara ett annat sätt att säga systemets komponenter och data som skickas runt.
Svar
Okej, låt mig förklara dig från steg för steg
1 Vad är flöde?
- Ett mönster
- Centraliserad utsändare
- Enriktade dataflöden
- Listobjekt
De kallar det också för en anledning Flux.
Fluximplementeringar
- Facebooks Flux
- Alt
- Reflux
- Flummox
- NuclearJS
- Fluxible
En chatt med Flux
Reagera : Hej åtgärd, någon klickade på den här ”Spara Cour se ”-knapp.
Åtgärd : Tack Reagera! Jag registrerade en handlingsskapare hos sändaren, så sändaren bör se till att meddela alla butiker som bryr sig.
Dispatcher : Låt mig se vem som bryr sig om att en kurs sparas. Ah! Det verkar som om butiken har registrerat en återuppringning hos mig, så jag meddelar henne.
Lagra : Hej avsändare! Tack för uppdateringen! Jag uppdaterar mina uppgifter med den nyttolast du skickade. Då släpper jag en händelse för de React-komponenter som bryr sig.
React : Ooo! Glänsande ny data från butiken! Jag uppdaterar användargränssnittet för att återspegla detta!
Flux API
registrera (återuppringningsfunktion) – ”Hej dispatcher, kör mig när åtgärder händer. -Store ”
avregistrera (sträng-id) -” Hej avsändare, sluta oroa dig för den här åtgärden. -Store ”
waitFor (array ids) -“ Uppdatera denna butik först. –Store ”
expedition (objekt nyttolast) -“ Hej dispatcher, berätta för butikerna om den här åtgärden . -Action ”
isDispatching () -” Jag är upptagen med att skicka återuppringningar just nu. ”
så frågan som uppstår i vårt sinne är
So Flux Is a Publish-Subscribe Model?
Inte riktigt.
Skiljer sig på två sätt:
1. Varje nyttolast skickas till alla registrerade återuppringningar.
2. Uppringningar kan vänta på andra återuppringningar
Sammanfattning
Flöde är ett mönster för enkelriktade dataflöden Åtgärder inkapslar händelser Dispatcher är ett centralt nav som har återuppringning Butiker håller apptillstånd Många implementeringar
Kommentarer
- Mitt första problem är det tillståndet som tillåter att applikationen har olika data om fjärr-api-enheterna: – /
- vad menar du med tillstånd tillåter? varhelst emit ändring kallas kommer den att kallas React View och återigen kallas state change method
- Inse att jag bygger en applikation med flux. Jag har att göra med ett API och sedan sparar jag data i mina butiker. Vad händer om en användare modifierar fjärrdata? Jag kommer att ha skillnad mellan både klient och server
- nu var kan jag hitta varför. Om allt avsändare och butik ska göra är att vidarebefordra att visa, varför kan ' t-uppdatera vyn direkt.varför det finns mellanhänder
- @MuhammadUmer: Dispatcher är en för applikationen och butiken är baserad på komponent i applikationen så för att ta bort de redundanser mellanhänder introducerades
Svar
Leta upp ett enkelt exempel ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), ”Butiker hanterar applikationstillståndet för en viss domän inom applikationen.” Det vill säga de innehåller data om tillståndet för en aspekt av applikationen och all kod för att ändra den. När det finns en ny uppdatering från Dispatcher, så ser alla butiker den, de bestämmer sig för hur de ska uppdatera som svar och sedan meddelar de visningarna att data har ändrats. I exemplen innehåller butiker saker som ”osedda trådlistor” (där Dispatcher meddelar dem att ett nytt meddelande har kommit eller ett gammalt har lästs och Visningarna visar meddelandetrådarna för användaren) och “aktuell uppspelningstid och tillstånd. ”
Mer tekniskt: de är mellanskiktet i ramverket som registrerar återuppringningar hos Dispatcher för att ta emot uppdateringar och meddelar sedan Visningarna när datatillståndet ändras. (Vyer kan sedan skicka åtgärder tillbaka till Dispatcher.) Det finns ett abstrakt gränssnitt som de implementerar, där varje butik registrerar en återuppringning hos Dispatcher och sänder händelser till Views, men varje Store verkar representera en specifik domän på ett konkret sätt. (Finns det motexempel?)
Svar
Butiker är områden i koden som lagrar applikationstillstånd och komplex logik. En anledning till dem är att flera visningar sannolikt kommer att använda samma data, men visa dem på ett annat sätt, eller visa vissa men inte alla data för en viss domän. Till exempel loggar en användare in och du får deras förnamn, efternamn, e-post, foto, stad, adressnummer, telefonnummer etc. Denna information visas i separata vyer. I stället för att duplicera data över vyer kan vi använda en butik som heter UserStore som lagrar data för användaren. Detta förenklar ”s systemet genom att ge” en plats att göra en förändring ”när logiken eller data som lagras måste ändras. Det finns många andra skäl att använda en butik, men det är den mest uppenbara jag tror.