В scala или scalajs Diode какой-либо из существующих типов соответствует сценарию использования "обновления модели, которая еще не существует"?

Question

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

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

Теперь очень необычная ситуация: вам нужно отслеживать ввод этой формы, потому что эта форма используется правительством США для общения с нашими парнями в ядерных бункерах в Вайоминге. Безусловно, важно, чтобы ввод данных действовал при отправке, но нам нужно дополнительно знать как можно больше о том, как он туда попал. Допустим, это форма входа в систему, например. Если мы отслеживаем последовательность событий от 0 до отправки и сравниваем ее с прошлым, мы можем обнаружить, например, аномалии в поведении пользователя. Мы можем определить, есть ли у нас проблемы с серверами входа, прежде чем узнаем о них. Так что это не всегда одноразовая информация.

Я хочу нанести на карту событие onChange к некоторой концепции Диода, но у меня возникают проблемы с выяснением того, что я должен делать. Вот варианты:

1. Я мог бы определить новый case class для каждого типа поля и для каждого переставленного типа объекта, и вставьте их все в корневую модель (кажется глупым способом сделать это)
2. Я мог бы определить обобщенную структуру данных, представляющую "непредставленное изменение входного значения", которое также указывало бы на изменение модели и поля. Кажется оптимальным, но, возможно, ненужным и много работы и трудно сделать хорошо.
3. Я мог бы использовать существующую структуру данных, как один из Pots, чтобы стоять на месте для моего Scratch структура данных. Вероятно, лучшая идея, но не уверен, что использовать.

Вот где я нахожусь... Любой вдумчивый совет приветствуется.

Answer 1

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

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

1. В состоянии просмотра компонента. Просто добавьте метки времени в список, сохраненный в состоянии просмотра. При отправке отправьте этот список вместе с остальными данными.

2. В диодной модели. Опять же, сохраните список событий в модели и отправьте с данными формы.

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

Для таких переходных данных я бы вообще не направлял их через диод, а использовал бы опции 1 или 3 для их передачи.