DK
Одно и то же.
Size: a a a
2020 October 02
/
Понял
DK
Про импорт важное замечание.
Каждый style-тег в компоненте компилируется отдельно от остальных, а не так, как в обычном Sass, пачкой.
Поэтому советую сделать отдельный файл, типа _importable.scss, в который импортировать все переменные, миксины, хелперы и прочее, что не генерирует CSS. Его использовать в компонентах, если надо.
Еще у свелта что-то так себе местами с удалением неиспользуемых селекторов, потому что сделать ui-компонент для бульмы у меня не вышло (делал меню, делал дропдаун — свелт говорил про кучу неиспользуемых стилей, выпиливал их и ломал дизайн), так что от отдельной папки с глобальными стилями отказаться всё равно не выйдет.
Каждый style-тег в компоненте компилируется отдельно от остальных, а не так, как в обычном Sass, пачкой.
Поэтому советую сделать отдельный файл, типа _importable.scss, в который импортировать все переменные, миксины, хелперы и прочее, что не генерирует CSS. Его использовать в компонентах, если надо.
Еще у свелта что-то так себе местами с удалением неиспользуемых селекторов, потому что сделать ui-компонент для бульмы у меня не вышло (делал меню, делал дропдаун — свелт говорил про кучу неиспользуемых стилей, выпиливал их и ломал дизайн), так что от отдельной папки с глобальными стилями отказаться всё равно не выйдет.
КС
Одно и то же.
КС
Ну там наверное классы хотелось передать хэшированные в компонент ?
/
Про импорт важное замечание.
Каждый style-тег в компоненте компилируется отдельно от остальных, а не так, как в обычном Sass, пачкой.
Поэтому советую сделать отдельный файл, типа _importable.scss, в который импортировать все переменные, миксины, хелперы и прочее, что не генерирует CSS. Его использовать в компонентах, если надо.
Еще у свелта что-то так себе местами с удалением неиспользуемых селекторов, потому что сделать ui-компонент для бульмы у меня не вышло (делал меню, делал дропдаун — свелт говорил про кучу неиспользуемых стилей, выпиливал их и ломал дизайн), так что от отдельной папки с глобальными стилями отказаться всё равно не выйдет.
Каждый style-тег в компоненте компилируется отдельно от остальных, а не так, как в обычном Sass, пачкой.
Поэтому советую сделать отдельный файл, типа _importable.scss, в который импортировать все переменные, миксины, хелперы и прочее, что не генерирует CSS. Его использовать в компонентах, если надо.
Еще у свелта что-то так себе местами с удалением неиспользуемых селекторов, потому что сделать ui-компонент для бульмы у меня не вышло (делал меню, делал дропдаун — свелт говорил про кучу неиспользуемых стилей, выпиливал их и ломал дизайн), так что от отдельной папки с глобальными стилями отказаться всё равно не выйдет.
Я именно по этому и спрашиваю
Сейчас то, что работает, безбожно плюется варнингами
Сейчас то, что работает, безбожно плюется варнингами
КС
Какими ?
/
Кирилл Спасибович
Какими ?
Неиспользуемые селекторы
/
И их ваще миллион
DK
Кирилл Спасибович
Пока нет инлайн-шаблонов, я адаптирую задачу под возможности фреймворка.
Если ситуация не искусственная, а вот прямо настоящая, я бы переписал, чтобы лейбл жил около селекта и атрибуцировался через рандомный id, а не вмещал в себя селект.
Выделять такое в отдельный компонент горестно.
Хотя когда-нибудь неизбежно появится требование делать labeled choices (просто массив значений, а не массив словарей), может поддержку option group, тогда этот итератор над опциями в отдельном компоненте уже не покажется такой плохой затеей.
Если ситуация не искусственная, а вот прямо настоящая, я бы переписал, чтобы лейбл жил около селекта и атрибуцировался через рандомный id, а не вмещал в себя селект.
Выделять такое в отдельный компонент горестно.
Хотя когда-нибудь неизбежно появится требование делать labeled choices (просто массив значений, а не массив словарей), может поддержку option group, тогда этот итератор над опциями в отдельном компоненте уже не покажется такой плохой затеей.
КС
Пока нет инлайн-шаблонов, я адаптирую задачу под возможности фреймворка.
Если ситуация не искусственная, а вот прямо настоящая, я бы переписал, чтобы лейбл жил около селекта и атрибуцировался через рандомный id, а не вмещал в себя селект.
Выделять такое в отдельный компонент горестно.
Хотя когда-нибудь неизбежно появится требование делать labeled choices (просто массив значений, а не массив словарей), может поддержку option group, тогда этот итератор над опциями в отдельном компоненте уже не покажется такой плохой затеей.
Если ситуация не искусственная, а вот прямо настоящая, я бы переписал, чтобы лейбл жил около селекта и атрибуцировался через рандомный id, а не вмещал в себя селект.
Выделять такое в отдельный компонент горестно.
Хотя когда-нибудь неизбежно появится требование делать labeled choices (просто массив значений, а не массив словарей), может поддержку option group, тогда этот итератор над опциями в отдельном компоненте уже не покажется такой плохой затеей.
А другие компоненты ниже ?
КС
Я размышлял о переходе на теги по максимуму, кнопки, инпуты и тд
КС
И использование глобальных стилей от рут компонента для тегов батон инпут и тд
КС
Т.к. неудобно навешивать классы для кастомизации расположеня (глобал, врап в дивы, пропсы - мэээ)
DK
Кирилл Спасибович
А другие компоненты ниже ?
Пример с ипутом — та же история. Я б положил лейбл около инпута, а не оборачивал его вовнутрь, тогда дублирования было бы меньше сильно, был бы просто один иф.
КС
Но если использовать теги то неудобно абстрагировать стили, либо в каждом компоненте их писать виджета, либо глобал
КС
Пример с ипутом — та же история. Я б положил лейбл около инпута, а не оборачивал его вовнутрь, тогда дублирования было бы меньше сильно, был бы просто один иф.
А чем это лучше врапа лейблом ?
DK
Кирилл Спасибович
А чем это лучше врапа лейблом ?
Кроме дублирования — ничем.
КС
Кроме дублирования — ничем.
Получается весь смысл оборачивания инпута в компонент это спрятать стили и логику генерирующую id ?
AP
Пока нет инлайн-шаблонов, я адаптирую задачу под возможности фреймворка.
Если ситуация не искусственная, а вот прямо настоящая, я бы переписал, чтобы лейбл жил около селекта и атрибуцировался через рандомный id, а не вмещал в себя селект.
Выделять такое в отдельный компонент горестно.
Хотя когда-нибудь неизбежно появится требование делать labeled choices (просто массив значений, а не массив словарей), может поддержку option group, тогда этот итератор над опциями в отдельном компоненте уже не покажется такой плохой затеей.
Если ситуация не искусственная, а вот прямо настоящая, я бы переписал, чтобы лейбл жил около селекта и атрибуцировался через рандомный id, а не вмещал в себя селект.
Выделять такое в отдельный компонент горестно.
Хотя когда-нибудь неизбежно появится требование делать labeled choices (просто массив значений, а не массив словарей), может поддержку option group, тогда этот итератор над опциями в отдельном компоненте уже не покажется такой плохой затеей.
рандом может быть плох для SSR и гидрации