Comments 12
Алгоритмическая сложность undo: O(времени проведённом пользователем на странице). Такое себе решение. Почитайте лучше про diffTree: www.microsoft.com/en-us/research/wp-content/uploads/2015/02/paper-full.pdf
А не проще ли применять мутацию обратную последней? чтобы постоянно не пересчитывать?
Если хранить состояние с помощью Immutable.js, можно сохранять не мутации, а сами состояния (Immutable.js хитрый, и это, скорее всего, не вызовет большого оверхеда по памяти), и всё станет сильно проще. Но возникнут трудности с сериализацией.
Возникнут сложности с изменениями полученными от сервера, которые, внезапно, не надо откатывать.
Поправьте меня, если я ошибаюсь: если мутации юзера не коммутативны с мутациями сервера, то всё так и так плохо. А если коммутативны, то можно выделить отдельное подмножество состояния, за которое отвечает юзер и которое можно сохранять в истории для undo/redo.
Любое состояние может меняться разными пользователями, так что ничего выделить не получится.
Можно пример?
Пример чего? Данное сообщение, например, может быть отредактировано мною, админом. А в перспективе ещё и ботом каким-нибудь.
В принципе, эта проблема решена в MobX State Tree «из коробки». Изменения можно хранить в виде набора immutable снапшотов (как в Redux). Или в виде потока операций JSON Patch: можно применить операцию к стору, или применить обратную операцию, или отпарвить на сервер, и т.д. Жаль, что для Vue нет подобной библиотеки.
Sign up to leave a comment.
Создаем плагин Vuex Undo/Redo для VueJS