Как передать computed data в дочерний template по клику?

Андрей Хохлов,
Я понял вашу мысль, но видимо моя реализация хромает

applyFilters() {
      this.visibleHotels = this.hotels.filter((h) => {
        if (this.selected_types == null || !this.selected_types.length) {
          this.selected_types.includes(h.type)
        }
        if (
          this.selected_countries == null ||
          !this.selected_countries.length
        ) {
          this.selected_countries.includes(h.country)
        }
        if (!this.reviews_amount) {
          this.reviews_amount <= h.reviews_amount
        }
        if (!this.checked_stars.length) {
          this.checked_stars.includes(h.stars.toString())
        }
        if (!this.price_range.length) {
          this.price_range[0] <= h.min_price &&
            this.price_range[1] >= h.min_price
        }
      })
    },

Как передать computed data в дочерний template по клику?

Не совсем понял, если честно. Мой опыт пользования vue примерно 10 часов, нужно что-то более наглядное)

Когда использовать микс, а когда модификатор?

Ох вы очень глубоко копнули, благодарю)
Я и сам за эти дни еще раз пробежался по форуму и доке бэм и удостоверился, что стилизация элементов каскадом от модификатора блока не плохая практика в общем.
А те блоки что я создавал, по типу header-nav это так называемые приватные(служебные) и лучше бы их сильно не плодить.

Единственное, я не совсем понял, зачем элементы .contacts называть по разному, если у них одинаковые стили по сути. И все таки как лучше стилизовать их в разных местах использования. Если у элементов .contacts, допустим, разный размер шрифта в футере и хедере, то это будет

.contacts_view_header .contacts__tel {}

или
.contacts__tel_view_header {}

или даже
.contacts__tel_size_small

или вообще сделать блок .text с модификаторами text_size_small, text_size_large и т.д. и миксовать где нужно.

А если у них и размера иконок и цвет текста и размер текста и отступы текста от иконок различаются, то это все будут отдельные модификаторы? Как я понял из документации, вполне обоснованно в таком случае будет сделать

.contacts_view_header {
    .contacts__icon {}
    .contacts__text {}
}

Когда использовать микс, а когда модификатор?

Виталий,
Спасибо, стало яснее.

Когда использовать микс, а когда модификатор?

Виталий,
Спасибо за развернутый ответ.
И тогда, чтобы у меня окончательно в голове все устаканилось.
Самые адекватные и надежные способы модификации блока и его элементов в зависимости от контекста в котором он находится:
1) Микс класса блока-родителя и затем конструкции вида header__contacts-item
2) Создание модификаторов для каждого элемента в отдельности
Правильно я понимаю?
Можете пожалуйста дать свое видение best practice так сказать.

Когда использовать микс, а когда модификатор?

Виталий,
Ну понятное дело, что в хэдере у меня header-contacts, а в футере footer-contacts был бы.
Хотя насколько я понял про миксы, у них нет вообще никаких ограничений. Т.е. мы вполне можем миксовать блок и элемент другого блока или элементы блоков как угодно и в каком угодно контексте, судя по этой презентации https://www.slideshare.net/yandex/ss-14895358

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

И что скажете по второму кейсу?

Когда использовать микс, а когда модификатор?

Вот так я и делал обычно, как вы предлагаете header__contacts-img
В вопросе привел пример с созданием header-contacts и уже от него header-contacts__img, но по сути это одно и то же, что и header__contacts-img
Собственно поэтому и полез писать стены текста, потому что мне такая реализация кажется кривой и некрасивой.
В то время, как простой модификатор contacts--theme--header, четко дает понять почему данный блок и его элементы стилизованы именно так, а не иначе. Более того, можно дать более абстрактное имя модификатору, типа contacts--theme--light и тогда мы отвязываемся от контекста в принципе.
А каскад по сути инкапсулирован в самом блоке и никому не мешает.

Когда использовать микс, а когда модификатор?

Я читал доку бэм и различные статьи очень много раз, начинает казаться, что схожу с ума от нее)
Я понимаю, что это очень абстрактное наименование модификатора. Но в этом же и смысл. Мы же благодаря им переопределим много стилей у блока и его элементов. Или вы предлагаете писать по модификатору на каждый стиль, по типу card--margin---large, card--text-size--small и т.д? Тогда уже можно и для каждого элемента модификатор придумывать, как я и упомянул в пункте 2) первого кейса, но зачем их столько, если реализация будет только в одном месте.

Когда использовать микс, а когда модификатор?

Steppp,
Почему? И как тогда делается?
Мне кажется вполне адекватным. Мы не привязываемся ни к чему. А различить .card--type--1 и .card--type--2 и т.д. элементарно просто взглянув на них. Это максимально обособленная реализация.
В тоже время если мы будем миксовать .portfolio-card, то как потом будет обосновано использование карточки с этими же стилями, но в другом контексте. Т.е. будет страница с секцией

.models
    .card.portfolio-card
    .card__img.portfolio-card__img

или если стилизовать каскадом от микса portfolio__card

.models
    .card.portfolio__card
    .card__img

Вызывает путаницу, как по мне.

Когда использовать микс, а когда модификатор?

Realetive,
Вопрос больше абстрактный. Но вот например. Блок .contacts в футере, хэдере и на странице контактов немного отличается. Где-то одна ссылка выделена жирным. Иконки немного разного размера. Где-то в столбик, а где-то в строку. То как я сейчас реализовал, через микс пустого класса мне не очень нравится.
panthera-auto.demo.mnogoslov.com
panthera-auto.demo.mnogoslov.com/contacts.html

Та же самая проблема и в меню футера и хедера