Mūsų patirtis pereinant nuo mažiau prie „Sass“

Daug buvo parašyta apie perėjimą nuo vanilės CSS prie CSS išankstinio procesoriaus ir dėl geros priežasties - išankstiniai procesoriai suteikia energijos ir valdymo, kurio negalime pasiekti tik naršyklėje. Iš straipsnių, kad išaukštinti ikiprocesoriaus dorybes daugiau techninių skaitymų, tokių kaip išsami Etsy Perėjimas prie SCSS skalėje “, - jaučiu, kad surijau juos visus.

At HASHTAGAI , mes padarėme tai, apie ką nerašyta beveik tiek pat - pereidami nuo vieno išankstinio procesoriaus prie kito. Anksti Sproutas buvo priimtas Mažiau ; praėjusių metų pabaigoje priėmėme sprendimą pereiti prie SCSS, panašios į CSS sintaksės Sasas . Skyrėme laiko, kad perėjimas vyktų sklandžiai, ir patirtis parodė keletą gilių „Less“ ir „Sass“ skirtumų.

Kodėl?

Prieš pradedant tai, ko išmokome, jūsų pirmasis teisėtas klausimas turėtų būti toks: „Kodėl nerimauti?“ Mums jau buvo naudingi kintamieji ir mišiniai, @import ir spalvų funkcijos. Be abejo, „Sass“ turi keletą funkcijų, kurių trūksta mažiau žemėlapiai ir funkcijos , bet taip toli pasiekėme be jų.

Išsiskiria dvi pagrindinės perėjimo priežastys:

Bendruomenė: „Github“ ieškokite „lib“ plėtinio: scss, tada ieškokite „lib“ plėtinio: mažiau. Šio rašymo metu rezultatai aiškūs: 120 234 SCSS failai, 29 449 mažiau failų. „Switching“ suteikia galimybę plačiau naudotis geromis idėjomis ir didesniu atvirojo kodo baseinu. Paskelbta net populiarioji „Bootstrap“ biblioteka, viena iš priežasčių, kodėl „Less“ išliko gyvybinga pereinama prie SCSS .
Greitis: Libsass akmenys. Mūsų stilių kūrimo laikas pagerėjo daugiau nei 500%. Nors Libsassas dar nepasivijo naujausios „Sass spec“ versijos, nejaučiame, kad mums nieko netrūktų.

Kaip?

Mūsų sudarytoje CSS yra beveik 19 000 selektorių. Po perjungimo surinkta CSS turėjo būti beveik identiška; turėjome užtikrinti, kad šis perėjimas būtų nematomas mūsų klientams. O kaip yra su šiuo metu vykdomomis funkcijomis? Mūsų neseniai sukurtas atnaujinimas pakeitė 3837 stilių linijas - kaip ta komanda galėjo saugiai perjungti vidurinį srautą?

Mes apsvarstėme tris galimybes:

Pirmiausia viską sudarykite CSS. Tai vienintelis būdas 100% tikslumu užtikrinti, kad mūsų vartotojai gauna tuos pačius stilius, ir iš tikrųjų perjungti jungiklį per vieną dieną. Švarios pertraukos idėja visada vilioja, bet naujas kodas ne visada yra geresnis kodas . Net ir su tokiomis priemonėmis kaip sass-konvertuoti ir css2compass , laikas, kurį praleisime atstatydami, gerokai atsvertų visas kitas galimybes.
Naujus stilius rašykite tik SCSS. Svarstėme nubrėžti liniją smėlyje - Mažiau yra sena ir sugadinta; Sassas yra nauja karštybė . Galų gale mes atmetėme šią idėją. Tiek daug būtų galima gauti iš karto perėjus, ir niekas nenorėjo išlaikyti pariteto tarp dviejų mišinių ir kintamųjų rinkinių.
Konvertuokite visus mūsų mažiau failus į SCSS ir pataisykite, kas sugenda. Arba išmesdami istoriją, ar pridėdami dar vieną kūrimo užduotį, kurią prižiūrėjome, mes pradėjome viską konvertuoti.

Valymo namai

SCSS nesiskiria nuo Less, ar ne? „ Konvertavimas iš „Less“ į „Sass“ “Dalijasi regex paieškų serija, kad būtų pakeisti akivaizdžiausi sintaksės skirtumai, pvz., .Awesome-mixin () vs @mixin awesome-mixin (). Šios regex paieškos yra surašytos į maziau2sasas , kurį mes paleidome per visus savo failus.

