În primul rând vreau să clarific că acest articol a fost scris de Liro Krankka și fac doar o traducere autorizată, la sfârșitul articolului vor fi linkurile către articolul original folosit.

construire

Flutterul este cool - Rock it.

Avem API-uri moderne și noi pentru a crea interfețe utilizator (UI) complexe într-o cantitate mică de cod. Reîncărcarea la cald este minunată - putem fi cu 5 ecrane adânci în ierarhia de navigare, putem face câteva modificări în interfața de utilizare, apăsați crtl + S iar IU se va schimba în mai puțin de o secundă fără a pierde statul. Dar când vine vorba de a construi aplicații complexe, ajungem cu o tonă de cod UI.

Cu mai mult cod, vine mai multă responsabilitate de a-l menține lizibil. Păstrarea lizibilității codului facilitează întreținerea pe termen lung. Să vedem câteva sfaturi rapide despre cum să menținem mai ușor de citit codul UI.

Majoritatea proiectelor din aplicațiile noastre se bazează pe conținut plasat orizontal sau vertical. Aceasta înseamnă că de mai multe ori vom folosi widgeturile Coloană sau Rând.

Deoarece plasarea widgeturilor chiar dedesubt sau una lângă alta nu arată întotdeauna bine, vrem să avem margini între ele. Una dintre cele mai evidente modalități de a pune marja între două widget-uri este să înfășurați unul dintre ele într-un widget Padding.

Luați în considerare următorul exemplu:

Avem trei widget-uri de text într-o coloană, acestea având 8,0 de marjă între ele.

Problema: „Widget-uri ascunse”

Problema utilizării widgeturilor Padding peste tot este că acestea încep să ascundă „Logica de afaceri” a codului nostru UI. Creșteți zgomotul vizual adăugând niveluri de indentare și număr de linii.

Ceea ce vrem să facem este să facem ca widgeturile principale să iasă în evidență cât mai mult posibil. Fiecare nivel de indentare suplimentar contează. Dacă putem reduce numărul de linii în același timp, ar fi minunat și.

Soluția: utilizați SizedBoxes

Pentru a combate problema widgeturilor ascunse, putem înlocui toate Paddings cu widget-uri SizedBoxes, folosind SizedBoxes în loc de Paddings ne permite să reducem nivelul de indentare și numărul de linii:

Aici widget-urile SizedBox îndeplinesc aceeași funcție de separare a textului cu o marjă de 8.0.

Aceeași abordare poate fi utilizată și cu widgeturile Row, deoarece rândurile își aranjează widget-urile pentru copii pe orizontală, putem folosi proprietatea de lățime a SizedBox pentru margini orizontale în loc de înălțime.

Apăsările sau atingerile în mod regulat sunt cel mai comun mod prin care utilizatorul poate interacționa cu aplicațiile noastre.

Pentru a permite utilizatorului să „atingă” undeva în aplicația noastră, putem folosi un widget GestureDetector. pentru a-l utiliza trebuie să înfășurați widget-ul original și să specificați callback în proprietatea onTap din constructorul GestureDetector.

Luați în considerare următorul exemplu preluat din aplicația (creată de scriitorul original) din aplicația Kino:

Aplicația inKino are o grilă de postere de filme. când utilizatorul atinge una dintre ele, ar trebui să fie duse la pagina cu detalii despre film.

Problema: amestecarea codului UI cu Logic

Metoda noastră de compilare ar trebui să conțină doar minimul legat de crearea interfeței de utilizare a aplicației noastre. Logica conținută în onTap nu este legată de construirea UI, acest lucru adaugă zgomot inutil la metoda de construire.

În acest caz, putem determina rapid că Navigator.push introduce un nou traseu și acesta este EventDetailsPage, astfel încât atingerea unui element din grilă îi deschide pagina de detalii. Cu toate acestea, dacă este implicat apelul onTap, acest lucru ar putea necesita mai multă citire pentru a înțelege metoda de construire.

Soluția: extrageți logica unei metode private

Această problemă poate fi rezolvată prin extragerea apelului din onTap într-un bine numit metoda privată. În acest caz, creăm o metodă numită _openEventDetails:

E mai bine asa.

Deoarece apelul onTap a fost extras într-o metodă bine denumită, nu trebuie să citim întregul cod. acum este ușor de înțeles ce se întâmplă când este apelat apelul onTap, doar citind numele metodei.

Acum reducem numărul de linii din metoda noastră de construcție prețioasă și ne concentrăm doar pe citirea codului UI.

Uneori, widgeturile pentru copii ale Coloanei sau Rândului nostru nu ar trebui să fie vizibile. De exemplu, după utilizarea inKino ca exemplu, dacă un film nu are detalii despre complot dintr-un anumit motiv, nu are sens să afișăm un text gol în interfața noastră de utilizare.

O modalitate obișnuită de a condiționa copiii Coloană sau Rând arată astfel:

Esența adăugării de elemente în mod condiționat la o coloană este destul de simplă: inițializăm o listă locală de widgeturi și, dacă unul îndeplinește condițiile sale, o adăugăm la listă. În cele din urmă, trecem lista respectivă la parametrul copii al Coloanei.

În acest caz, API-ul Finnkino (API utilizat în aplicația inKino) nu returnează întotdeauna detaliile complotului sau ale actorilor filmului.

Problema: dacă este peste tot

Deși acest lucru funcționează, acele informații se vor îmbătrâni foarte repede.

