Aleksei Podgaev

Нужно держать состояние диалога, индивидуальное для каждого пользователя.

Команды пользователя складывать в очередь, и как-то помечать, «где мы сейчас»: ждём очередную команду от пользователя или ждём ответа от сервера.

Состояние можно держать в Redis, MySQL или другой БД. Входящее сообщение от пользователя содержит его from.id – по нему идентифицируется диалог и берется его состояние.

Промисы и прочая асинхрота тут не поможет, так как дело шире, чем один запрос.

можно условно считать, что fetch это низкоуровневая реализация, а axios - более высокоуровневая библиотека. Fetch он вам предоставляет минимум для работы с запросами, в аксиос есть дополнительные интересные плюшки. И вы вероятно правы, - если написать обертку над фетчем (а ее скорее всего придется писать в более или менне непростом сайте), то получится как минимум кастрированный аксиос, как максимум — что-то лучше.

Изучать надо программирование.
Все эти вопросы, "Какую машину лучше учиться водить - Рено или Фольксваген?" - это детский сад, честное слово.
Если для вас потолок - это несколько десятков встроенных функций одного языка, то всё равно что учить - ковыряться помаленьку можно на любом.
Программист же мыслит не инструкциями, а алгоритмами, паттернами, потоками данных, структурами объектов, шинами сообщений. На каком языке это все реализуется - не принципиально.

Судя по доке:
now secret add acme-api-key my-value-here

https://zeit.co/docs/features/env-and-secrets

UPD:
> Это нормально что в контроллере столько много catch'eй?
Не то чтобы нет, но "попахивает".
> как быть, если у меня возникает несколько исключений, и я хочу выдать пользователю информацию о всех возникших сразу

У вас смешана валидация входных параметров с возникновением нештатных ситуаций.
Exception стоит кидать если метод не может вернуть осмысленный результат.
Ошибки валидации ("сообщение слишком длинное", "файл не того расширения") можно собирать, к примеру, в массив. Как валидировать входные данные выходит за рамки этого вопроса.
------
> Можно ли так делать?
Попробуйте использовать правило 5 почему (ну или "зачем") чтобы попытаться добраться до сути.

- Я даю отдельные имена исключениям.
- Зачем?
- Для того что бы отловить различные ошибки.
- Зачем отлавливать различные типы ошибок?
- Чтобы показывать разные сообщения.
- Зачем показывать разные сообщения?
- Чтобы пользователь мог отреагировать определенным образом на конкретный тип ошибки
(решить что ему делать в случае конкретного исключения).

Давайте посмотрим что человек (пользователь) на вашем сайте (системе) может сделать в случае ошибки:
1. Не корректное сообщение.
Привести его к корректному (сделать его короче, как-то отформатировать и т.п.)

2. Не удалось загрузить файл.
Если файл слишком большой - можно попробовать загрузить файл поменьше.
Если это внутренняя ошибка (например: закончилось место на диске на сервере, нет прав на запись и т.п) - то ничего, здесь уже требуется вмешательство тех кто обслуживает систему.

3. Ошибка PDO.
Ничего, это внутренняя ошибка.

Т.е. есть смысл создавать новый тип исключения, если пользователь системы может иначе отреагировать на этот тип.

Я использую 2 типа исключений на уровне web-слоя: внешние и внутренние.
Внешние - если пользователь может повлиять на них (страница не найдена, файл слишком большой, нет доступа и т.п.).
В них сообщение показывается пользователю как есть. Подноготная (пути к файлам, пароли, названия БД и т.п) в такие ошибки не вкладывается.

Внутренние - пользователь не может влиять (ошибка подключения к БД, SQL syntax error и т.п).
Пользователю показывается только код ошибки. В такие ошибки также вкладываю техническую информацию.

Ты (как программист) также можешь быть пользователем какой-то системы (к примеру, библиотеки).
Например, библиотеки для работы с БД.
Предположим ты импортируешь csv-файл в базу, заполняешь числовую колонку и вместо числа у тебя попадается текст.
Запрос падает с ошибкой и тебе не плохо бы отличать её от ошибки синтаксиса.
Если попался текст вместо числа - то можно просто пропустить строку.
Если ошибка синтаксиса - то у ошибка в коде и продолжать импорт нет смысла.

Подытожу:

> Можно ли создавать свои пустые классы Exception'ов наследуемые от класса Exception только лишь для того что бы было отдельное имя исключения?

Можно.

Сколько делать отдельных исключений?
Зависит от того как их будет обрабатывать пользователь.
Если твой контроллер(модель, подсистема) кидает множество разных ошибок и все они обрабатываются одинаково - то стоит призадуматься.

