Хе-хе, реакт с хуками наконец-то и до мобилок добрался. Разве что реализация хуков здесь гораздо более правильная, из-за того что используется плагин для компилятора.
Ну в общем-то, тот подход можно переложить на vanilla-extract без особого труда. Я бы рассматривал его как высокоуровневый генератор CSS, который запускается в билдтайме и может быть связан с рантаймом. Рассматривайте его как любой препроцессор CSS, только вместо кастомного диалекта у вас тайпскрипт, а вместо плагинов — обычные функции, которые вы сами применяете по мере необходимости.
Как и CSS файлы, так что особой разницы не вижу. Понятно что те могут быть побыстрее, но с учётом того, что на экране редко бывает больше двух-трёх файлов — вообще неважно.
общий лоадер для ts-файлов, что приведет к деградации скорости сборки
Как раз вот нет, учитывая что vanilla-extract использует esbuild в фоне — эти стилевые файлы обрабатываются параллельно в отдельном лоадере, тут разницы с CSS особой нет.
Разве что полезную работу производит конкретно написанный вами код, а не дженерик компилятор, обходящий AST написанного вами кода. Разница в скорости пока не ясна (надо бы попроводить замеры), но, умозрительно, есть вероятность что так окажется даже побыстрее.
Sprinkles посмотрел — это переизобретенные mixins
Есть важное отличие — sprinkles это атомарный CSS, так что результирующие стили будут состоять, условно, из пары килобайт атомарных классов, при том что вёрстка от этого вообще никак не изменится. Как вам такая оптимизация на ровном месте?
не вижу ни одной неудобной строчки в таком варианте:
Я вижу, в основном, в том, что стили которые по замыслу должны работать вместе, в самом коде CSS никак не связаны. Надеюсь, важность инкапсуляции вы отрицать не будете? Условный BEM решает эту проблему через строгие правила именования, а тут она решается бесплатно, самым органичным (чистая функция) и наименее вербозным образом.
каким бы ни был лаконичным DSL, он максимум что сможет сделать — приблизиться к композиционному подходу с миксинами
Тут опять же есть крайне важное отличие — DSL того же sprinkles абсолютно типизирован, так что вам даже не нужно изучать константы и миксины, всё находится на кончиках пальцев — вернее, в окошке автодополнения редактора.
А бойлерплейт не особо и отличается от тех самых файлов с миксинами и константами, так что тут различия не вижу.
нетипизированные значения без подсказок от IDE и соответственно с большой вероятностью опечаток
Ну это уже наследственная болезнь CSS — да и то, проверять значения в билд-тайме (а при пущем желании и в компайл-тайме, с учетом template types в TS 4.1) — это дело нескольких дополнительных строк кода.
Просто те, кому всё понравилось, молча добавили в закладки и поставили звезду на гитхабе ;) И таковых в два раза больше чем комментов.
В остальном даже вступать в полемику не буду, если вы всё ещё уверены в том, что отсутствие статической типизации — это всегда благо, то тут даже говорить не о чем.
В целом это можно долго обсуждать, но хочу заметить что "маленькая фича" в виде более удобной композиции класснеймов, это только первый предвестник тех фич, которые можно сделать, в том числе и самому, без всякой расплаты в рантайме. Вопрос здесь только в том, как скоро эти отдельные маленькие удобства накопятся до состояния, когда нативный CSS станет просто целью для компиляции, как это уже произошло с HTML. Посмотрите на тот же sprinkles, который позволяет сделать DSL для стилей, заточенный под конкретно вашу дизайн-систему.
А по поводу производительности — это очень сложный вопрос. Лично мне кажется что используемая схема "убрали типы и запустили сразу в ноде" может оказаться быстрее препроцессоров традиционных диалектов.
Про оверхед по синтаксису же… Ну, если стремиться к сходству с обычным CSS, то безусловно оверхед будет. Если же делать на его основании DSL, то уже CSS будет выглядеть вербозным.
Вообще звучит как оправдание для Олега от мира тестировщиков :)
Пока нет, но в экстеншенах есть - https://github.com/tc39/proposal-decorators/blob/master/EXTENSIONS.md#parameter-decorators-and-annotations
Спасибо! Хорошо получилось
Может выложите на ютуб? В посте видео не отображается у меня
О, полноценный интерфейс для ботов это интересно, можно много всякого накрутить!
А лучше AsciiDoc
Хе-хе, реакт с хуками наконец-то и до мобилок добрался. Разве что реализация хуков здесь гораздо более правильная, из-за того что используется плагин для компилятора.
Ну и ещё оно полностью статическое, js нужен только для выбора классов. Zero-runtime!
Кстати, теперь в vanilla-extract есть вдохновленные stitches рецепты!
Ну и вехотка, конечно. Далеко даже не все местные про неё слышали (если что — это мочалка).
Пока вроде до этого не дошло, но в целом думаю возможно.
Ну не знаю как вы, а мне вполне нравится. Из преимуществ — максимальная гибкость, при этом никакой расплаты за неё в рантайме.
Ну в общем-то, тот подход можно переложить на vanilla-extract без особого труда. Я бы рассматривал его как высокоуровневый генератор CSS, который запускается в билдтайме и может быть связан с рантаймом. Рассматривайте его как любой препроцессор CSS, только вместо кастомного диалекта у вас тайпскрипт, а вместо плагинов — обычные функции, которые вы сами применяете по мере необходимости.
Про vanilla-extract недавно написал статейку: https://m.habr.com/ru/post/555984/
Как и CSS файлы, так что особой разницы не вижу. Понятно что те могут быть побыстрее, но с учётом того, что на экране редко бывает больше двух-трёх файлов — вообще неважно.
Как раз вот нет, учитывая что vanilla-extract использует esbuild в фоне — эти стилевые файлы обрабатываются параллельно в отдельном лоадере, тут разницы с CSS особой нет.
Разве что полезную работу производит конкретно написанный вами код, а не дженерик компилятор, обходящий AST написанного вами кода. Разница в скорости пока не ясна (надо бы попроводить замеры), но, умозрительно, есть вероятность что так окажется даже побыстрее.
Есть важное отличие — sprinkles это атомарный CSS, так что результирующие стили будут состоять, условно, из пары килобайт атомарных классов, при том что вёрстка от этого вообще никак не изменится. Как вам такая оптимизация на ровном месте?
Я вижу, в основном, в том, что стили которые по замыслу должны работать вместе, в самом коде CSS никак не связаны. Надеюсь, важность инкапсуляции вы отрицать не будете? Условный BEM решает эту проблему через строгие правила именования, а тут она решается бесплатно, самым органичным (чистая функция) и наименее вербозным образом.
Тут опять же есть крайне важное отличие — DSL того же sprinkles абсолютно типизирован, так что вам даже не нужно изучать константы и миксины, всё находится на кончиках пальцев — вернее, в окошке автодополнения редактора.
А бойлерплейт не особо и отличается от тех самых файлов с миксинами и константами, так что тут различия не вижу.
Ну это уже наследственная болезнь CSS — да и то, проверять значения в билд-тайме (а при пущем желании и в компайл-тайме, с учетом template types в TS 4.1) — это дело нескольких дополнительных строк кода.
Просто те, кому всё понравилось, молча добавили в закладки и поставили звезду на гитхабе ;) И таковых в два раза больше чем комментов.
В остальном даже вступать в полемику не буду, если вы всё ещё уверены в том, что отсутствие статической типизации — это всегда благо, то тут даже говорить не о чем.
В целом это можно долго обсуждать, но хочу заметить что "маленькая фича" в виде более удобной композиции класснеймов, это только первый предвестник тех фич, которые можно сделать, в том числе и самому, без всякой расплаты в рантайме. Вопрос здесь только в том, как скоро эти отдельные маленькие удобства накопятся до состояния, когда нативный CSS станет просто целью для компиляции, как это уже произошло с HTML. Посмотрите на тот же sprinkles, который позволяет сделать DSL для стилей, заточенный под конкретно вашу дизайн-систему.
А по поводу производительности — это очень сложный вопрос. Лично мне кажется что используемая схема "убрали типы и запустили сразу в ноде" может оказаться быстрее препроцессоров традиционных диалектов.
Про оверхед по синтаксису же… Ну, если стремиться к сходству с обычным CSS, то безусловно оверхед будет. Если же делать на его основании DSL, то уже CSS будет выглядеть вербозным.
Хороший пример, точно так же как и со строками селекторов, единицы измерения не более типизированы чем в самом CSS, так что улучшать есть ещё куда.
Ябпосмотрел!
Самый простой способ сказать что ты вписался.