Дмитрий Беляев

const credTester: Record<keyof Credentials, RegExp> = {
        login: /^[0-9a-zA-Z]*$/,
        password: /^[0-9a-zA-Z@#.]*$/
};

https://vueframework.com/docs/v3/ru/ru/guide/event...
Смотрите про $event

Ну начнем с того, что computer science - это очень широкое понятие, которое включает в себя множество различных областей, как теоретических так и практических. Вопрос "нужен ли программисту computer science?" из той же оперы, что и "нужна ли программисту математика?", кому-то и арифметики хватает (а это тоже математика как не странно), а кому-то нужен углубленный бэкграунд в мат.анализе, тер.вере и мат.статистике. Так же и с computer science, кому-то хватит базового понимания, почему 0.1 + 0.2 != 0.3, а кому-то нужен углубленный бэкграунд в алгоритмы, в теорию типов и в слабые модели памяти. Все сугубо индивидуально и сильно зависит от сферы, для которой ведется разработка.
Многим совсем не обязательно знать как реализуются те или иные алгоритмы или структуры данных, вполне можно пользоваться готовыми. Но вот иметь представление, какие вообще бывают алгоритмы и структуры данных, какая у них алгоритмическая сложность - это полезно всем, просто чтобы знать что гуглить и какие вообще есть возможности решить ту или иную задачу. Так же полезно уметь считать ту самую алгоритмическую сложность из составных частей произвольного алгоритма и понимать чем отличается нотация O-большое от нотации Ω-большое. Какая от этого практическая польза? Для самого программиста - это возможность решать задачи проще и быстрее, выдавая при этом более оптимальные решения. Для бизнеса - это деньги, от банального "ускорив некое действие в N раз мы повысили конверсию в M раз", до насущного "сократив потребление ресурсов на N в прошлом месяце мы заплатили за облако на M млн. рублей меньше в этом месяце при той же нагрузке".
Та же архитектура, всем не обязательно уметь строить огромные решения с запасом прочности на десятки лет. Но понимать базовые принципы и паттерны, какие у них плюсы и минусы, где и что применять - полезно. К сожалению здесь все плохо в большинстве своем, порой доходит до того что стоимость поддержки небольшого проекта вырастает в 300-500 раз всего лишь за год поддержки. Для бизнеса это опять таки деньги, и если бизнес не планирует через год-другой либо продаться либо свернуться, как делают многие стартапы, то бизнес будет это оптимизировать. А на программистах такая оптимизация скажется на прямую, те кто умеет писать код на года будет получать выше рынка, иногда значительно. Хотя и те кто вообще в архитектуре не шарит без работы не останутся, так как работодателей с принципом "продали и забыли" просто банально больше.

Все реактивные свойства объекта Vue оборачивает в геттеры и сеттеры.
Computed - это тоже по сути геттер, правда Vue его еще и своим кодом оборачивает.
Перед кажым запуском computed Vue помещает в особую переменную функцию для инвалидации текущего computed, а перед выходом восстанавливает значение, которое там было до.
Каждый геттер вызванный внутри computed просто запоминает себе в массив функцию инвалидации, а в сеттере дергает ее, сообщая тем самым computed свойству, что его зависимость изменилась.
Это очень упрощенная схема, так как на деле все немного сложнее. Но в общих чертах, Vue просто знает какие геттеры были вызваны при последнем вызове computed и при вызове соответствующих этим геттерам сеттеров пересчитывает computed.

HttpOnly Cookie доступна только серверу, который доступен по домену, который прописан в этой куке и никому больше.
Storage доступен любому скрипту на странице. Соответственно содержимое Storage может угнать любой скрипт подключенный извне.

Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

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

Через несколько месяцев прочел еще раз, анализируя все затупы, что записал за это время в блокнот. После прочтения начал потихоньку рефакторить в существующих проектах места, которые уж очень жить мешали.

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

Ну и недавно решил освежить память и перечитать еще раз. И на этот раз уже были мысли вроде "так если делать по другому, потом проблемы вылезут тут и тут".

new Promise(resolve => {
  // здесь код выполняется синхронно
  resolve();
}).then(() => {
  // здесь уже асинхронно, в ближайшем микротаске после вызова resolve выше
});

Promise.resolve().then(() => {
  // здесь тоже асинхронно, в ближайшем микротаске
});

много вычислений

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

А что Вам не понятно из описания ошибки?
Вы пытаетесь присвоить объект ComputedRef<number>, возвращаемый функцией computed в поле объекта объявленное как number.
Нужно или поменять тип у поля, или обновлять поле через watch.

Скорее всего проблема с путями для 'easyvk.js'.
Во-первых, лучше всегда вычислять абсолютный путь до файла.
Во-вторых, electron-packager пакует приложение в asar, и если require пропатчен для работы с ним, то child_process скорее всего нет и нужен анпакинг файла перед запуском.

Во-первых, REST - это не стандарт, не строгие правила, это рекомендации.
Вся суть этих рекомендаций сводится к двум вещам:
- Каждый ресурс (документ, данные о сущности) имеет свой собственный URI
- Для каждого действия с ресурсом предлагается в соответствие свой HTTP метод запроса

Теперь по вопросам:
1. Если данные json и html - это просто разные представления одного ресурса, то они вполне могут жить на одном URI. Например разное представление отдается в зависимости от HTTP заголовка Accept.
2. REST никак не регламентирует, как Вам строить приложение. Это может быть отдельный запрос к сущности "роль" или быть частью сущности "пользователь", решать Вам.
3. Опять же, REST тут вообще не причем. В REST нет никаких БД, сессий или еще чего либо, что Вы там под капотом используете инкапсулировано от клиента.
4. CSRF делается как и в любом другом случае. Вот статья есть: https://habr.com/ru/post/318748/

state.firstname = action.payload.firstname;тут Вы мутируете предыдущий стейт, что потенциально может привести к невозможности сравнить стейты.

reducer(state, action);возвращаемый стейт никуда не записывается

callback();А вот тут может быть потенциально ошибка, так как callback может быть undefined