— tl;dr masse kode nedenfor —
Hos Wearable Intelligence trenger vi pålitelig sanntidstilkobling for arbeidere ute i felten. Aller viktigst er det at vi viser en frakoblet tilstand nøyaktig på nett- og mobilklienter.
Det er ikke noe revolusjonerende med Gmail-lignende gjenoppkoblingsbannere, men måten vi håndterer det på med React og NuclearJS (Flux-implementeringen vi bruker og elsker) er ganske kult, synes jeg, og etter noen få iterasjoner har vi fått finessene til native WebSockets nedgradert ganske elegant. Forhåpentligvis er det noe nyttig her hvis du driver med lignende områder.
Veivisere
- React brukes kun til brukergrensesnitt. Ingen forretningslogikk – de binder seg bare til kjernefysiske gettere og kaller kjernefysiske handlinger.
- Kjernebaserte «getters» er rene funksjoner som henter data fra lagre, og kjernebaserte lagre oppdaterer kun tilstand basert på kjernebaserte handlinger. Verken kjernebaserte «getters» eller lagre utfører noen eksterne handlinger selv.
- All WebSocket-logikk er rent isolert til en tjeneste helt utenfor Nuclear.
- Kjerneaksjoner knytter alt sammen, administrerer tilkoblingen og reagerer på bruker- og socket-vedlikeholdshendelser.
Reager: Bare brukergrensesnittet, frue
Vi bruker en «Signalering»-server for å kringkaste hendelser i sanntid til nett- og mobilklienter. For å legge til denne funksjonaliteten i en av nettappene våre, trenger vi bare å inkludere en Signalering-komponent i en hvilken som helst Authenticated-overordnet komponent.
Nuclear lar oss binde statusen til signalforbindelsen som et uforanderlig kart. Vi kan utløse en tilkoblingshandling når komponenten monteres og når brukeren eksplisitt ber om det, og vi kan koble fra når komponenten er avmontert.
Resten er brukergrensesnitt. Det er kjempeenkelt for designerne våre å se hvordan alt fungerer uten å tenke på alt maskineriet som driver det, og de kan gjerne redigere markupen eller relatert SCSS. Boom.
WebSocket-leverandøren: Nøye å inneholde singletoner
Tidligere har sanntidstilkoblingen min vært mye enklere ved bruk av Socket.io , men i dette tilfellet må vi bygge og administrere WebSockets direkte for å koble til en eksisterende server (kanskje et emne for et annet innlegg).
Det vanskelige er at vi trenger Nuclear-handlinger for å referere til den gjeldende socket-instansen, så vi trenger en singleton vi kan persistere og mutere, noe som best holdes helt unna Nuclear.
Denne leverandøren kan trygt kalles fra enhver handling og stoles på at den leverer den gjeldende instansen. Instansen kan, som forespurt, tilbakestilles hardt, noe som er en uheldig nødvendighet under gjenopprettingsprosessen.
Som en bonus vedlikeholder leverandøren også et permanent kart over tidtakere, noe som forhindrer at kjernekraftlagre må sette og fjerne intervaller.
Vår spesifikke socket-implementering krever at vi pinger serveren med en tilstedeværelsespakke hvert ~30. sekund, slik at leverandøren har denne funksjonaliteten innebygd, og den vedlikeholder en kartlegging av meldingstype til sine behandlere (som hver kaller kjernefysiske handlinger fra andre moduler).
Atomaksjoner: Arbeidshestene
For å holde alt ryddig og oversiktlig, ønsker vi bare å eksponere handlingene «koble til» og «frakoble». Alt annet er en intern implementeringsdetalj.
«Connect» er den eneste metoden som utløser en hard tilbakestilling av socketen ved å sende true som det tredje argumentet. Andre instansieringer av WebSocketProvider returnerer ganske enkelt den eksisterende instansen.
Resten av de interne funksjonene er der den virkelige handlingen finner sted. Hendelseshåndtererne starter og stopper også de aktuelle tidtakerne.
Hvis tilkoblingen er i klartilstand, utløser identifikasjonstimeren en ping hvert 30. sekund, noe som oppfyller tilstedeværelseskravet vårt for selve signaleringsserveren.
Hvis forbindelsen lukkes eller blir «kald» (ingen lukkingshendelse, men ingen respons på pings på over et minutt), stoppes identifikasjonstimeren , og gjenoppkoblingstimeren startes. Hvert sekund utløses handlingen UPDATE_RECONNECT_TIMER , som butikken vår bruker til å oppdatere statusen sin, slik at React-komponenten vår ikke trenger å gjøre noe med det.
Siden WebSocketProvider sjekker om det finnes en timer før intervallet stilles inn, er det ingen risiko for at funksjoner som checkConnection blir kalt for mange ganger.
NuclearJS-feilsøking er en drøm som går i oppfyllelse
Når hørte du det sist? Her er hva jeg ser når jeg feilsøker en ny endring:
Hvilke som helst av disse loggobjektene kan utvides for å vise handlingsnyttelasten samt appens status på det tidspunktet. Du trenger ikke lenger å legge inn console.log overalt for å finne ut hva som skjedde mellom hendelsene.
I dette tilfellet kan du ved innlogging se appen starte et tilkoblingsforsøk, rapportere endringen i tilstand når tilkoblingen åpnes, utløse en tilstedeværelsesping og motta resultatet. Et par identifiserings- og mottakspinger kommer inn 30 sekunder senere.
Så avsluttet jeg signaleringsserveren manuelt (lokalt!), og du ser at lukkingshendelsen kommer etterfulgt av et umiddelbart og mislykket forsøk på å gjenopprette tilkoblingen. Timeren for å gjenopprette tilkoblingen oppdateres hvert sekund, men når jeg slår på signaleringen igjen, får vi de forventede tilkoblingshendelsene.
Ved utlogging blir alt frakoblet og ryddet opp, og vi ser innloggingssiden vår gjengitt.
Hvis du syntes dette var nyttig, så vær ikke redd for å anbefale det.
Å ja, og vi ansetter vår tredje frontend-ingeniør hvis du har lyst til å få betalt for å fikse med React, Nuclear og ImmutableJS hos en Series-A-finansiert oppstartsbedrift støttet av blant annet Andreessen Horowitz, First Round, Kleiner Perkins og Google Ventures.