Deși sunt ușor de înțeles, ocupă spațiu inutil în metoda noastră de construire. Mai ales dacă avem trei sau mai multe.

Soluția: o metodă globală în interiorul utilizărilor.

Pentru a combate problema, putem crea o metodă globală utilă care condiționează widgeturile de adăugat. Următorul este un model utilizat în codul principal Flutter Framework.

În loc să repetăm ​​logica condițională a adăugării de widget-uri la lista de copii, creăm o metodă globală utilă care o conține.

Odată ce am definit metoda, trebuie doar să importați fișierul și să folosiți metoda globală.

Ceea ce am făcut aici este că acum metoda noastră _buildMywidget () returnează un widget sau nul, în funcție de condiția care este adevărată sau nu. Acest lucru ne permite să economisim spațiu în metoda noastră de construire, mai ales dacă avem o mulțime de widget-uri condiționate.

Salveaza cel mai bun la urma.

Aceasta este probabil una dintre cele mai răspândite probleme din codul nostru de proiectare. O reclamație obișnuită în codul UI cu Flutter este că nivelurile de indentare cresc ca nebun, rezultând o mulțime de paranteze.

Luați în considerare următorul exemplu:

Exemplul de mai sus este din aplicația inKino și conține codul pentru a construi o listă de filme cu programele lor. Am făcut-o urât intenționat (scriitorul original). S-au redus multe lucruri, credeți-mă când spun că exemplul complet ar fi fost ceva grozav.

În esență, acesta este codul pentru a afișa acești băieți răi:

Dacă citești acest lucru pe un dispozitiv mobil, îmi pare rău. Codul de top nu este destul de vizibil chiar și pe ecrane mari. De ce? Sunt destul de sigur că majoritatea dintre voi știți deja.

Problema: ați folosit vreodată Lisp?

Acest vechi limbaj de programare, numit Lisp, are o sintaxă care folosește multe paranteze. Am văzut de câteva ori interfețele Flutter comparate cu Lisp și, pentru a fi sincer, văd similaritatea.

Este uimitor cum nimeni nu a mai făcut asta, așa că iată-ne.

„Cum să salvezi prințesa cu Flutter”

Chiar dacă codul de mai sus funcționează, este destul de urât să te uiți. Nivelurile de indentare merg destul de departe, există o mulțime de dezordine verticale, paranteze și este dificil să urmezi tot ce se întâmplă și unde se întâmplă.

Uită-te la paranteze la final:

Datorită cuibăririi atât de profunde, chiar și cu un IDE bun, este dificil să adăugăm elemente noi la designul nostru. Ca să nu mai vorbim, citind codul UI.

Remediați: refacturați diferite părți ale interfeței de utilizare în widgeturi separate

Nota traducătorului: Versiunea originală a articolului menționa utilizarea metodelor în loc de clase, dar din moment ce utilizatorul Wm Leler a menționat, în comentariile articolului original, că utilizarea metodelor este un anti-model În performanța aplicațiilor Flutter, autorul original și-a actualizat articolul și a creat un altul dedicat acestui subiect (lucrez la traducere). Următoarea este traducerea articolului deja actualizat.

Există două părți diferite în lista noastră: stânga și dreapta.

Partea din stânga conține informații despre filmele care încep și se termină acum. Partea dreaptă are informații precum titlul și dacă este în format 2D sau 3D. Pentru a face codul mai lizibil, să începem prin a-l separa în două widget-uri numite _LeftPart și _RightPart.

Deoarece widgetul care arată tipul de prezentare, în partea dreaptă, va introduce o mulțime de dezordine verticale și cuibărire profundă, îl vom separa într-un alt widget numit _PresentationMethod. Nota autorului original: nu vă separați metoda de construire în metode diferite, care este un model anti-performanță și care merită propriul articol.

Odată cu aceste modificări, nivelul de indentare a fost redus la jumătate. Acum este ușor să scanați codul UI și să vedeți ce se întâmplă.

Nu consider acest lucru ca o problemă similară superiorilor, dar este totuși ceva destul de important. De ce? vom vedea.

Pentru a ilustra această problemă, să ne uităm la următorul cod:

E cam ciudat, nu-i așa? Cu siguranță nu este ceva ce vedeți într-un cod bun.

Problema: neutilizarea dartfmt

Codul de mai sus nu aderă la nicio convenție comună de formatare din Dart - se pare că autorul acelui cod și-a inventat propriul stil. Acest lucru nu este bun, deoarece citirea codului necesită o atenție sporită - nu se ocupă de convențiile cu care suntem obișnuiți.

Este esențial să aveți un stil de cod convenit în comun. Acest lucru ne permite să evităm gimnastica mentală de a ne obișnui cu un stil ciudat.

Soluția: folosiți doar dartfmt

Din fericire, avem un „formatator” oficial numit dartfmt, care se ocupă de formatare pentru noi. De asemenea, deoarece există un „monopol al formatelor”, putem evita să ne certăm despre ce format este mai bun și, în schimb, să ne concentrăm asupra codului nostru.

Ca regulă principală, puneți întotdeauna virgulele după toate parantezele și rulați dartfmt.

Codul anterior formatat deja este mult mai lizibil.

Mai bine. Formatarea codului nostru trebuie să vă amintiți întotdeauna virgulele și să vă formatați codul folosind dartfmt.

Mulțumesc mult către autorul original pentru că mi-a permis să traduc articolul său și sper că aceste informații vor servi comunității vorbitoare de spaniolă.

Link către articolul original, profilul twitter al autorului și pagina acestuia.