✨
ну версию мы сохраням непосредственно в самом событии
Size: a a a
2021 September 24
✨
а здесь мы сугубо имеем только ссылку на текущее состояние
SP
Меняем имя "событие" на "ревизия" и получаем гит
✨
ура, я изобрела гит ))
SP
Там смысл в том что с es нас не интересует стэйт на какой-то момент времени. Нас интересует как он менялся во времени. Что бы можно было любую модель данных потом делать. Это требует анализа чё у тебя за события происходит. Подход не любит реюза. Когда весь стрим это "я поменялсо" то ценности в этом нет
SP
Версионизация проще чем es
SP
Справедливости ради в 90% ситуаций где хотят es запихнуть хватит версионизации
SP
Зато с es ты сможешь потом оч быстро запилить фичу "а давай мы будем им показывать товары которые они выкладывали из корзины за 5 минут до чекаута*
SP
Это не выйдет сделать просто на снэпшетах состояния карзины. Ну точнее можно но сложно. Потому и ивенты там дробить надо сильно
SP
Шоб потом аще любую модель строить
SP
Удобно когда что происходит ты знаешь а чё потом делать с данными ещё нет
✨
хм...
✨
я поняла...
важно иметь события изменения состояния и именно значение изменения, а не его результат
важно иметь события изменения состояния и именно значение изменения, а не его результат
SP
да, в этом всем больше данных чем в самом стэйте, по сути добавляется семантика изменения стэйта и время когда это происходило
✨
а если мы будем иметь и значение изменения и резудьтат в одном объекте?
✨
хотя что нам стейт, если мы не знаем порядок и значения событий
✨
все, я поняла, спасибо )
SP
можно, просто обычно не нужно. взять сотню ивентов и вычислить по ним стэйт обычно не напрягает CPU особо. А хранить больше данных доставать и перемещать обычно влияет на пропускную способность. Достать 100 записей из базы может быть дешевле чем сначала достать снэпшет по сети а потом остаток ивентов чекнуть