Ростислав

В App.vue я запрашиваю все продукты из БД

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

store.dispatch('GET_PRODUCTS').then(() => {
  new Vue({ ... });
});

??

Если же отвечать непосредственно на спрошенное - установите наблюдение за значением в хранилище:

watch: {
  '$store.state.products': {
    immediate: true,
    handler(products) {
      if (products) {
        // можно что-то сделать
      }
    },
  },
},

То, о чём Вы спрашиваете, официально называется WAI-ARIA.
Тут можно скачать бесплатно экранного диктора и с помощью него тестировать свои сайты, осуществляя навигацию по ним с помощью табуляции, а так же открывая специальное меню с помощью горячих клавиш (командная кнопка приложения, которую назначите, по умолчанию ins+f7, или f6? Не помню уже точно :-) )

Доклады Вадима Макеева на ютубе:
https://www.youtube.com/watch?v=MWJKwn_gKR4
https://www.youtube.com/watch?v=ssJsjGZE2sc

Если действительно умеете соблюдать семантику, то, скорее всего, Вы уже сделали достаточно.
Рускоязычные ресурсы по доступности:
https://weblind.ru/
specialbank.ru/guide (В данный момент чёт не работает, но должен)
Есть курс, где учат именно этому: https://kurmak.info/
Статья на хабре: https://habr.com/ru/post/40730/ (там внизу есть полезные ссылки)
Тут можно найти информацию по этому вопросу, в том числе перевод статей из первой ссылки англоязычных ресурсов

В подкасте Веб-стандарты упоминается об этом очень часто. Тут можно прослушать все выпуски, а так же покопаться в выпусках и поискать упоминания доступности и статьи про это.

Есть англоязычные ресурсы
Про доступные компоненты: https://inclusive-components.design/ (нажимаете в хроме справа сверху "перевести страницу" и профит)
Есть спецификация: https://www.w3.org/TR/wai-aria-1.1/#usage (аналогично, перевод в браузере и профит)
MDN: https://developer.mozilla.org/en-US/docs/Learn/Acc...

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

Говорить о том, что некие фичи устарели - крайне глупо, если знать, что они ведут себя иначе, чем более модные альтернативы. Предлагаю немного разобраться и начать с того что на поверхности:
- getElementById и querySelector возвращают конкретную ноду в единственном экземпляре
- querySelectorAll и getElementsByName возвращает статичную коллекцию NodeList
- getElementsByClassName, getElementsByTagName и getElementsByTagNameNS возвращают динамическую коллекцию HTMLCollection
Как видим результат у разного апи различен, а значит и говорить, что некоторые из них устарели - глупо.
С устареванием вроде разобрались, но в вопросе еще есть часть "чем лучше". И тут есть теория, что getElementsBy* быстрее querySelector*. Чисто теоретически звучит логично, querySelector* должен делать полный поиск по дереву со сложностью O(n), а getElementsBy* могут использовать индексы на базе HashMap и получать данные со сложностью O(1), тут и особенности HTMLCollection будут кстати, так как можно не копировать коллекцию, а отдавать одну и ту же (и браузеры действительно так делают). Но без пруфов теория так и останется теорией.Гораздо лучше тут выглядят исходники. И я выбрал исходники chromium, как самого распространенного:
- getElementsBy* методы все как один обращаются к некой шаблонной функции EnsureCachedCollection, которая в свою очередь обращается к некоему NodeLists кэшу, устроенному внутри действительно как HashMap или что-то наподобие. Никакого поиска тут нет, просто берутся готовые значения, сложность у всего этого действительно константная O(1).
- querySelector* используют абстракцию SelectorQuery, которая и в самом деле делает поиск по DOM. Но данный поиск неплохо оптимизирован и обвешан кэшами. Притом CSSOM использует абсолютно тот же алгоритм поиска DOM нод для каждого селектора в css.

На этом спор думаю можно закрыть. querySelector* методы действительно могут быть медленнее, но чтоб убить ими производительность, нужно очень постараться. На фоне того, что пишут кривые ручки среднестатистического дешевого js-кодера это будет незначительной потерей измеряемой в наносекундах. Используйте то что удобнее в каждой конкретной ситуации.

Автор, в сам вс код встроен поиск расширений, даже заходить никуда не надо. И ты хочешь сказать, что зайти сюда, задать вопрос и дождать ответа это дольше, чем самому найти за полминуты максимум?
1. https://marketplace.visualstudio.com/items?itemNam...
2. https://marketplace.visualstudio.com/items?itemNam...

У вас в state нет свойства wsData

Добрый день
А если при регистрации добавлять емейл и пароль как у вас,

await firebase.auth().createUserWithEmailAndPassword(email, password)

затем определять uid
и по нему добавлять все нужные поля уже в database()

await firebase.database().ref(`/users/${uid}/userInfo`).set({
                  name, department, email
              });

У меня так полный вариант выглядит в vuex

actions: {
async registrations({commit, dispatch}, {name, department, email, password}){
          try{
              await firebase.auth().createUserWithEmailAndPassword(email, password)
              const uid = await dispatch('userId');  
              await firebase.database().ref(`/users/${uid}/info`).set({
                  name, department, email
              });
          }catch(e){
              throw e
          }
        },
       userId(){
          const user = firebase.auth().currentUser
          return user ? user.uid : null
        }
}