Нашият опит преминава от по-малко към Sass

Много е писано за преминаването от ванилов CSS към CSS препроцесор и с добра причина - препроцесорите добавят мощност и контрол, които не можем да получим само в браузъра. От статии, които възхвалявайте добродетелите на препроцесор към по-технически четения като подробното на Etsy „ Преминаване към SCSS в мащаб ', Чувствам, че съм ги погълнал всички.

В ХАШТАГИ , направихме нещо, за което не е писано почти толкова - превключване от един препроцесор на друг. В началото Sprout прие По-малко ; взехме решение в края на миналата година да преминем към SCSS, подобен на CSS синтаксис на Sass . Не бързахме, за да се уверим, че преходът е плавен и опитът подчерта някои дълбоки разлики между Less и Sass.

Защо?

Преди да стигнем до наученото, първият ви въпрос - легитимен - трябва да бъде: „Защо да си правим труда?“ Вече се възползвахме от променливи и комбинации, @imports и цветни функции. Разбира се, Sass има редица функции, които по-малко липсват, като карти и функции , но стигнахме дотук без тях.

Открояват се две основни причини за превключване:

Общност: Потърсете github за разширение lib: scss, след това потърсете разширение lib: по-малко. Към момента на написването резултатите са ясни: 120 234 SCSS файла, 29 449 по-малко файлове. Превключването предлага достъп до по-широк набор от добри идеи и по-голям басейн с отворен код за плуване. Дори популярната библиотека Bootstrap, една от причините Less да остане жизнеспособна, обяви преминава към SCSS .
Скорост: Libsass скали. Времето за изработка на нашите стилове се подобри с над 500%. Въпреки че Libsass все още не е наваксал най-новата версия на спецификацията на Sass, ние не смятаме, че ни липсва нищо.

Как

Нашият компилиран CSS има близо 19 000 селектори. След превключването този компилиран CSS трябваше да бъде почти идентичен; трябваше да гарантираме, че този преход е невидим за нашите клиенти. А какво ще кажете за функции, които в момента са в процес? Нашите скорошна актуализация за съставяне промени 3 837 реда стилове - как този екип може безопасно да превключи средния поток?

Обмислихме три възможности:

Първо компилирайте всичко в CSS. Това е единственият начин да гарантираме със 100% точност, че нашите потребители получават едни и същи стилове и всъщност да извадят превключвателя за един ден. Идеята за чисто почивка винаги е примамлива, но новият код не винаги е по-добър код . Дори и с инструменти като sass-convert и css2compass , времето, което бихме отделили за възстановяване, значително би надхвърлило всички други възможности.
Пишете само нови стилове в SCSS. Обмислихме да нарисуваме линия в пясъка - По-малко е старо и разрушено; Sass е новата горещина . В крайна сметка отхвърлихме тази идея. Толкова много ще се спечели от незабавното превключване и никой не е искал да поддържа паритет между две групи миксини и променливи.
Конвертирайте всичките ни по-малко файлове в SCSS и коригирайте какво се прекъсва. Изправени пред изхвърляне на история или добавяне на друга задача за изграждане, която да поддържаме, се заехме да преобразуваме всичко.

Почистваща къща

SCSS не е толкова различен от Less, нали? „ Преобразуване от по-малко в Sass ”Споделя поредица от търсения с регулярни изрази, за да промени най-очевидните синтаксисни разлики, като .awesome-mixin () срещу @mixin awesome-mixin (). Тези търсения на регулярни изрази са събрани по-малко2sass , които прегледахме през всичките ни файлове.

Ако беше толкова лесно обаче, наистина нямаше да има много за блогове. Няколко продължителни заявки за изтегляне към скрипта less2sass подчертават някои от неговите пропуски, като низови интерполационни разлики . По-предизвикателни бяха грешките при изграждането, които срещнахме след преобразуването, които подчертаха разликите, по-големи от обикновените регулярни изрази, които биха могли да разрешат. За да бъдем откровени, открихме и някои лоши CSS.

Взехме тези грешки при изграждането и направихме списък на това, което трябваше да поправим, и знаехме, че можем да поправим по-голямата част от тях, преди да преобразуваме стиловете. Решихме да изчистим нашите по-малко файлове, преди да конвертираме.

Fixin ’Mixins

Започнахме с разликата между начина, по който Less и Sass се справят с условни условия. Ето един прост градиентен миксин, който имахме:

Сас предлага проста структура @ if ... @ else, докато нашият миксин използва това, което по-малко нарича a миксин пазач . В случая с нашия градиентен миксин, ние го използвахме за промяна от префиксирания от доставчика синтаксис на черновата към синтаксиса W3C. Знаехме, че ще трябва да пренапишем този миксин.

След това спряхме и разгледахме дълго всичките си комбинации. Повечето от тях добавиха префикси на доставчици и разрешиха разликите в браузъра като градиентния миксис по-горе. Въведете Автопрефиксър , инструмент, който анализира CSS и прилага префикси на доставчици въз основа на списък с поддържани браузъри. Чрез добавяне на Autoprefixer към нашата компилация, ние елиминирахме девет комбинации. Като бонус, Autoprefixer премахва ненужните префикси на доставчици, което ни помогна да идентифицираме някои прашни ъгли в нашия CSS и да създадем по-малки компилирани файлове.