Tačiau jei tai būtų taip lengva, tinklaraščių tikrai nebūtų daug. Keli užsitęsę „less2sass“ scenarijaus traukimo prašymai pabrėžia kai kuriuos jo nepaisymus, pvz eilutės interpoliacijos skirtumai . Daugiau iššūkio buvo sukūrimo klaidos, su kuriomis susidūrėme atlikus konversiją, kurios išryškino skirtumus, didesnius nei paprastas regexas galėtų išspręsti. Jei atvirai, radome ir blogų CSS.

Mes paėmėme šias sukūrimo klaidas ir sudarėme sąrašą, ką turime ištaisyti, ir prieš konvertuodami stilius žinojome, kad galime tai ištaisyti. Prieš konvertuodami nusprendėme išvalyti mažiau failus.

Fixin ’Mixins

Pradėjome nuo skirtumo, kaip „Less“ ir „Sass“ tvarko sąlyginius. Štai paprastas gradiento mišinys, kurį turėjome:

„Sass“ siūlo paprastą @ if… @ struktūrą, o mūsų rinkinyje dirbo tai, ką mažiau vadina a mixin apsauga . Mūsų gradiento mišinio atveju mes jį naudojome norėdami pakeisti iš tiekėjo priešdėlio juodraščio sintaksę į W3C sintaksę. Žinojome, kad turėsime perrašyti šį mišinį.

Tada mes sustojome ir ilgai apžvelgėme visus savo mišinius. Dauguma jų pridėjo pardavėjo priešdėlius ir išsprendė naršyklės skirtumus, pvz., Aukščiau esantį gradiento mišinį. Įveskite Automatinis pataisymas , įrankis, analizuojantis CSS ir pritaikantis tiekėjo priešdėlius, remiantis palaikomų naršyklių sąrašu. Pridėję „Autoprefixer“ prie savo versijos, pašalinome devynis derinius. Kaip premiją, „Autoprefixer“ pašalina nereikalingus pardavėjų priešdėlius, kurie padėjo mums nustatyti kai kuriuos dulkėtus mūsų CSS kampus ir sukurti mažesnius kompiliuotus failus.

Gera pamoka iš mūsų patirties čia: nešvaistykite laiko konvertuodami ar pertvarkydami tai, ką galite ištrinti.

Dar vienas derinys, į kurį verta atkreipti dėmesį: Less rekomenduoja parametrus atskirti kabliataškiais . Tik nedaugelis buvo parašyti tokiu būdu, tačiau juos visus reikėjo pakeisti, derinant su mišinio apibrėžimais ir kur jie buvo naudojami. Laimei, „Less“ palaiko ir kabliataškius, ir kablelius, todėl šį pakeitimą galėtume atlikti prieš konversijos veiksmą.

skaičius reiškia 444

„Ampersand“ piktnaudžiavimas

Išsprendę „mixins“, atkreipėme dėmesį į dar vieną sukūrimo klaidų šaltinį: ampersandai . Tai vienas galingiausių operatorių tiek „Sass“, tiek „Less“, ir jie dirba labai panašiai. Išskyrus atvejus, kai jie to nedaro. Ir tada jie veikia labai skirtingai.

Pavyzdžiui, turėdami 19 000 selektorių galite įsivaizduoti, kad susiduriame su specifiškumo problemomis, kurios dažnai greitai išsprendžiamos:

Mažiau gamina h1.modal-header, kaip galima įtarti, bet Sassas užspringsta. Pabandėme tai išspręsti:

Puikiai veikia su Ruby Sass, bet nuo šio rašymo „Libsass“ dar nepalaiko šio naudojimo . Šiuo atveju net nesvarstėme galimybės pereiti prie Ruby Sass. Vietoj to mes išrašėme h1.modal-antraštę už .modal taikymo srities ribų. Mes žinome, kad tai yra problemos požymis, todėl ištraukę selektorių iš taikymo srities ir iškviesdami jį komentaru, galime lengviau identifikuoti tas problemas savo kode.

Pablogėjo, kai maišytuve tokiu būdu buvo naudojamas amperantas. Štai ištrauka iš mažiau rinkinio, kurį turėjome mygtukams:

