КС
чтобы иметь изолированный компонент, нужно очень хорошо подумать, либо постоянно допиливать его едж кейсами
Size: a a a
2020 September 30
КС
т.е. выходит что думаешь о ерунде
PM
это норм варик если ты берешь чужой компонент и начинаешь его ситилизовать под себя, но опять же если тебе приходится делать это, значит компонент не дал апи для стилизации и ты опять же должен чувтсвовать что делаешь это на свой страх и риск
КС
вместо задачи
КС
ясно
PM
Кирилл Спасибович
чтобы иметь изолированный компонент, нужно очень хорошо подумать, либо постоянно допиливать его едж кейсами
это не эйдж-кейсы, это просто кейсы твоего конкретного компонента. желание писать супер-универсальные компоненты всегда заканчивается их переусложнением и в тоже время не приводит к желаемому результату, потому что невозможно предугадать все
PM
Кирилл Спасибович
меньше всего неприятных ощущений от global
остальное просто неприятно, ощущается костыльно
остальное просто неприятно, ощущается костыльно
раз это выгядит костыльно и у тебя есть патч на className, то можешь тогда ты решить мой пример?
PM
убрать закругления и выставить margin для 2-х кнопочного режима этого компонента
PM
мысленно накатываем твой патч и делаем
МТ
Какой в среднем оптимальный максимум вариантов одного и того же компонента?
МТ
Например кнопки
PM
Марк Танащук
Какой в среднем оптимальный максимум вариантов одного и того же компонента?
зависит от того, какой код/стили общие
PM
если 2 варианта кноки имеют 80% разных стилей и столько же разной логики/поведения, то очевидно лучше немного копипасты и разнести их на 2 компонента
PM
все равно практика показывает, что такие компоненты продолжают "расходится" в стороны, а поддержание унификации заставляет описывать все более хитрые комбинации, чтобы заставить их работать внутри одной изолированной частицы
AP
это не эйдж-кейсы, это просто кейсы твоего конкретного компонента. желание писать супер-универсальные компоненты всегда заканчивается их переусложнением и в тоже время не приводит к желаемому результату, потому что невозможно предугадать все
в защиту класснейма передаваемого сверху я могу только представить знания уважаемых предков https://ru.bem.info/methodology/css/#%D0%B2%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F-%D0%B3%D0%B5%D0%BE%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%8F-%D0%B8-%D0%BF%D0%BE%D0%B7%D0%B8%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
которые до сих пор ничему не противоречат, хоть бэм-нейминг хоть цсс модуль нейминг
которые до сих пор ничему не противоречат, хоть бэм-нейминг хоть цсс модуль нейминг
PM
в защиту класснейма передаваемого сверху я могу только представить знания уважаемых предков https://ru.bem.info/methodology/css/#%D0%B2%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F-%D0%B3%D0%B5%D0%BE%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%8F-%D0%B8-%D0%BF%D0%BE%D0%B7%D0%B8%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
которые до сих пор ничему не противоречат, хоть бэм-нейминг хоть цсс модуль нейминг
которые до сих пор ничему не противоречат, хоть бэм-нейминг хоть цсс модуль нейминг
Дык все верно: В данном примере внешняя геометрия и позиционирование блока
button задана через элемент header__button. Блок button не специфицирует никакие отступы и может быть легко переиспользован в любом месте.PM
В данном примере button - это чайлд и header__button это родитель
PM
Принцип остаётся же неизменным, просто цсс не так назначается
PM
В контексте БЭМ компоненты это классы, в контексте свелт это SFC