lavezzi1

Сделайте отдельный метод:

@click="onClick"

methods: {
  onClick() {
    this.myVueMeth1();
    this.myVueMeth2();
    document.forms[0].submit();
  },
},

UPD. Конечно, вы можете определить computed свойство для document, типа так:

computed: {
  document() {
    return document;
  },
},

Тогда ваш первый пример заработает. Но это какое-то варварство, на мой взгляд.

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

Есть такая штука - nextTick. С ёё помощью можно вызвать функцию после обновления DOM-дерева. Т.е., делайте так:

this.stage = 1;
this.$nextTick(() => {
  const elem = document.querySelector('.elem');
  ...
});

Отвечу как тот, кто работает с "папками" от веб-дизайнеров.
В идеальном случае это:
макеты с артбордами внутри(с хорошо именованными и структурированными слоями);
шрифты(если это не гуглфонтс);
графика(не вся, но, например, если в макете используются большие бэкграунды, фотки, все это - неплохо иметь отдельными файлами);
свг иконки;
все макеты сохраненные в пнг;

fetch промис возвращает, не нужны еще дополнительно оборачивать

return fetch(`/api/items/create/`)
        .then(response => response.json())
        .catch((err) => {
          window.console.error(err);
          throw err;
        });
    });

Если отбросить маркетинг (рекламу).

Зачем Microsoft службы телеметрии

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

что он может с этими знаниями сделать

Да, в общем-то ничего такого. При условии, что ты не кладёшь свою жизнь на алтарь корпорации.

Можно так:

this.items.forEach((item) => {
   this.teams.forEach((team) => {
      if (item.team_id === team.id) {
          if (team.items) {
            team.items.push(item);
          } else {
            team.items = [item];
          }
      }
  });
});

Либо предварительно:

this.teams.forEach(team => {
  team.items = [];
});

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

просто добавьте проверку на существование, если не существует то инициализируйте пустым массивом: team.items = team.items || []

this.items.forEach((item) => {
   this.teams.forEach((team) => {      
      if (item.team_id === team.id) {
          team.items = team.items || [];
          team.items.push(item);
      }
  });
});

Читаю книги. Проблем нет

Есть две крайности, которых лучше избегать:
1. красивая и исчерпывающая документация требует колоссальных ресурсов на поддержку
2. сложно воспринимаемый код, без малейших подсказок с чего все начинается и чем заканчивается

Стандартные решения:
1. самодокументируемый код, составленный так, что читающий может понять что для чего и в какой последовательности работает.
2. описание интерфейсов (назначение метода, тип/суть параметров и т.п.) в форме комментов в коде.
3. автоматическая документация (генерится из комментариев) - эффективно, только если сам код закрыт.
4. модульные тесты, фиксирующие требования к коду и демонстрирующие его использование.
5. описание высокоуровневого дизайна (High Level Design, HLD), описывающий какие элементы существуют, их взаимосвязь друг с другом и основные сценарии взаимодействия.

Работающая документация - это компромисс из этих практик, релевантный конкретной ситуации.

Кстати, проектная работа, это не только документация к коду, это еще и свод правил, которые позволят архитектуре не расползтись кто в лес кто по дрова, а также сохранят стилистику написания кода для единообразия и легкой поддерживаемости кода.