Vėlgi, „@ at-root“ direktyva negalėjo mums padėti „Libsass“. Šiuo atveju turėjome pažvelgti į pagrindinę specifiškumo nepaisymo priežastį ir ją išspręsti. (Geros naujienos yra tai, kad mes ją ištaisėme pašalindami tris pernelyg specifinius stilius kitur.)

Kitas skirtumas tarp „Less“ ir „Sass“ ampersandų iš tikrųjų buvo naudingas:

Mes tikėjomės .checkbox-wrap> .checkbox-widget, .radio-wrap> .radio-widget. Tačiau Less apdoroja ampersandą daugiau rekursijų ir taip surašo:

Niekada (ar nenorėtume) radijo mygtukui naudoti žymės langelio valdiklį. Laimei, Sassas iš tikrųjų išsprendė problemą, apie kurią nežinojome, nes nežiūrėjome į savo sudarytą CSS.

Išmokta pamoka: dažnai peržiūrėkite sukurtą CSS, kitaip nežinote, ką atsisiunčia jūsų vartotojai.

Rezultatų palyginimas

Atnaujinimai, skirti pataisyti ir pašalinti „mixins“, išspręsti amperų ir neatitikimų problemą ir pašalinti kai kuriuos kitus bitus, kurie nebuvo konvertuojami švariai, įvyko per septynis įsipareigojimus per mėnesį. Buvo gera valyti namus ir nustatyti būsimas pertvarkymo galimybes.

Vis dėlto nesvarbu, kaip atrodo mūsų šaltinio kodas; svarbu tai, kas pristatoma mūsų vartotojams. Mes svarstėme galimybę generuoti AST palyginti mūsų sukurtą CSS. Po tam tikrų tyrimų ir eksperimentų paaiškėjo, kad viskas, ko mums reikia, yra būdas sužinoti, ar labai mažai pasikeitė sukurtoje CSS. Todėl pakaks senų gerų diferencijų - kuo mažesnis diffas, tuo geriau. Kiekvienoje užklausoje buvo pateiktas „Less“ kompiliavimo rezultatų prieš ir po rezultatų skirtumas. „Xcode“ kūrėjo įrankis „FileMerge“ buvo labai patogu palyginti rezultatus. Jei pamatėme tai, ko nesitikėjome, grįžome tyrinėti.

Mes prilipome prie „FileMerge“ ir „diffs“, kai pradėjome reguliaraus paieškos ir pakeitimo antspaudą ir iš tikrųjų pavertėme failus SCSS. Tačiau dviejų skirtingų išankstinių procesorių surinkti rezultatai pavertė mūsų diferentus nenaudingais, nes skiriasi skirtukai ir laikikliai. Pridėjome papildomą žingsnį norėdami normalizuoti CSS prieš ir po formatą paprastas mazgo scenarijus . Tai sumažina CSS, tada ją pagražina. Negali būti paprasčiau.

Normalizuoti formatavimą labai padėjo, bet šukavimas per diferentą vis tiek užtruko apie dvi solidžias peržiūros dienas. Naudingas procesas, bet sunkus. Abejojame, ar pritaikytas AST sprendimas būtų padėjęs paspartinti peržiūrą. Reikėjo spręsti visus skirtumus.

Tačiau skirtumai buvo nedideli. Selektoriai šiek tiek kitokia tvarka, dešimtainis apvalinimas ir net nedideli spalvų funkcijų rezultatų skirtumai. Kiekvienas skirtumas buvo kruopščiai patikrintas prieš pradedant „Sassed-up CSS“ gamybą.

Kas toliau

Sujungus, nebaigtas darbas beveik nesustojo. Visus parengiamuosius darbus, atliktus prieš laiką, buvo lengva konvertuoti į mažesnį vis dar kuriamų failų skaičių. Visi buvo ir veikia maždaug per dvi dienas. Net pertvarkyta „Compose“ komanda sugebėjo per kelias valandas sugrįžti į SCSS. Planuodami iš anksto ir išvalydami esamus stilius prieš traukdami jungiklį, viskas pasikeitė.

Dabar pereiname prie šablonų nustatymo, didelių CSS failų suskaidymo į modulius, gamybos nenaudojamų selektorių audito CSS audito ir praleidžiame daugiau laiko įrankiams palyginti AST ar kokį kitą analizuojamą mūsų CSS vaizdą. Ar minėjau, kad turime beveik 19 000 CSS atrankų? Mes prie jo, bet tai yra dar vienas straipsnis.

Dalykitės Su Savo Draugais: