profcat

Тэг menu есть в спеке html, хоть и deprecated вроде, а так - тебе ничто не мешает юзать незарезервированные названия.
Ну или если очень хочется, можно на свой страх и риск перебить и зарегистрированные тэги:

Vue.config.isReservedTag = function(isReservedTag){
  const allowedTags = ['menu'];
  return function(tag) {
    if(allowedTags.includes(tag)) return false;
    return isReservedTag.call(this, tag);
  }
}(Vue.config.isReservedTag);

Мне вот интересно при перезагрузке страницы лайк останется?
Не рекомендую заниматься великами с треугольными колесами. Это кнопка. У нее могут быть состояния

Вот честно задолбало. Люди делают экспериментальные вещи. рисуют картины на css, а другие думают что так и надо не разобравшись начинают делать слайдеры на css и пр. фигней заниматься.
Ничего что чекбокс это элемент формы Он в вакууме не может существовать?

https://material.io/icons/

https://materialdesignicons.com

Не натягивайте ужа на кактус.

connect не нужен с тех самых пор, как появились useSelector и useDispatch. Просто выбрасываете лишние обертки и живете счастливо.

это норма :)
открой эту вкладку консоли разработчика на фейсбуке, посмотри как любой самый маленький компонент вложен в сотню врапперов



это один комментарий к посту (юзернейм, юзерпик, лайк, время), всё дерево компонентов не влезает на один экран

1. useDispatch - получение функции store.dispatch в компоненте. Раньше для вызова action функциональный компонент приходилось оборачивать в вызов connect:

const Foo = ({ dispatch }) => {
  const handler = useCallback(() => {
    dispatch(action());
  }, []);

  return (
    <Bar onClick={handler} />
  );
};

export default connect()(Foo);

Сейчас:

const Foo = () => {
  const dispatch = useDispatch();

  const handler = useCallback(() => {
    dispatch(action());
  }, []);

  return (
    <Bar onClick={handler} />
  );
};

export default Foo;

2. useSelector - маппинг значения из store.
Раньше:

const Foo = ({ value }) => {
  return (
    <Bar value={value} />
  );
};

const mapStateToProps = state => ({
  value: state.value,
});

export default connect(mapStateToProps)(Foo);

const Foo = () => {
  const value = useSelector(state => state.value);

  return (
    <Bar value={value} />
  );
};

export default Foo;

3. useStore - получение store целиком:

const valueSelector = state => state.value;

const Foo = () => {
  const { dispatch, getState, subscribe } = useStore();
  const value = valueSelector(getState());
  
  useEffect(() => subscribe(console.log), []);

  const handler = useCallback(() => {
    dispatch(action());
  }, []);

  return (
    <Bar onClick={handler} value={value} />
  );
};

export default Foo;

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

Все достаточно просто, хоть и не совсем очевидно.
Выражение:
foo.x = foo = {n: 2};
равносильно:
foo.x = (foo = {n: 2});

Мы присваиваем объекту по идентификатору foo свойство x, которое равно результату операции присваивания идентификатору foo ссылки на объект { n: 2 }.

Чтобы в этом убедиться достаточно добавить переменную bar, присвоить ей начальное значение foo и вывести в конце:

let foo = {};

const bar = foo;

foo.x = (foo = {n: 2});

console.log(foo.x === undefined);  // true

console.log(bar);  // { x: { n:  2 } }

console.log(bar.x === foo);  // true

Ключевые отличия операций присваивания, которые важно понимать:
foo.x = - присваивание свойства конкретному объекту. На момент вызова в нашем примере это {}.
foo = - присваивание значения самому идентификатору foo. Это может быть примитив, ссылка на объект или функцию. В нашем случае это объект { n: 2 }.

obj.constructor.name

1. Нет. Зевс молнией вас не испепелит. Втыкать лишнее computed заради одного единственного вызова никакого смысла нет.
2. В хранилище должны быть только функции относящиеся к хранению данных. Некоторые пихают в store чуть ли не всю логику приложения, как по мне, так это форменное безумие.
У вас есть повторяющийся код связанный с работой с данными? Используйте миксины или вообще просто обычные отдельные js модули.
3. Маленькая.
4. Такой же как и без vue - аккуратная вёрстка с использованием разумной системы(БЭМ и пр.). Никакой излишне сложной логики в шаблоне быть не должно, а потому оная на это практически не влияет.
Для действительно сложной логики, способной превратить шаблон в кашу, используется render функция.

1. Да
   
2. Тут всё просто: Функцция или данные нужны только в одном компоненте или в нескольких? В одном — всё в компонент. Иначе в хранилище. Сами мутации должны быть как можно легче. Они блокируют интерфейс.
   
3. Чем меньше тем лучше. Любую несвязанную логику лучше выносить в отдельный компонент. Это опять таки скажется на производительности в лучшую сторону
   

Ссылки:

• https://ru.vuejs.org/v2/style-guide/index.html
  
• https://habr.com/ru/post/483042/
  
• https://arutyunov.me/blog/vue/26-sovetov-dlya-vue-...
  

При помощи calc(100vw - 100%) можно вычислить ширину скроллбара (а если он не отображается, то будет 0). Идея: при помощи отрицательного margin-right увеличить ширину <html> на эту ширину. При этом появляется горизонтальная полоса прокрутки — ее скрываем.

html {
  overflow-x: hidden;
  margin-right: calc(-1 * (100vw - 100%));
}

Пример. Нажатие кнопки "change min-height" скрывает\отображает скроллбар.

Компиляторы-транспиляторы-трансляторы (типа Coffee, LESS, Jade), тест-раннеры, стайл-чекеры и линтеры (mocha, chai, karma, (js|es)lint, jscs), плагины для таск-раннеров (grunt-contrib-watch, gulp-jade) — все это обычно ставится как --save-dev, потому что нужно только тем, кто контрибьютит в этот проект, работает с его кодом.

Библиотеки и фреймворки (expressjs, jquery, backbone), на основе которых работает ваш код, без которых ваш код не запустится у его потребителя — ставятся как --save.

Вам ничего не мешает делать по старинке: один глобальный файл с глобальными стилями.

Ну, или иначе. Если вы хотите инкапсулировать стили — тогда все они дожны быть внутри компонентов.

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

Глобальные стили или отдельный компонент с кнопкой.

Как наиболее правильно с точки зрения good practice назвать имена классов?

На самом деле как вам удобно. Лично я использую следующий паттерн

class=" component-root <component-name>-component-root "

UPD.
Если есть необходимость передать какое-то свойство в нутрь компонента, то можно сделать это через кастомные свойства:

<style scoped>
.button {
    color: var(--text-color, green)
}
</style>

<button-component style="--text-color: blue"/>

wscript - это утилита выполняющая vbs/js скрипты в винде. Это не с ней не так, это не так со скриптом который она выполняет в этот момент времени.
Включите отображение командной строки в менеджере задач, там увидите путь к скрипту, который передан утилите как параметр командной строки. Скрипт может стартовать где-нибудь в автозагрузке или в шедулере или быть частью какого-то установленного ПО.

Не оч понял что там с БЕМом.

Кнопка Плей ничего не парсит. Есть папка компонент. В папке компонент есть папка Кнопка. В ней код компоненты и стилей для Кнопки. Кнопка может принимать разные конфигурационные параметры типа текста, возможно иконки, цвета, формы, размера... Короче все вариации кнопок которые вам нужно реализовать. И кнопка принимает как один из параметр функцию обработки клика которую вызывает при клике и которой передает объект события. Может что-то еще. Вам виднее.

Далее у вас есть компонента которая отвечает за отрисовку какой-то страницы. Например у вас несколько основных разделов на сайте. Для каждого создает папку, а внутри компоненты страниц и подстраниц. Если иерархия сайта не глубокая и не большая можно структурой папок повторять структуру сайта.

В компоненте вашей страницы вы импортируете все необходимые компоненты в том числе Кнопку, объявляет методы которые делают эту страниц живой. Один из методов обработчик клика кнопки. Передаете компоненте Кнопка необходимые параметры включая title="Play" и функцию обработки клика.

Если есть какие-то сервисы которые много где используются или хелпер функции то их можно разместить например в папке common/services или common/helpers.

Ой я писал как если бы это был проект на реакте, только сейчас заметил что вопрос по ноде. Но современный бэкэнд не компилирует хтмль а только отдает по определенным эндпоинтам соответствующие данные в виде json. А разметка полностью на стороне фронтэнда.