Практика хорошая. Именно так и стоит делать. В идеале у каждой ошибки должен быть свой уникальный эксепшн. Например, от FileException можно наследовать например NotFoundFileException и AccessFileException. При этом тело классов в большинстве случаев будет пустым.

А вот то, что ты пытаешься поймать все возможные эксапшны в контроллере - это совсем не хорошо. По хорошему нужен отдельный эксепшн хендлер для этого.

Полезность итераторов в том что это открытый интерфейс для любой структуры данных. Как вы уже поняли, любой класс/объект в JS может обладать интерфейсом итератора. Идея итератора в том чтобы скрыть внутреннее представление структуры данных от потребителя этих данных. Например, если вы работаете с какими-либо замысловатыми структурами данных, типа бинарных деревьев. Пользователю совсем не обязательно знать как ваш класс/объект хранит бинарное дерево. Пользователь просто его получает и проходит по всем его элементам в цикле. В дальнейшем, вы можете, при необходимости, заменить одну структуру данных на другую, не меняя самого пользователя. Например, вы можете заменить бинарное дерево на б-дерево прозрачно для самого пользователя (пользователь не будет знать что вы подменили структуры, он по прежнему получает что-то что можно проитерировать и ему этого достаточно).

Для того чтоб глубже понять суть вопроса, можно погуглить про инкапсуляцию и SOLID (в вашем случае, принцип Open/closed).

Попробую на пальцах объяснить.

Событие – это конверт, на котором написано его название. Внутрь конверта можете вложить что-нибудь, а можете оставить конверт пустым.

Элемент – это столик. Кто угодно может подойти и положить на столик свой конверт.

Слушатель – это мужик, который топчется около столика и смотрит, нет ли чего с интересующим его названием. Может несколько человек поджидать конвертики с определённым названием – прочтут все, если только в конверте не написано «по прочтении съесть» – тогда кто-то съест и дальше не передаст.

Как создать/отправить конверт. В любом месте кода создайте конверт и дайте ему название: var myEvent = new Event('teaTime'); Остается положить конверт на нужный столик:

document.getElementById('stolik').dispatchEvent(myEvent);

Чтобы в событие вложить какие-то данные, нужно использовать другой конструктор и передать нагрузку в поле detail:

var event = new CustomEvent('saySomething', { detail: "Hello there!" });

Для чего нужно создавать свои события? Чтобы развязать куски кода. Например, в разных местах документа можно нажать на кнопку повторяющегося виджета. Виджет создаст на document событие "widgetClicked". А ещё несколько одинаковых компонентов в странице, слушающих document на предмет события "widgetClicked", получат пинок и что-нибудь вытворят.

Вешаю на него сеттер...

Не-а, не на него. Созданное ранее свойство вы перетёрли вызовом defineProperty, кроме того, вы не определяете геттер - отсюда и undefined.

Можно добавить геттер, само же значение сделать локальной переменной конструктора:

function test(m) {
  let money = m;

  Object.defineProperty(this, 'money', {
    get() {
      return money;
    },
    set(val) {
      alert(`Значение свойства money меняется с ${money} на ${val}`);
      money = val;
    },
  });
}

Или можно воспользоваться Proxy:

function test(m) {
  this.money = m;

  return new Proxy(this, {
    set(target, prop, val) {
      alert(`Значение свойства ${prop} меняется с ${target[prop]} на ${val}`);
      target[prop] = val;
      return true;
    },
  });
}

(angular не использует vdom, для него история другая)

перерисует целиком свой виртуальный dom

Давайте немного проясним: виртуальный DOM - это грубо говоря js объект содержащий другие объекты.
При добавлении нового сообщения туда добавится новый объект и весь DOM сравнится со старой версией с помощью diff-алгоритма специфичного для конкретного фреймворка.
И только результат этого сравнения добавится в реальный DOM.
Работа с объектом значительно быстрее работы с самим DOM-ом, поэтому чтобы оно начало работать заметно медленее у вас должен быть дикий уровень вложенности или очень большой DOM.

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

Вот пример бенчмарков с большим количеством объектов(1000+) для многих фреймворков на примере незамысловатой таблицы:
www.stefankrause.net/js-frameworks-benchmark6/webd...
(там же есть ссылка на репо чтобы увидеть как она выглядит)
Как видите, там в таблицу уже содержащую 10 000 добавляется еще 1000(!) объектов, и многие фреймворки впонле с этим справляются.

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