使用本地存储作为自动保存代理 - 好还是坏？
我们正在开发一个使用自动保存作为保存模式的网络应用程序。这个功能带来了一些意想不到的用户界面问题。
为了增强用户对这个概念的理解，我们希望自动保存是即时的，而不是定期的，并在每次保存文档时提供视觉反馈。
我们考虑使用本地存储作为临时数据缓存，然后设置一个较慢的时间间隔，将所有用户数据与后台的 Web 服务器同步。在处理可能的修订冲突场景时，这可能会产生一些不良的副作用。
有谁有自动保存模式和/或使用本地存储作为数据代理的经验，并且可以分享一些有价值的信息
We are developing a web app that uses auto save as a save pattern. With that feature came some quite unexpected UI problems.
In order to enhance the user understanding of the concept, we wanted to make the autosave instant, not periodic with visual feedback everytime the document is saved.
We thought about using local storage as a temporary data cache, and then just set a slower interval that synchronizes all user data with the web server in the background. This might have some bad side-effects when dealing with possible revision conflict scenarios.
Has anyone had any experience with autosave patterns and/or using local storage as a data proxy, and can share some valuable information
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我假设您的意思是在每次用户编辑操作（或按键或其他操作）之后？
这取决于你这里有什么数据。
如果您只有文本文档，我认为没有理由不直接与服务器交互
但我会添加一些睡眠时间，例如：
如果用户编辑某些内容，则将开关设置为edited = true，
如果最后一次提交时间超过10秒，则提交当前状态（此时文档可能已更改，使用当前状态）
将上次提交开关设置为当前时间。
我认为本地缓冲区非常复杂，并且可能带来的痛苦多于它的用处。
但是，如果您决定采用常见的方法，是以较高的频率填充缓冲区（但使用上述方法），并让它以较低的频率传输到服务器（也使用上述方法）。时间戳/增量ID从第一个缓冲区传递到第二个缓冲区到第三个缓冲区等。
当从所有缓冲区或存储服务器恢复内容时，将获取并使用最新版本（带有来自第一个缓冲区的增量 id）。
i assume by instant you mean after every user edit action (or keypress or whatever)?
it depends on what data you have here.
if you have only text documents i see no reason why not to directly interact with the server
but i would add some sleep time like for example:
if the user edits something set a switch to edited = true,
if the last commit is longer than 10 seconsd ago, commit the current state (the document may have changed in this time, use current state)
set last commit switch to current time.
i think a local buffer is very complicated and probably brings more pain than its useful.
however if you decide to the common way to do it is to fill the buffer at a higher frequency (but using the method described above), and let it transmit to the server at a lower frequency (also using the methods above). a timestamp/incrementid is passed from the first to the second to the third buffer etc.
when restoring the content from all buffers or storage servesr is fetched and the latest version (with the increment id from the first buffer) is used.