O masina de stare simpla on-off

Iti voi spune povestea mea, poate este si a ta …

Deci este o zi minunata la locul de munca si incep sa codez o aplicatie care pare destul de simpla.

Timpul trece, imi fac cateva sarcini si, la un moment dat, aplicatia incepe sa devina dezordonata.

Array

Rezolv problema facand cateva trucuri pentru ca sunt destul de inteligent si dezvoltator cu experienta ????.

Dar incep sa ma simt murdar si uneori uimit de modul in care ideea simpla, pe care o aveam in minte, devine atat de complexa si detaliata ca sa mapez la cod. Cred ca nu exista o relatie unu-la-unu intre harta mea mentala si cod, se pare ca este o relatie unu-la-multi .

Eu sunt creatorul. Stiu cum functioneaza lucrurile si acest lucru nu ma ingrijoreaza atat de mult, deoarece fac tot posibilul sa scriu un cod usor de inteles si de citit.

Array

Dupa aceea, aplicatia incepe sa devina mai mare si acum trebuie sa lucrez cu un coleg pentru a accelera lucrurile.

In acest moment, colegul meu are multe intrebari, deoarece nu stie cum functioneaza aplicatia! si care este ideea din spatele ei. Imi pasa de sanatatea lui si imi iau timp sa-i explic codul. Sunt o persoana amabila pe care nu vreau sa o fac sa piarda timpul acela ????.

Ceva mai tarziu am fost repartizat la alta aplicatie si, chiar acum, pot intelege durerea pe care a avut-o dragul meu coleg sa inteleaga codul meu, deoarece trebuie sa-mi dau seama cum functioneaza acest nou cod UI.

Array

Cu cateva luni in urma, am fost repartizat la prima aplicatie pentru rezolvarea unei erori si stiti, ar trebui sa-mi dau seama cum ma gandeam zilele acestea.

Mereu m-am gandit ca imi lipseste ceva, o solutie care nu vine cu documente de specificatii UI extinse si invechite. Ceva care ma face pe mine si pe altii sa prindem ideea mai repede si sa petrecem mai putin timp intelegand codul. Si da, am avut dreptate, in cele din urma, l-am gasit.

Aceste probleme se intampla aproape tuturor oamenilor implicati in orice fel de dezvoltare a sistemelor reactive, cum ar fi dezvoltarea UI si, unii oameni sunt prea obisnuiti sa se lupte cu ea, ca pare inevitabil si natural, dar nu este.

Problema este una bine cunoscuta, sistemele reactive sunt complexe din cauza complexitatii orchestrarii evenimentelor . Si rezolvarea acestei probleme este o problema de a face lucrurile explicite de la inceput. Deci, modelul tau mental ar trebui codificat intr-un mod pe care tu si ceilalti il poti argumenta cu usurinta.

In termeni simpli, o Statechart este o functie pura care contine intreaga logica legata de orchestrarea eveniment-stare intr-un mod explicit. Astfel putem evita cele mai frecvente erori si, daca exista unele, este usor sa le gasiti.

Cu statecharts, aveti un mod simplu si usor de organizat aceasta logica utilizand un grafic si cateva constructii. Acest lucru ne da puterea de a rationa despre fluxurile complexe de interfata si, in acelasi timp, impiedica sa se intample un comportament neasteptat. Doar FYI, acest formalism este folosit la NASA pentru misiunea Mars Science Laboratory.

Luata din galeria NASA

Da! Curiozitatea foloseste diagrame! ???? ????

Oferiti statisticii starea curenta , evenimentul care s-a intamplat si, optional, unele date externe si va reda urmatoarea stare si actiunile care ar trebui efectuate. O actiune este un concept destul de simplu, il puteti intelege ca comenzi sau functii care ar trebui executate ca raspuns la evenimentul care s-a intamplat.

Aveti deja masini de stat in cod

Deci, aveti deja aceasta logica in codul dvs., dar problema este ca este implicita . Aici trebuie sa il citez pe Reginald Braithwaite:

