MB
это решается другими методами, такими как style-модули
Size: a a a
2017 September 07
MB
сохраняя одновременно и реюзабельности и изолированность
MB
так что ответ неправильный, сорри
l(
Но ведь тем не менее, задачу решает: прокидывает обычный CSS-стиль, не style-модуль, в компонент?
MB
нет, это решает другу задачу, а именно необходимость получить именно тот стиль, который определен в окружение, где компонент используется, а не те (и не микс), которые определены внутри него
MB
это очень специфичный юзкейс, который даже хаком то не назовешь, для меня это выглядит скорее как немного недодуманная спецификация
MB
немного сужу вопрос
MB
мы вставляет в slot другой веб-компонент, стили которого определены внутри него и по природе изолированы
нам нужно, чтобы хост этого вставляемого компонента получил стили из окружения Light DOM
при этом вставляем мы его динамически (согласно задаче)
нам нужно, чтобы хост этого вставляемого компонента получил стили из окружения Light DOM
при этом вставляем мы его динамически (согласно задаче)
MB
конечно можно сделать style-модуль, и вставлять его в шаблон компонента, а также в шаблон окружения, где он используется
но это сделает невозможность использования этого компонента нигде, кроме как в вышеуказанном контексте
а хочется большей переиспользуемости
но это сделает невозможность использования этого компонента нигде, кроме как в вышеуказанном контексте
а хочется большей переиспользуемости
MB
и кажется, что это не мы пытаемся хакнуть спеку, а в спеке не предусмотрено решения для поставленной проблемы
MB
я еще пересплю с этой мыслью денек, и если не найду более красивого решения, то может попробую зарепортить баг в спеку, что не хватает гибкости
кстати @chicoxyzzy будет интересно услышать у тебя как это происходит, прежде чем идти что-то делать
кстати @chicoxyzzy будет интересно услышать у тебя как это происходит, прежде чем идти что-то делать
MB
хотя вспоминая вопрос на заре создания чата
эта проблема блекнет на фоне невозможности вставлять одинаковый контент в более чем один слот... (без JS, имеется ввиду)
хотя обе проблемы имеют одинаковую природу, как мне кажется, и порождены и так чересчур сложной имплементацией слотов
эта проблема блекнет на фоне невозможности вставлять одинаковый контент в более чем один слот... (без JS, имеется ввиду)
хотя обе проблемы имеют одинаковую природу, как мне кажется, и порождены и так чересчур сложной имплементацией слотов
l(
> нам нужно, чтобы хост этого вставляемого компонента получил стили из окружения Light DOM
Разве я не это сказал?
Разве я не это сказал?
l(
Я в этих ваших вэб-компонентах мало понимаю, вы уж простите за тупку. 😇 Я без издевки.
MB
стили не прокидываются, а из твоего ответа это явно следовало
MB
ну и не было ответа, зачем это может быть надо
ответ в стили: изоляция стилей не решает всех проблем, это не только не ответ на поставленный вопрос, это еще и намек на то, что это плохая идея
ответ в стили: изоляция стилей не решает всех проблем, это не только не ответ на поставленный вопрос, это еще и намек на то, что это плохая идея
MB
а это вовсе не плохая идея, это чудесная идея, которая прекрасно решает проблемы неконтролируемо протекающих стилей, и имеет свои особенности, как то: иной подход к переиспользованию стилей, к которому просто нужно привыкнуть
l(
Под "прокидываются" я имел в виду "применяются".
Замечательная эта идея в теории, а когда сталкиваешься с тем, что не можешь перекрасить элемент из-за изоляции, и надо городить вот такие костыли, то становится грустно. Особенно если редактировать чужой компонент -- не вариант.
Замечательная эта идея в теории, а когда сталкиваешься с тем, что не можешь перекрасить элемент из-за изоляции, и надо городить вот такие костыли, то становится грустно. Особенно если редактировать чужой компонент -- не вариант.
l(
Кстати, на *всех* работах, где я был не единственный фронтендщик, я сталкивался с сопротивлением (иногда пассивным, иногда активным) необходимости нэймспэйсить HTML-классы в духе упрощенного БЭМ.
Когда я первый раз привожу аргумент про протечки стилей, обязательно получаю ответ, мол, до сих пор не протекало и никто не умер.
Когда я первый раз привожу аргумент про протечки стилей, обязательно получаю ответ, мол, до сих пор не протекало и никто не умер.
MB
я не вижу здесь никакой истины по середины
стили либо протекают, и ты рано или поздно (скорее рано) оказываешь в неконтролируемой ситуации
либо не протекают, и тогда ты создаешь API для кастомизации, что медленно для срочных задач, но в долгосрочной перспективе позволяет гарантировать стабильность
стили либо протекают, и ты рано или поздно (скорее рано) оказываешь в неконтролируемой ситуации
либо не протекают, и тогда ты создаешь API для кастомизации, что медленно для срочных задач, но в долгосрочной перспективе позволяет гарантировать стабильность