Pull to refresh

Comments 3

Такой способ стилизации не лишен недостатков. Предположим, в компоненте Dialog уже были стилизованы компоненты Button подобным образом:
.dialog :global(button) { /* ... например, имеют синий цвет */ }

Что преобразуется с помощью Svelte к виду:
.dialog.svelte-8d16lv button { /* ... */ }

И поскольку SubmitButton тоже находится внутри Dialog начнутся коллизии стилей:
.submit.svelte-138xsye button { /* ... */ }
.dialog.svelte-8d16lv button { /* ... */ }
Понимаю о чем вы волнуетесь, но то что вы описали — это принцип работы CSS и не имеет прямого отношения к Svelte. Конечно же каскадность никто не отменял. Но даже в вашем примере все будет работать как надо. Потому что стили из родительского компонента перекроют стили вложенного.

Иными словами, если некий компонент Dialog захочет красную SubmitButton, то не смотря на стилизацию внутри SubmitButton, Dialog сможет это сделать. При этом во всех иным местах использовния, SubmitButton останется зеленой.

Вот REPL. Как я и ожидаю, кнопка зеленая.

Кроме того, гибкость подхода позволяет вам писать CSS селекторы наиболее удобным для вас образом, чтобы максимально таргетировать стиль на элемент внутри вложенного компонента. Главное, что все это не «протекает» наружу наверх. То есть модицикация стилей идет сверху вниз, словно пропсы и только в рамках одной иерархии.
Изучил тему немного глубже. Действительно, могут возникал коллизии стилей, если пытаться перезаписать стили на несколько уровней ниже. А без использования более приоритетных CSS селекторов иногда не получается добиться нужного результата.

Отсюда делаю вывод, что лучше не увлекаться глубокими преобразованиями стилей и использовать максимальный CSS таргетинг, чтобы решить вопрос возможных коллизий.

В любом случае, стили не «протекают» за пределы компонента, поэтому любая коллизия будет иметь место только в рамках одной иерархии и спокойно можно использовать CSS для фиксации стилей на определенных элементах.
Sign up to leave a comment.

Articles