Какой вариант именования более правильный (БЭМ)?

Как возможно определить условную грань, когда элементы становятся достаточно сложными что бы выносить их в отдельные блоки? (даже если не планируется их переиспользовани где-либо ещё)

Корректно ли по БЭМу создавать классы для отступов?

Realetive, сейчас ещё пришел в голову вариант использования переменных, учитывая что мне нужен лишь отступ, т.е. создать какую-то переменную --categories-about-margin и просто использовать ее где нужен отступ, но подозреваю что это не особо бэмовское решение

Корректно ли по БЭМу создавать классы для отступов?

Realetive, спасибо ещё раз, отступ будет использоваться и на других сущностях тоже, так что вроде как всё понятно и в голове всё плюс - минус устаканилось. Всего вам наилучшего)

Корректно ли по БЭМу создавать классы для отступов?

Realetive, благодарю за уделённое время и объяснение всех моментов. И можно ещё завершающим аккордом, проверочный момент уточнить. Есть всё те же страницы .services и .industries. У них есть свои разные секции и в этих секциях есть title (.services-about__title, .services-summary__title и тд).
Если есть необходимость задать этому тайтлу одинаковые отступы (margin) на разных страницах, тогда правильным решением будет поступить вот так? :

<div class="services">
      <div class="services__about services-about categories-section">
        <div class="services-about__title categories-section__title">some title text</div>
      </div>
    </div>

.categories-section__title {
  margin-bottom: 20px;
}

Корректно ли по БЭМу создавать классы для отступов?

Realetive, изначально была идея миксовать классы что бы в итогу вышло следующее :

<div class="services categories">
  <div class="services__about categories__about"></div>
</div>

<div class="industries catgegories">
  <div class="industries__about categories__about"></div>
</div>

В этом примере добавляется миксом блок categories (общая, скажем так, тема для industries и services) и потом к внутренним элементами миксуется элемент categories__about. Но я счёл не особо удобным такую констркуцию ввиду постоянной необходимости прописывания этого микса.

Но сейчас, как понимаю, это вполне себе имеющий право на жизнь вариант, да?)

Корректно ли по БЭМу создавать классы для отступов?

Realetive, а какая альтернатива могла бы быть в случае отсутствия общего корневого класса у страниц? Или тогда всё равно необходимо присваивать какой-то класс для body и от него всё строить?

Корректно ли по БЭМу создавать классы для отступов?

Ближайший общий и для одной и для второй страницы родительский элемент это .main, но между .main и блоками .services / .industries идут разные прослойки в виде лейаутов. И если спустя некую вложенность в духе
.main - .layout-default - .layout-default__container - .services
появится блок .services__about.main__about то будет же не особо логично что элемент main__about используется уже внутри какого блока .services

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

Erl, на разных страницах разные отступы, разные размеры, не вижу тут ничего такого. И я как-то не вижу логики в именовании .card__page_long -> карточка для длинной страницы? А в варианте .card_page_page1 - карточка для страницы page1.

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

Erl, просто в ситуации когда у меня, к примеру будет 20 страниц, и на каждой из них нужен будет свой вариант .card. Тогда выходит что в файле со стилями для .card будет куча модификаторов в духе .card_page_page1, .card_page_page2 и тд?

Какой вариант именования более правильный по БЭМу?

Realetive, сейчас ещё повторно просматриваю ещё документацию Vue, и там есть такой пример наименования :

Из-за него у меня вероятно и не получается перестроиться на иной принцип. Т.е. тут тоже должно идти не SearchButtonClear, a ButtonSearchClear?

Какой вариант именования более правильный по БЭМу?

Realetive, в моей ситуации все карточки это полностью отличающиеся друг от друга компоненты. И к примеру, взять CircleCard. Если мне нужно сделать наследуясь от него, сделать тот же CircleCard, но с обводкой, то я бы его назвал CircleCardBordered. Или всё равно изначально необходимо начинать наименование по принципу CardCircle, а потом добавлять CardCircleBordered?

Где в проекте разместить папку для разных функций?

Александр, у меня сейчас и есть отдельный файлик в папке с миксинами, где сборище подобного рода функций. Хотелось бы их слегка разгруппировать и вопрос в том, как назвать папку для этих целей. services / utils / helpers?

Где в проекте разместить папку для разных функций?

Alex, у вас, или здесь на сайте?) Если на сайте уже подобное было не будет ссылочки, с радостью ознакомлюсь.

Где в проекте разместить папку для разных функций?

Александр, не мешает ничего, я её импортирую и вызываю. Вопрос в том, где "правильно" эту функцию в проекте расположить. т.к. она не относится конкретно к какой-то группе файлов, а может применяться в разных ситуациях.

Какой вариант именования более правильный по БЭМу?

То есть в ситуации, когда у меня нет базового компонента "карточки", то всё же логично оставить всё как есть? А если бы у меня все "карточки" наследовались от какого - то базового компонента Card, то тогда наименование типа "CardCircle" имело бы смысл, верно?

Как понять что нужно разделять компонент на новые компоненты (vue)?

Aetae, а к примеру, если есть ситуация : "мне нужно что бы кнопка выглядела как Button, но при нажатии на неё отправлялся запрос на сервер". Т.е. у меня есть дефолтный компонент Button и тут как я понимаю, 2 варианты развития пути :

- просто добавить функционал запроса на сервер к Button и через пропс в случае чего его активировать.
- либо создать компонент RequrestButton в котором будет вложен Button и при клике на него - будет идти запрос и получается если мне нужно использовать кнопку с отправкой запроса - просто юзать RequestButton.

Понимаю что в данном контексте вроде как проще подход с просто пропсами, но в каких ситуациях может быть более удобным вариант с подходом как в случае с созданием RequestButton?

Как понять что нужно разделять компонент на новые компоненты (vue)?

Kutuzov_ska, тут вы один момент упустили. В 1м варианте - порядок дивов : title - desc -image, во 2м варианте : desc - title -subtitle -image.

Т.е. мне либо строить такой компонент :

<div class="button">
  <template v-if="defaultOrder">
    <div class="button__title/>
    <div class="button__desc/>
    <div class="button__image/> 
  </template>

  <template v-else>
    <div class="button__title/>
    <div class="button__desc/>
    <div class="button__image/> 
  </template>
</div>

Либо строить 2 отдельных компонента

Как понять что нужно разделять компонент на новые компоненты (vue)?

Kutuzov_ska, а если к примеру мне в одной ситуации нужно что бы компонент выглядел так :

<div class="button">
    <div class="button__title/>
    <div class="button__desc/>
    <div class="button__image/> 
  </div>

А в другой ситуации я получал что-то вроде :

<div class="button">
    <div class="button__desc/>
    <div class="button__title/>
    <div class="button__subtitle/>
    <div class="button__image/> 
  </div>

То есть нужно много чего перестроить, отобразить сабтайтл и всякое такое.
Тут как бы вы сделали? В один компонент запихнули оба варианта кнопки и через пропс и v-if отображали какой-то из них? Или делали бы для каждой кнопки отдельный компонент?

Как загрузить в локальное хранилище и получить обратно?

Александра, локальное хранилище это localstorage вашего браузера, а для вашего варианта взаимодействия вероятно нужен локальный сервер по типу Open server. (дальше думаю при помощи гугла проблема решится)

Как уменьшить размер reactdom?

Антон Спирин, проблема была в использовании cheap-evap-source-map на проде, спасибо за терпение и помощь.