Вебпак повторяет логику работы стандарта ES Modules. Согласно этому стандарту, код модулей выполняется единожды вне зависимости от того, сколько раз они были импортированы.
Вебпаком и любым другим бандлером довольно легко выгрузить получившиеся стили. Мне кажется наоборот прикольно, что каждый инструмент делает свою конкретную задачу и передаёт результат дальше.
Я думаю, что настроить то же самое для Vite изи, так как цсс модули и тайпскрипт — это инструменты, не привязанные к бандлеру. Я использовал тут вебпак скорее для примера.
Я дед, мне с вебпаком удобно :) если вопрос про то, как настроить похожую инфраструктуру в Vite, то сходу я сказать не могу, так как не пользовался им ни разу.
Слои и специфичность — это два разных уровня каскада. Не понимаю, как их можно сравнивать. Слои позволяют декларативно один раз описать приоритет правил вместо бесконечной войны за бОльшую специфичность.
Не претендую на правоту, но способ, который предлагает Layer кажется гораздо более простым, чем определение приоритета на уровне специфичности.
Это норм решение, но мне кажется, что в долгосрочной перспективе такое повышение специфичности — дорога в ад. С каждым следующим витком будет сложнее вносить правки в стили.
Ну и я могу изи привести пример, в котором нет нарушения закона, о котором ты говоришь, но есть описанная проблема. Представь, что ты делаешь компонент заголовка и сбрасываешь ему браузерный margin до нуля. Его так же сложно будет перебить потом пользователям либы.
Я и согласен, и не согласен. С одной стороны ссылка как будто действительно не должна мимикрировать под кнопку, с другой — это настолько часто встречающийся паттерн почти во всех дизайн системах, что хош не хош приходится его реализовывать.
Кажется вы путаете транспиляцию с полифиллами. Попробуйте какой-нибудь модный Object.values использовать в своём примере. TS либо грохнется с ошибкой (за что ему кстати спасибо), либо оставит такой вызов без изменений.
А как ts решит проблему, которую решают полифиллы? Кажется, что это несвязанные вещи. TS помогает писать более стабильный код, но к кроссбразуерности он, кмк, отношения не имеет.
Если приложение большое, то да, полифиллы не так сильно бросаются в глаза. Однако зачастую они занимают процентов 20 от общего бандла. При том что современные браузеры могут в большинстве случаев обходиться без них.
А зачем останавливаться?) Я в одном из своих проектов до сих пор использую Redux, в другом – вообще ничего не юзаю, кроме state и props, потому что приложение маленькое. По-моему это классно, когда люди придумывают новые подходы, особенно если их идеи снабжены аргументацией.
Вебпак повторяет логику работы стандарта ES Modules. Согласно этому стандарту, код модулей выполняется единожды вне зависимости от того, сколько раз они были импортированы.
Кажется, я перестал понимать, какую задачу нужно решить)
Вебпаком и любым другим бандлером довольно легко выгрузить получившиеся стили. Мне кажется наоборот прикольно, что каждый инструмент делает свою конкретную задачу и передаёт результат дальше.
По существу есть что?)
А мы точно про один и тот же плагин говорим?
ttsc заработает, но бандлеру это не помешает собрать код с ошибкой.
Я думаю, что настроить то же самое для Vite изи, так как цсс модули и тайпскрипт — это инструменты, не привязанные к бандлеру. Я использовал тут вебпак скорее для примера.
Я дед, мне с вебпаком удобно :) если вопрос про то, как настроить похожую инфраструктуру в Vite, то сходу я сказать не могу, так как не пользовался им ни разу.
Упс, ты прав. Исправил.
Никогда не писал на Angular. Выглядит угарно! А во что в итоге этот код превращается? В первую очередь интересует CSS.
Затем, что допустим большинству нужен
margin, сброшенный до какого-то значения, а части пользователей требуется его переопределить.Твой
h1будет аффектить ваще все `<h1 />` на странице. На больших проектах с несколькими независимыми фронтендами такой ресет приводит к проблемам.Использую
!importantв самых патовых ситуациях и не считаю, что он подходит для решения проблемы, которую я описал.Скажу то же самое, что сказал пунктом ранее.
Слои и специфичность — это два разных уровня каскада. Не понимаю, как их можно сравнивать. Слои позволяют декларативно один раз описать приоритет правил вместо бесконечной войны за бОльшую специфичность.
Не претендую на правоту, но способ, который предлагает Layer кажется гораздо более простым, чем определение приоритета на уровне специфичности.
Это норм решение, но мне кажется, что в долгосрочной перспективе такое повышение специфичности — дорога в ад. С каждым следующим витком будет сложнее вносить правки в стили.
Ну и я могу изи привести пример, в котором нет нарушения закона, о котором ты говоришь, но есть описанная проблема. Представь, что ты делаешь компонент заголовка и сбрасываешь ему браузерный margin до нуля. Его так же сложно будет перебить потом пользователям либы.
Я и согласен, и не согласен. С одной стороны ссылка как будто действительно не должна мимикрировать под кнопку, с другой — это настолько часто встречающийся паттерн почти во всех дизайн системах, что хош не хош приходится его реализовывать.
Спасибо за фидбэк, внёс в статью ваше примечание о
compat-tableС версией corejs в конфиге preset-env не всё так однозначано. Кажется, что минор в конфиге ваще ни на что не влияет: https://github.com/babel/babel/blob/main/packages/babel-preset-env/src/index.ts#L207
Кажется вы путаете транспиляцию с полифиллами. Попробуйте какой-нибудь модный
Object.valuesиспользовать в своём примере. TS либо грохнется с ошибкой (за что ему кстати спасибо), либо оставит такой вызов без изменений.А как ts решит проблему, которую решают полифиллы? Кажется, что это несвязанные вещи. TS помогает писать более стабильный код, но к кроссбразуерности он, кмк, отношения не имеет.
Если приложение большое, то да, полифиллы не так сильно бросаются в глаза. Однако зачастую они занимают процентов 20 от общего бандла. При том что современные браузеры могут в большинстве случаев обходиться без них.