Share
Indiferent de limbaj, erorile trebuie să fie tratate într-un mod curat și simplu, fie că este în folosul utilizatorului final sau dezvoltatorului următor. Atunci când efectuați o acțiune incorectă pe un site, acesta nu trebuie doar să vă lovească cu un cod de eroare sau o comandă nereușită. Ar trebui să vă avertizeze printr-un mesaj explicativ despre ceea ce se întâmplă.
Acest lucru nu ar trebui să fie diferit atunci când codul pentru alți dezvoltatori. Când construiți o bibliotecă, un cadru sau pur și simplu lucrați într-o echipă, nu sunteți singurul care să utilizați codul. Este posibil ca mulți dezvoltatori cu fundaluri foarte diferite să fie nevoiți să utilizeze codul dvs. și nu ar trebui să sapă adânc în sursă și răsucirile și răsucirile minții pentru a afla ce se întâmplă.
De aceea ar trebui să rezolvați erorile în mod corespunzător. Chiar și în Sass. Chiar și atunci când se compilează la ceva la fel de permisiv ca CSS. Ori de câte ori construiți o funcție personalizată sau un amestec, trebuie să vă asigurați întotdeauna că totul funcționează așa cum era de așteptat și când nu este cazul, ar trebui să luați o altă cale.
Nu știu pentru tine, dar nu-mi place să las compilatorul Sass să cadă. Aș prefera să am un mesaj miștoos, care să-mi explice că am uitat un argument mai degrabă decât să mă confrunt cu:
Poveste lungă scurtă: gestionați corect erorile. Îți arăt cum.
Unul dintre primele lucruri de făcut atunci când se construiește o funcție este să se asigure că toate argumentele sunt specificate. Din păcate, Sass nu va introduce chiar funcția dacă numărul de argumente care îi sunt transmise este incorect. Din fericire, compilatorul o manipulează într-un mod destul de frumos, cu un mesaj precum: Mixin-mi-awesome-mixin lipseste argumentul argumentului-minunat. așa că nu e așa de rău.
Dacă nu doriți să lăsați acest lucru în mâinile compilatorului și ar trebui să vă ocupați mai degrabă de el însuși, puteți lucra în jurul acestuia prin specificarea parametrilor impliciți pentru toate argumentele din funcție / mixin. Nu numai că este mai bine ca utilizatorul final să nu trebuiască să specifice toate argumente fiecare o singură dată, dar, de asemenea, vă permite să declanșați mixin / funcția în toate cazurile și să faceți tot ce trebuie făcut.
Cel mai important lucru acum este să vă asigurați că toate argumentele sunt valide. De exemplu, dacă aveți nevoie de o culoare, trebuie să vă asigurați că dezvoltatorul transmite într-adevăr o culoare a funcției și nu un număr sau un șir. Dacă aveți nevoie de o listă cu trei valori, trebuie să verificați lungimea pentru a vă asigura că există sunteți trei valori, nu două sau patru.
Din fericire, Sass face foarte ușor acest lucru cu o grămadă de funcții implicite, inclusiv tip de() pentru a verifica tipul de date al unei valori. Apropo, Sass 3.4 ar trebui să introducă chiar is-type-of (valoare $, tip $) pentru a rezolva problema tipului de testare () care se întoarce întotdeauna listă în timp ce poate fi și o hartă.
Oricum, chiar și atunci când scrieți o bucată de cod pentru dezvoltatori cu o cunoaștere decentă a lui Sass, ar trebui să acordați atenție introducerii funcțiilor.
De exemplu, atunci când faci Valoarea $: $ input + "px", esti în esență casting un număr (dacă $ intrare este un număr, evident) la un șir. Atunci dacă încerci să faci $ valoare * 2, Sass va arunca o eroare deoarece încercați să multiplicați un șir. Mai multe informații despre acest fenomen în acest articol.
Depășirea erorilor în cazul unei funcții personalizate este de fapt destul de ușoară: verificați dacă este necesar să fiți verificat. Dacă condiția nu se potrivește, reveniți fals (sau nul, a se vedea mai jos) și avertiza utilizatorul cu ajutorul @a avertiza Direcția Sass.
@ function add-10 (numarul de $) @ daca tipul de (numarul $)! = "numarul" @warn "'# $ number' nu este un numar de 'add-10'."; @return false; @return $ număr + 10;
În acest caz (chiar prost, sunt de acord), dacă număr $ argumentul nu este un număr, funcția va reveni fals iar utilizatorul va fi avertizat că au trecut un argument greșit printr-un mesaj care apare în terminalul lor: "SWAG" nu este un număr pentru "add-10".
Dacă argumentul este valabil, atunci returnă pur și simplu numărul + 10. Simplu ca plăcinta.
Atunci când se ocupă de un amestec, este ceva mai complicat pentru că nu întoarceți ceva; în schimb, veți elimina regulile CSS. Pentru a rezolva problema, trebuie să declarați un boolean care servește drept verificator de valabilitate. Vă rugăm să luați în considerare următorul exemplu:
Modul @mixin ($ name) // Initializeaza un validator boolean $ everything-okay: true; // Verificați validitatea argumentului @in cazul tipului ($ name)! = "String" @warn "'# $ name" nu este un șir pentru "module". "; $ totul - bine: fals; // Dacă totul este încă în regulă, conținutul de conținut al combinației @if $ totul - bine @content;
Când doriți să vă asigurați că unul dintre argumente este o listă cu mai multe elemente în el, trebuie să testați întotdeauna lungimea și nu tipul de date. Pentru a spune pur și simplu, Sass tratează toate valorile ca liste de elemente unice și, în unele cazuri, vă puteți găsi cu o listă cu un singur element care este de fapt încă un listă.
Pe de altă parte, o problemă potențială la verificarea lungime este că poate fi a Hartă de asemenea. O modalitate de a vă asigura absolut sigur că vă confruntați cu o listă de valori multiple este să o faceți astfel:
@ la lungime (valoarea $)> 1 și tipul de (valoarea $)! = harta // Este o listă cu mai multe valori
Dacă sunt complet sincer cu tine, aș spune niciodată. Nu puteți fi niciodată prea atent și probabil că puteți verifica orice argument de orice funcție și orice amestec al aplicației dvs. Cu toate acestea, probabil că nu este necesar. Am o regulă de aur atunci când vine vorba de verificarea argumentelor: în cazul în care valoarea este de natură să facă compilarea Sass, atunci ar fi trebuit să o verificați.
Asta inseamna ca daca ai un mixin acceptand argumente care sunt folosite direct ca valori pentru proprietatile CSS, nu cred ca are rost sa le verifici agresiv. Scenariul cel mai rău este că aceste valori vor fi eliminate în ieșirea CSS, rezultând în CSS nevalid, care nu va fi înțeles de browser. În afară de câteva încărcări suplimentare de octeți, nu va fi mult rău.
De exemplu, ia în considerare următoarele mixin:
Dimensiune @mixin (lățime $, înălțime $: lățime $) lățime: $ lățime; înălțime: $ height;
Iar acum ia în considerare următoarea utilizare:
.element @ include dimensiunea (10, "șir");
CSS rezultată va fi:
.element lățime: 10; înălțime: "șir";
Orice browser va respinge pur și simplu ambele proprietăți, deoarece valorile lor sunt nevalide. Nu e mare lucru.
Cu ceea ce am văzut, ar trebui să puteți gestiona corect 99% dintre posibilele erori, totuși acolo este un caz în care devine din ce în ce mai greu să ții pasul cu Sass: atunci când se ocupă de erori de la o funcție numită de la o funcție numită de la o funcție ...
M-am confruntat cu acest lucru chiar când scriu SassyJSON, un parser JSON scris în Sass. Practic, treceți un șir JSON la JSON-decodarea funcția, care o transmite către _json-decodarea - valoare funcția, care o trimite apoi la a _json-decodarea - * funcție în funcție de tipul de valoare care este analizată. Oricum, nu era neobișnuit să am trei, patru, poate cinci apeluri de funcții, încorporate unul în celălalt.
Din păcate, într-un astfel de caz, nu există nici un mod curat pentru a opri execuția. Trebuie să faceți bulele de erori până la nivelul superior, verificând manual revenirea funcției la fiecare nivel. De exemplu, dacă aveți o eroare în cea mai adâncă funcție, ar trebui să returneze fals funcția de apelare, care ar trebui să verifice această valoare, să își dea seama că este fals, așa că întoarceți falsul la funcția superioară și așa mai departe până când ajungeți la cel mai înalt, care apoi oprește execuția.
Asta e destulă durere pentru a face față, dar nu este de ales. Acestea fiind spuse, dacă trebuie să cuibărești mai multe niveluri de funcții, aș spune că nu folosești Sass corect.
Ori de câte ori ceva nu merge bine, puteți reveni la diferite valori, fals și nul fiind cele mai populare. Presupun că te poți întoarce -1 sau void 0 dacă veniți dintr-un fundal JavaScript. Cred că ați putea reveni și la ceva asemănător COD DE EROARE deși acest lucru ar face ca verificarea unui eșec să fie puțin mai complicată.
Eu folosesc pentru a reveni fals pentru că asta vorbește de la sine: este falsă. Totuși, aceasta ar putea fi o problemă cu funcții care ar trebui să returneze un boolean. Cum ai ști dacă funcția revine fals deoarece rezultatul a fost evaluat la fals, sau fals pentru că a existat o eroare?
Astfel, puteți decide să alegeți o altă valoare. Există un lucru interesant cu nul: o proprietate CSS cu o valoare de nul nu vor fi compilate la sursă. Practic, aceasta înseamnă că dacă utilizați o funcție Sass ca valoare pentru o proprietate CSS și ceva e greșit, proprietatea CSS va fi pur și simplu omisă de compilatorul Sass.
Cred că este foarte frumos pentru ceva de genul:
Accentsconagua
.element fundal: get-color-from-theme ("admin"); Dacă funcția get-culori de la temă a fost bine proiectat, ar trebui să vă asigurați că admin tema există și este de fapt legată de o valoare de culoare. Dacă admin nu există, atunci funcția s-ar întoarce nul care ar avea ca rezultat fundal: null. Acest lucru va face ca Sass să omite regula când compilarea fișierului în CSS.
arunca() FuncţieCele mai multe limbi au arunca funcție sau directivă. De obicei, această funcție acceptă un mesaj de eroare sau o excepție ca argument și doar oprește execuția scriptului pentru a afișa acest mesaj (în consola sau ceva) ori de câte ori există o eroare. De exemplu, în JavaScript, puteți face ceva de genul:
dacă (typeof myVariable === "undefined") aruncați userException nou ("" variabilă "ar trebui să fie definită"); Din păcate, Sass nu are acest lucru. Practic, nu există absolut nici o cale în Sass să oprească o funcție sau un mixin de la executare. Ați putea construi unul, dar nu va opri practic funcția, s-ar întoarce doar fals și va înregistra un mesaj.
aruncare funcțională ($ log) @warn $ log; @return false;
În loc să scrie manual @a avertiza directive și directivă @return false de fiecare dată, puteți folosi arunca() funcția amintiți-vă însă că nu face nici o magie și nici nu oprește să ruleze scriptul. Pur și simplu returnează "false" și înregistrează un mesaj de eroare.
Acestea fiind spuse, având un arunca directiva a fost solicitată de câteva ori de susținătorii Sass și se pare că au fost de acord că nu ar fi atât de rău să pună în aplicare un @eroare directivă care ar încălca execuția actuală a domeniului de aplicare în conformitate cu numărul # 747. Poate pentru 3.4, nu sunt sigur.
Indiferent de modul în care faceți acest lucru, trebuie să verificați întotdeauna funcțiile și intrările mixte, mai degrabă decât să lăsați compilatorul să se prăbușească deoarece sa întâmplat ceva neașteptat. În calitate de dezvoltator, aș prefera să am un jurnal curat și să nu mai producă nimic decât o urmă de stivă uriașă, dar din nou nu sunt eu.
Ca exemplu live, vă sugerez să aruncați o privire la o mică bibliotecă de butoane pe care am construit-o ceva timp în urmă. Majoritatea codului din mixinul de bază este verificarea argumentării și tratarea erorilor. Aceasta face amestecul să arate aglomerat, dar cred că este esențial pentru dezvoltatorii care vor folosi codul.
În cele din urmă, asigurați-vă că ați venit cu ceva care se potrivește atât cu dumneavoastră, cât și cu echipa dvs. și veți fi bine.
