Alex

надо что бы противник не идеально отбивал мяч

Afafks123132132165, Ну так просто добавьте ему некоторое отклонение. Рассчитываете идеальную позицию, в которую должен встать бот, и добавляете к ней случайное значение в указанном диапазоне, скажем [-0.2; +0.2].

Данные в sessionStorage хранятся как строки.
https://learn.javascript.ru/type-conversions

https://www.hostinger.com.ua/rukovodstva/kak-ispra...

1. Погуглить про CMS
   
2. Почитать как она работает
   
3. Поискать по имени файла
   
4. Использовать VCS
   

А выбирает цвет кто? Компонент parent? Или кто-то выше?
Если второй случай, тогда, полагаю, пропсы в любом виде, или inject.

Иначе, такой вопрос: Текст может быть только красным? Или существует вероятность что понадобится другой цвет? Если второй вариант, тогда, полагаю, кастомное свойство будет уместно:

<template>
<div class="parent">
  <Child1 class="child1">
    <Child2 class="child2" :style="'--text-color: ' + textColor">
    </Child2>
  </Child1>
</div>
</template>

Иначе, просто добавляйте класс, так как вам удобно исходя из конкретного случая.

P.S. С БЭМ не работал, поэтому рекомендации могут не соотносится с данной методологией.

https://ru.vuejs.org/v2/guide/unit-testing.html — Модульные тексты. С примерами для отдельных компонентов. Ваши всьюхи — по своей сути те же компоненты.
Если вам нужно протестировать "всю страницу" — тогда ищите инструменты и примеры для e2e тестирования

Если вы создаёте собственный цикл для вывода, то и параметры пагинации должны передавать самостоятельно.
https://wp-kama.ru/function/wp_query#pagination

https://wp-kama.ru/hook/login_errors
https://wordpress.org/support/topic/how-can-i-chan...

Используйте условные теги внутри фильтра и проверяйте любые свойства. В данном случае — принадлежит ли текущий пост к указанным категориям:

add_filter('excerpt_length', function(){
	
	// Для постов с рубрикой 1
	if (in_category(1)) {
		return 100;
	} 

	// Для постов с рубрикой 2
	if (in_category(2)) {
		return 50;
	}
	
	// Значение по умолчанию
	return 25;
});

Вот пара варинатов:

1. Использовать сторонний вииджет комментариев. Таким, обычно, плевать что за страница, важен только уникальный URL.
   
2. Создать статическую страницу, оформить для неё шаблон как для рубрики. Включить на ней комментарии.
   

Обычно, правильная постановка вопроса такая:

1. Что я делаю?
   
2. Какая аудитория?
   
3. Какие браузеры использует аудитория?
   
4. Какие технологии поддерживаются в этих браузерах?
   

Поймите, всё подобные вопросы индивидуальны для каждой задачи.

Пишу проект для портфолио

Ок. Что вы хотите продемонстрировать потенциальному работодателю? Каике навыки? Вы хотите продемонстрировать знание технологий? Тогда используйте pattern. Покажите что вы знаете о его существовании и умеете с ним работать. Хотите показать, что можете создавать сайты идеально работающие даже на чайниках и кофеварках? Тогда, очевидно, не используйте.

Нельзя.

https://gist.github.com/lauhakari/5089252
Но, очень не советую делать что-то такое. Это чудесный способ выстрелить себе в ногу.

Полагаю, вы должны задать себе несколько вопросов на определённую тему.

Как пользователь будет работать с сайтом? Предполагается больше мобильных устройств? Или десктопных? Пользователь попадет на одну страницу? Или предполагается несколько последовательных страниц? Все страницы однотипны? Или каждая и выглядит и работают по разному? Какой контент должен размещаться? Предполагается ли что пользователь будет периодически возвращаться на эти страницы? Нужен ли доступ offline?

Отвечайте на эти вопросы. А дальше думайте о том, как добиться наилучшей производительности в описанном сценарии. Например, если предполагается Сайт визитка. В этом случае, у вас есть одна или несколько практически идентичных страниц. Весь контент статический. Вероятно пользователи будут часто возвращаться на этот сайт.

• Так как у нас одна или несколько практически идентичных страниц, логично собрать весь функционал (скрипты, стили) для всего в один файл. Вместо того, чтобы создавать отдельные файлы для каждой страницы.
  
  
• Так как весь контент статический, нет нужны в каких либо CMS или серверной генерации. Весь сайт можно скомпилировать в готовые html файлы которые будут максимально быстро отдаваться клиенту.
  
  
• Так как предполагается, что пользователи будут время от времени возвращаться на ваш сайт, нужно настроить кэширование файлов.
  
  
• Так как на сайте предполагается размещение контактов, важно предоставить возможность доступа к сайту offline.
  

Кто будет работать, что умеет? Сюда я отношу всё что связано с задачей и тем кто будет её выполнять. Если ли ограничения по времени на реализацию? Какой бюджет на разработку? Какие люди есть в команде? Что они умеют? Есть ли в команде люди, умеющие, работавшие ранее с какой-то технологией, которую вы определили ранее? Сколько времени понадобится чтобы разработчик изучил эту технологию с нуля? Целесообразно ли это? Если ли альтернативы из того, что люди в вашей команде уже умеют? Кто будет заниматься поддержкой этого сайта? Поддержку какого рода вы будете предоставлять? Насколько вы хотите продолжать работать с этим клиентом?

Так вы сможете определить технологии которые будут использоваться для разработки. И отталкиваясь от этого определить архитектуру.

В каждом модуле импортируйте всё и исключительно то, что нужно для работы непосредственно этого модуля. Так ваша система будет гибче и работать с каждым модулем отдельно будет проще. Модули устроены так, что импортируются только раз, не зависимо от того, сколько раз вы вызываете require.

Ваш подход вполне нормальный, если вы конечно не импортируете в модуль А что-то что используется только в модуле Б и не используется в модуле А непосредственно.

Выносить все импорты в отдельный файл, как предлагает Дмитрий я бы не стал.

А

все модули передавать напрямую в функцию (как это сделано со state)

оправдано только в том случае, если вы реализуете паттерн Стратегия

Так и в чем проблема?

localStorage.setItem('cart', JSON.stringify({[2021]: cart[2021]}));