Orice clasa de model suficient de complicata contine o implementare lenta, ad-hoc, specificata informal, eronata, a jumatatii unei masini de stare. – Reginald Braithwaite in Cum am invatat sa nu-mi mai fac griji si ❤️ Masina de stat.

Implementati deja tot felul de fluxuri in codul dvs. de interfata de utilizare si, probabil, o faceti gestionand manual toate cazurile si descoperind cazurile marginale, facand unele teste exploratorii. Aceasta este cunoscuta sub denumirea de abordare ascendenta si este cea mai comuna abordare a dezvoltarii interfetelor UI in aceste zile. Atasam ascultatori de evenimente la componentele UI si efectuam un fel de actiune in interiorul acesteia. De exemplu, in vanilie JS puteti avea:

Dar ce zici de Redux ? Ei bine, in arhitecturile asemanatoare cu Redux impartiti gestionarele de evenimente in reductoare, pentru gestionarea starii si gestionare de efecte. Aceasta este o practica excelenta, iar Redux rezolva problema de gestionare a starii, dar trebuie totusi sa te lupti cu cea de orchestrare a evenimentelor (tranzitii de stat).

O chestiune de paradigme

Abordarile de mai sus sunt cunoscute sub numele de paradigma eveniment-actiune . In aceasta paradigma, cand se intampla un eveniment, declansati o actiune ca raspuns la aceasta. Problema cu aceasta este ca, pentru a coordona interfata de utilizare, trebuie sa puneti o multime de conditii in gestionarele de evenimente si chiar mai rau este posibil sa fi cuibarit conditionare if-else, sa schimbati cazurile si asa mai departe.

In Redux, impartiti acest lucru in reductor si in gestionarele de efecte, dar aveti in continuare aceeasi problema. Aceasta paradigma face codul dvs. complex si predispus la erori. Ca dezvoltator, trebuie sa va mentineti toate aceste cazuri in minte si sa aveti grija sa nu uitati ceva.

Diagramele statistice utilizeaza paradigma eveniment-stare-actiune care este natura interfetelor UI complexe. Si ati putea spune, care este diferenta dintre diagrame si diagrame de stare. Poveste lunga scurta:

Exista o notatie pentru construirea de diagrame folosind XML numita SCXML. Vom folosi XState, o biblioteca JavaScript care are propria notatie, dar care implementeaza majoritatea lucrurilor din specificatiile SCXML. Sa construim cu usurinta primul nostru statechart.

Diagrama de stare

O diagrama de stare este construita din noduri si margini. Un nod reprezinta una dintre starile posibile ale masinii si o margine reprezinta o tranzitie intre stari. Tranzitiile sunt expediate ca raspuns la evenimente si, foarte des, acestea sunt evenimente ale utilizatorilor.

Deci, sa implementam o simpla statistica on-off:

Stari imbricate

Sa facem cateva stari imbricate. Sa presupunem ca , atunci cand UI nostru este in pe stare luminile de trafic sunt vizibile , iar utilizatorul poate face clic pe ele.

Conditii

Putem face tranzitii conditionate. De exemplu, vreau ca utilizatorul sa opreasca aparatul numai in timp ce acesta se afla pe starea verde . Pentru asta sa folosim In Guard .

Poate va intrebati, dar in ce cazuri am nevoie de ea? Ei bine, sa incepem sa-l folosim pentru widget-uri si componente de stare.

Deci, atunci cand trebuie sa orchestreze evenimente (stat + solicitari catre retea + utilizator interactiune + orice), amintiti – va Statechart este prietenul tau .

Articolul urmator Voi arata cum sa creati o aplicatie din lumea reala, precum si sa explic cateva bune practici si sfaturi pentru crearea de diagrame pentru aplicatiile dvs., precum si alte caracteristici Statechart.

Cititi urmatorul articol din aceasta serie: „Modelarea unui Screensaver cu un Statechart, un caz de utilizare real”.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR