Nasze doświadczenie w przechodzeniu z Less na Sass

Wiele napisano o przechodzeniu ze zwykłego CSS na preprocesor CSS i nie bez powodu - preprocesory dodają mocy i kontroli, których nie możemy uzyskać w samej przeglądarce. Z artykułów, które wychwalaj zalety preprocesora do bardziej technicznych lektur, takich jak szczegółowe informacje Etsy „ Przejście do SCSS at Scale , ”Czuję, że pożarłam je wszystkie.

W HASHTAGI , zrobiliśmy coś, o czym nie pisano prawie tak dużo - przejście z jednego preprocesora na inny. Wcześnie przyjęła Sprout Mniej ; podjęliśmy decyzję pod koniec zeszłego roku, aby przejść na SCSS, składnię podobną do CSS Sass . Nie spieszyliśmy się, aby zapewnić płynne przejście, a doświadczenie uwydatniło pewne głębokie różnice między Less i Sass.

Dlaczego?

Zanim przejdziemy do tego, czego się dowiedzieliśmy, twoje pierwsze pytanie - uzasadnione - powinno brzmieć: „Po co się przejmować?” Skorzystaliśmy już ze zmiennych i mixinów, @importów i funkcji koloru. Z pewnością Sass ma wiele funkcji, których mniej brakuje, takich jak mapy i Funkcje , ale bez nich dotarliśmy tak daleko.

Wyróżniają się dwa główne powody zmiany:

Społeczność: Wyszukaj na github rozszerzenie lib: scss, a następnie wyszukaj rozszerzenie lib: less. W chwili pisania tego tekstu wyniki są jasne: 120 234 plików SCSS, 29 449 mniej plików. Zmiana zapewnia dostęp do szerszego wachlarza dobrych pomysłów i większego puli open source do pływania. Ogłosiła nawet popularna biblioteka Bootstrap, jeden z powodów, dla których Less pozostał opłacalny przełącza się na SCSS .
Prędkość: Libsass skały. Czas budowy naszych stylów poprawił się o ponad 500%. Chociaż Libsass nie dogonił jeszcze najnowszej wersji specyfikacji Sass, nie czujemy, że niczego nam brakuje.

W jaki sposób?

Nasz skompilowany CSS ma prawie 19 000 selektorów. Po zmianie ten skompilowany CSS musiał być prawie identyczny; musieliśmy upewnić się, że to przejście było niewidoczne dla naszych klientów. A co z funkcjami, które są obecnie w toku? Nasz ostatnia aktualizacja tworzenia wiadomości zmienił 3837 linii stylów - jak ten zespół mógł bezpiecznie zmienić środek strumienia?

Rozważaliśmy trzy opcje:

Najpierw skompiluj wszystko do CSS. To jedyny sposób, aby ze stuprocentową dokładnością upewnić się, że nasi użytkownicy uzyskują te same style, i faktycznie przestawić się na zmianę w ciągu jednego dnia. Pomysł na czystą przerwę jest zawsze kuszący, ale nowy kod nie zawsze jest lepszym kodem . Nawet przy użyciu narzędzi takich jak sass-convert i css2compass czas, jaki spędzilibyśmy na odbudowie, znacznie przewyższałby wszelkie inne opcje.
Pisz tylko nowe style w SCSS. Rozważaliśmy narysowanie linii na piasku… Mniej jest stare i zniszczone; Sass to nowa atrakcyjność . Ostatecznie odrzuciliśmy ten pogląd. Tak wiele można by zyskać na natychmiastowej zmianie, a nikt nie chciał zachować parytetu między dwoma zestawami mikserów i zmiennych.
Konwertuj wszystkie nasze pliki Less do SCSS i napraw błędy. W obliczu wyrzucenia historii lub dodania kolejnego zadania kompilacji do utrzymania, przystąpiliśmy do konwersji wszystkiego.

Czyścić dom

SCSS nie różni się zbytnio od Less, prawda? „ Konwersja z Less do Sass ”Udostępnia serię wyszukiwań wyrażeń regularnych, aby zmienić najbardziej oczywiste różnice w składni, takie jak .awesome-mixin () vs @mixin awesome-mixin (). Te wyszukiwania wyrażeń regularnych są zebrane w less2sass , które przejrzeliśmy przez wszystkie nasze pliki.

Gdyby to było takie proste, naprawdę nie byłoby o czym pisać. Kilka przeciągających się żądań ściągnięcia do skryptu less2sass podkreśla niektóre z jego przeoczeń, na przykład różnice w interpolacji ciągów . Bardziej wymagające były błędy kompilacji, które napotkaliśmy po konwersji, które wskazywały na różnice większe niż proste wyrażenie regularne. Szczerze mówiąc, znaleźliśmy również zły CSS.

Wzięliśmy te błędy kompilacji i sporządziliśmy listę tego, co musimy naprawić, i wiedzieliśmy, że większość z nich możemy naprawić przed konwersją stylów. Zdecydowaliśmy się wyczyścić nasze pliki Less przed konwersją.

Fixin ’Mixins

Zaczęliśmy od różnicy między tym, jak Less i Sass radzą sobie z warunkami warunkowymi. Oto prosta mieszanka gradientowa, którą mieliśmy:

Sass oferuje prostą strukturę @ if… @ else, podczas gdy nasz mixin wykorzystuje to, co Less nazywa a strażnik mieszania . W przypadku naszego miksu gradientowego używaliśmy go do zmiany składni roboczej z prefiksem dostawcy na składnię W3C. Wiedzieliśmy, że będziemy musieli przepisać ten mixin.

Następnie zatrzymaliśmy się i przyjrzeliśmy się wszystkim naszym miksom. Większość z nich dodała przedrostki dostawców i rozwiązała różnice między przeglądarkami, takie jak powyższy gradient mieszania. Wchodzić Autoprefixer , narzędzie, które analizuje CSS i stosuje prefiksy dostawców na podstawie listy obsługiwanych przeglądarek. Dodając Autoprefixer do naszej kompilacji, wyeliminowaliśmy dziewięć miksów. Jako bonus, Autoprefixer usuwa niepotrzebne prefiksy dostawców, co pomogło nam zidentyfikować zakurzone zakamarki w naszym CSS i stworzyć mniejsze skompilowane pliki.

Dobra lekcja z naszego doświadczenia: nie trać czasu na konwersję lub refaktoryzację tego, co można usunąć.

Kolejna różnica w mieszaniu, na którą warto zwrócić uwagę: Less zaleca oddzielanie parametrów średnikami . Tylko kilka zostało napisanych w ten sposób, ale wszystkie musiały zostać zmienione, w definicjach mixin i miejscu ich zastosowania. Na szczęście Less obsługuje zarówno średniki, jak i przecinki, więc mogliśmy wprowadzić tę zmianę przed krokiem konwersji.

biblijne znaczenie 69

Ampersand Abuse

Po rozwiązaniu problemu mixinów zwróciliśmy uwagę na inne źródło błędów kompilacji: ampersands . Jest to jeden z najpotężniejszych operatorów zarówno w Sass, jak i Less, i działają bardzo podobnie. Z wyjątkiem sytuacji, gdy tego nie robią. A potem działają zupełnie inaczej.

Na przykład, mając 19 000 selektorów, możesz sobie wyobrazić, że napotykamy problemy ze specyfiką, często szybko rozwiązywane jako takie:

Less produkuje nagłówek h1.modal, jak można by podejrzewać, ale Sass się dławi. Próbowaliśmy to naprawić za pomocą:

Świetnie współpracuje z Ruby Sass, ale w chwili pisania tego tekstu Libsass nie obsługuje jeszcze tego zastosowania . W tym przypadku nawet nie rozważaliśmy przejścia na Ruby Sass. Zamiast tego wypisaliśmy nagłówek h1.modal poza zakresem .modal. Wiemy, że jest to wskazanie problemu, więc wyciągając selektor z zakresu i wywołując go z komentarzem, możemy łatwiej zidentyfikować te problemy w naszym kodzie.

Sytuacja pogorszyła się, gdy znak „&” został użyty w ten sposób w miksie. Oto fragment mniejszego mixinu, który mieliśmy dla przycisków:

Ponownie, dyrektywa @ at-root nie mogła nam pomóc w Libsass. W tym przypadku musieliśmy przyjrzeć się głównej przyczynie zastąpienia specyficzności i rozwiązać ją. (Dobra wiadomość jest taka, że naprawiliśmy ten problem, usuwając trzy zbyt specyficzne style w innych miejscach).

Inna różnica między znakami ampersandów Less i Sass była w rzeczywistości pomocna:

Nasze oczekiwanie brzmiało: .checkbox-wrap> .checkbox-widget, .radio-wrap> .radio-widget. Jednak Less przetwarza ampersand z większą rekurencją i skompilowany w ten sposób:

W żadnym momencie nie użyliśmy - lub nie chcielibyśmy - użyć widżetu pola wyboru jako przycisku opcji. Na szczęście Sass faktycznie rozwiązał problem, o którym nie wiedzieliśmy, ponieważ nie patrzyliśmy na nasz skompilowany CSS.

Wyciągnięta lekcja: często przeglądaj skompilowany kod CSS - w przeciwnym razie nie wiesz, co pobierają użytkownicy.

Porównanie wyników

Aktualizacje naprawiające i usuwające mieszanki, rozwiązujące rozbieżności ze znakami ampersand i zajmujące się niektórymi innymi bitami, które nie miały zamiaru konwertować, miały miejsce w ciągu siedmiu zatwierdzeń w ciągu miesiąca. Dobrze było posprzątać dom i zidentyfikować przyszłe możliwości refaktoryzacji.

Jednak nie ma znaczenia, jak wygląda nasz kod źródłowy; liczy się to, co jest dostarczane naszym użytkownikom. Rozważaliśmy generowanie AST aby porównać nasz skompilowany CSS. Po kilku badaniach i eksperymentach stało się jasne, że potrzebowaliśmy tylko sposobu, aby dowiedzieć się, czy niewiele się zmieniło w skompilowanym CSS. Dlatego wystarczyłyby dobre, staromodne różnice - im mniejszy, tym lepiej. Każde żądanie ściągnięcia zawierało różnicę wyników kompilacji Less przed i po. Narzędzie programistyczne Xcode FileMerge było bardzo przydatne do porównywania wyników obok siebie. Jeśli zobaczyliśmy coś, czego się nie spodziewaliśmy, wróciliśmy, by to zbadać.

Utknęliśmy z FileMerge i diffami, gdy przeszliśmy do naszego wyrażenia regularnego „znajdź i zamień” i faktycznie przekonwertowaliśmy pliki na SCSS. Jednak wyniki skompilowane przez dwa różne preprocesory sprawiły, że nasze różnice stały się bezużyteczne z powodu różnic w umieszczaniu tabulatorów i nawiasów. Dodaliśmy dodatkowy krok, aby znormalizować format CSS przed i po prosty skrypt węzła . Minimalizuje CSS, a następnie upiększa go. Nie mogło być prostsze.

Normalizacja formatowania bardzo pomogła, ale przeglądanie różnic nadal trwało około dwóch dni. Proces satysfakcjonujący, ale żmudny. Wątpimy, czy niestandardowe rozwiązanie AST pomogłoby przyspieszyć przegląd. Należało odnieść się do wszystkich różnic.

Ale różnice były niewielkie. Selektory w nieco innej kolejności, zaokrąglenia dziesiętne, a nawet niewielkie różnice w wynikach funkcji koloru. Każda różnica została dokładnie sprawdzona przed wprowadzeniem naszego Sassed-up CSS do produkcji.

Co dalej

Po połączeniu trwające prace prawie nie utknęły w martwym punkcie. Mniej plików, które wciąż były w fazie rozwoju, można było łatwo przekonwertować dzięki całej pracy przygotowawczej wykonanej wcześniej. Wszyscy byli gotowi do pracy w około dwa dni. Nawet przeprojektowany zespół Compose był w stanie przekształcić swoją drogę do SCSS w ciągu kilku godzin. Planowanie z wyprzedzeniem i czyszczenie istniejących stylów przed naciśnięciem przełącznika miało ogromne znaczenie.

Teraz przechodzimy do identyfikacji wzorców, dzielenia dużych plików CSS na moduły, kontroli CSS w środowisku produkcyjnym pod kątem nieużywanych selektorów i spędzamy więcej czasu na narzędziach do porównywania AST lub innych przeanalizowanych reprezentacji naszego CSS. Czy wspomniałem, że mamy prawie 19 000 selektorów CSS? Już nad tym pracujemy - ale to zupełnie inny artykuł.

Podziel Się Z Przyjaciółmi: