En introduktion til Flux arkitektoniske mønster

Discover Functional JavaScript blev udnævnt til en af ​​de bedste nye funktionelle programmeringsbøger af BookAuthority !

Flux er et arkitektonisk mønster, som Facebook foreslår til opbygning af SPA'er. Det foreslås at opdele applikationen i følgende dele:

  • Butikker
  • Afsender
  • Visninger
  • Action / Action Skabere

butik

Store styrer staten. Det kan gemme både domænetilstand og brugergrænsefladetilstand.

Butik og tilstand er forskellige begreber. Stat er dataværdien. Store er et opførselsobjekt, der styrer tilstand gennem metoder. I tilfælde af administration af bøger: boglisten er staten, og BookStore administrerer listen.

En butik administrerer flere objekter. Det er den eneste kilde til sandhed med hensyn til disse specifikke objekter. I en applikation kan der være mange butikker. For eksempel: BookStore, AuthorStore, UserStore.

Der er ingen settermetoder i butikken. Du kan kun anmode om ændring af tilstand ved at sende en handling til afsenderen.

En butik lytter efter alle handlinger og beslutter, hvilken af ​​dem der skal handle. Dette betyder normalt en switcherklæring. Når butikken har foretaget tilstandsændringerne, udsender den en ændringshændelse. Butikken er en begivenhedsudsender.

Butikker tager ikke andre butikker som afhængigheder.

Afsender

Dispatcher er et enkelt objekt, der sender handlinger / begivenheder til alle registrerede butikker. Butikker skal registrere sig til begivenheder, når applikationen starter.

Når en handling kommer ind, videregiver den handlingen til alle registrerede butikker.

Udsigt

Visning er komponenten til brugergrænsefladen. Det er ansvarligt for gengivelse af brugergrænsefladen og for håndtering af brugerinteraktion. Visningerne er i en træstruktur.

Visninger lytter til ændringer i butikken og gengives igen.

Visninger kan opdeles yderligere i præsentations- og containervisninger.

Præsentationsvisninger forbinder ikke til afsender eller butikker. De kommunikerer kun gennem deres egne egenskaber.

Containervisninger er forbundet til butikker og afsender. De lytter til begivenheder fra butikker og leverer data til præsentationskomponenter. De får de nye data ved hjælp af butikkernes offentlige getter-metoder og sender derefter dataene ned i visningstræet.

Container ser afsendelseshandlinger som svar på bruger iteration.

Handlinger

En handling er et almindeligt objekt, der indeholder alle de oplysninger, der er nødvendige for at udføre denne handling.

Handlinger har en typeegenskab, der identificerer handlingstypen.

Da handlingsobjekter bevæger sig rundt i applikationen, foreslår jeg at gøre dem uforanderlige.

Handlinger kan komme fra forskellige steder. De kan komme fra visninger som et resultat af brugerinteraktion. De kan komme fra andre steder som initialiseringskoden, hvor data kan hentes fra en Web-API, og der udløses handlinger for at opdatere visningerne. Handling kan komme fra en timer, der kræver skærmopdateringer.

Handlingsskabere

Øvelsen er at indkapsle koden, skabe handlinger i funktioner. Disse funktioner, der opretter og afsender handlinger, kaldes handlingsskabere.

Web-API-opkald

Når du foretager Web API-opkald for at opdatere brugergrænsefladen, efterfølges Web API-opkaldet af en handling for at opdatere butikken. Når butikken er opdateret, udsender den en ændringsbegivenhed, og som resultat gengives den visning, der lytter til den begivenhed, igen.

Web-API-opkald foretages i handlingsskabere. Vi kan udtrække den kode, der gør API-opkaldet i Web API Utils-funktioner.

Envejs datastrøm

Opdatering af visningsflow i en enkelt retning:

Visninger ændrer ikke de data, de har modtaget. De lytter efter ændringer af disse data, opretter handlinger med nye værdier, men opdaterer ikke dataene.

Butikker, visninger og enhver anden handling kan ikke ændre tilstanden i (andre) butikker direkte. De skal sende en handling gennem afsenderen

Datastrømmen er kortere i lagerlæsning end i skrivning. Datastrømmen i lagerskrivning adskiller sig mellem asynkron og synkron handling.

Store læser

Store Writes i synkron handlinger

Store Writes i asynkrone handlinger

Fordele

Flux-arkitektur er bedre i et program, hvor visninger ikke kortlægges direkte til domæne butikker. For at sætte det på en anden måde, når visninger kan oprette handlinger, der opdaterer mange butikker, og butikker kan udløse ændringer, der opdaterer mange visninger.

Handlinger kan fortsættes og derefter afspilles igen.

Ulemper

Flux kan tilføje unødvendig kompleksitet til et program, hvor hver visning kortlægges til en butik. I denne form for anvendelse er det nok med en adskillelse mellem visning og lagring.

Se for eksempel på Sådan oprettes en applikation i tre lag med React.

Konklusion

Butikker administrerer tilstand. De ændrer kun tilstand ved at lytte efter handlinger. Butikker underretter visninger for at opdatere.

Visninger gengiver brugergrænsefladen og håndterer brugerinteraktion. Containervisninger lytter til butiksændringer.

Afsenderen sender handlinger til alle registrerede butikker.

Handlinger er almindelige objekter.

Discover Functional JavaScript blev udnævnt til et afbedste nye funktionelle programmeringsbøger fra BookAuthority !

For mere om anvendelse af funktionelle programmeringsteknikker i React, se på Functional React .

Lær funktionel reaktion på en projektbaseret måde med funktionel arkitektur med React og Redux .

Følg på Twitter