Добър урок от нашия опит тук: Не губете време за преобразуване или рефакторинг на това, което можете да изтриете.

Друга разлика в комбинацията, която си струва да се отбележи: По-малко препоръчва разделянето на параметрите с точка и запетая . Само няколко бяха написани по този начин, но всички те трябваше да бъдат променени, в дефинициите на миксина и къде бяха приложени. За щастие, Less поддържа както запетаи, така и запетаи, така че бихме могли да направим тази промяна преди стъпката на преобразуване.

535 означава ангел

Амперсанд и злоупотреба

След като се обърнахме към миксините, насочихме вниманието си към друг източник на грешки при изграждането: амперсанди . Това е един от най-мощните оператори както в Sass, така и в Less и те работят много подобно. Освен когато не го правят. И тогава те работят съвсем различно.

Например с 19 000 селектори можете да си представите, че се сблъскваме със специфични проблеми, често бързо решавани като такива:

По-малко произвежда h1.modal-header, както някой би могъл да подозира, но Sass се задушава. Опитахме се да го поправим с:

Работи чудесно с Руби Сас, но към момента на писане, Libsass все още не поддържа тази употреба . Дори не сме обмисляли, в този случай, да преминем към Ruby Sass. Вместо това изписахме h1.modal-header извън обхвата на .modal. Знаем, че това е индикация за проблем, така че като извадим селектора извън обхвата и го извикаме с коментар, можем да идентифицираме тези проблеми в нашия код по-лесно.

Влоши се, когато амперсанд се използва по този начин в смес. Ето откъс от по-малко комбинация, която имахме за бутоните:

Отново директивата @ at-root не може да ни помогне в Libsass. В този случай трябваше да разгледаме първопричината за отмяна на спецификата и да я разрешим. (Добрата новина е, че го поправихме, като изтрихме три прекалено специфични стила другаде.)

Друга разлика между амперсандите Less и Sass всъщност беше полезна:

Нашето очакване беше .checkbox-wrap> .checkbox-widget, .radio-wrap> .radio-widget. Въпреки това, Less обработва амперсанда с повече рекурсия и се компилира по този начин:

В нито един момент не използвахме - или не бихме - използвали джаджа за отметка за радио бутон. За щастие, Sass всъщност реши проблем, за който не знаехме, защото не разглеждахме нашия компилиран CSS.

Извлечен урок: Поглеждайте често компилирания си CSS - в противен случай не знаете какво изтеглят вашите потребители.

Сравняване на резултатите

Актуализациите за коригиране и премахване на миксини, разрешаване на несъответствия и амперсанди и адресиране на някои други битове, които нямаше да се преобразуват чисто, се случиха в седем фиксации в рамките на един месец. Чувствах се добре да почистим къщата и да идентифицираме бъдещи възможности за рефакторинг.

И все пак няма значение как изглежда нашият изходен код; това е, което се доставя на нашите потребители. Обмислихме да генерираме AST за сравнение на нашия компилиран CSS. След известни изследвания и експерименти стана ясно, че всичко, от което се нуждаем, е начин да разберем дали много малко не се е променило в съставения CSS. Следователно, добрите старомодни разлики биха били достатъчни - колкото по-малка е разликата, толкова по-добре. Всяка заявка за изтегляне се доставяше с разликата в резултатите преди и след компилацията по-малко. Инструментът за разработчици на Xcode FileMerge беше много удобно за сравняване на резултатите един до друг. Ако видяхме нещо, което не очаквахме, се връщахме да разследваме.

Задържахме се с FileMerge и diffs, след като преминахме към нашето намиране и замяна на регулярни изрази и всъщност преобразувахме файловете в SCSS. Обаче резултатите, съставени от два различни препроцесора, направиха разликите ни безполезни поради разлики в табулирането и поставянето на скоби. Добавихме допълнителна стъпка за нормализиране на формата на CSS преди и след прост скрипт на възел . Той минимизира CSS, след което го разкрасява. Не може да бъде по-просто.

Нормализирането на форматирането помогна много, но преглеждането на разликата все пак отне около два солидни дни за преглед. Процес на възнаграждение, но труден. Съмняваме се, че персонализирано AST решение би помогнало за ускоряване на прегледа. Трябваше да се обърне внимание на всички различия.

Но разликите бяха незначителни. Селектори в малко по-различен ред, десетично закръгляване и дори леки разлики в резултатите от цветовите функции. Всяка разлика беше проверена внимателно, преди да вкараме нашия Sassed-up CSS в производството.

Какво следва

Веднъж обединени, текущата работа едва ли е спряла. По-малко файлове, които все още са в процес на разработка, бяха лесни за конвертиране, благодарение на цялата подготвителна работа, извършена преди време. Всички бяха готови за около два дни. Дори преработеният екип Compose успя за няколко часа да изрази пътя си към SCSS. Планирането напред и почистването на съществуващите стилове преди издърпване на превключвателя направиха всичко различно.

Сега продължаваме с идентифицирането на модели, разбиването на големи CSS файлове на модули, одитирането на CSS в производство за неизползвани селектори и отделянето на повече време за инструменти за сравняване на AST или друго анализирано представяне на нашия CSS. Споменах ли, че имаме близо 19 000 CSS селектори? Ние сме на него, но това е друга статия изцяло.

Споделете С Приятелите Си: