-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: persisted storage #531
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## master #531 +/- ##
=======================================
Coverage 83.02% 83.02%
=======================================
Files 96 96
Lines 5832 5832
Branches 458 459 +1
=======================================
Hits 4842 4842
Misses 984 984
Partials 6 6 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
Preview DeploymentSites https://pr-531-sites--bangumi-next.netlify.app Storybook https://pr-531-storybook--bangumi-next.netlify.app |
const _id = `resume:${id}`; | ||
const item = sessionStorage.getItem(_id); | ||
if (item) { | ||
sessionStorage.removeItem(_id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
页面崩了咋办,数据丢了?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
页面崩掉要分几种情况吧。
如果是 throw Error 那种不会导致整个组件崩掉,状态还是会在的,而且如果是这种错误应该我们这边处理一下(比如解析 wiki 错误加个弹窗之类的)
如果是整个页面崩了,就是状态都没了的话是什么情况呢,不太清楚怎么触发这类错误🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
页面崩掉要分几种情况吧。 如果是 throw Error 那种不会导致整个组件崩掉,状态还是会在的,而且如果是这种错误应该我们这边处理一下(比如解析 wiki 错误加个弹窗之类的) 如果是整个页面崩了,就是状态都没了的话是什么情况呢,不太清楚怎么触发这类错误🤔
比如浏览器某个页面卡死了,用户只能用任务管理器强制 kill 掉浏览器?总之是那种非正常的退出?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
这种存储策略,非正常退出应该没办法~就是正常退出,比如用户直接叉掉页面也是没办法(
针对这种的话可能用实时缓存好点?然后加个 throttle 之类的。
这个用在维基编辑页面会不会导致用户因为版本冲突而不消息覆盖掉其他维基人的编辑版本? 比如在 A -- B -- C 的纪录上用户之前保存了基于A的编辑纪录,然后另外的维基人创建了版本 B 和 C,然后用户再次进入页面的时候本应该是基于C做修改的,但是显示的是之前存的基于A修改的纪录?🤔 现在的 key 用的是 这个功能加在日志/发帖功能保存写一半的内容还可以,加在维基编辑页面感觉没太有必要 |
是会有这个问题,感觉这个功能加在维基确实没必要。 |
那为啥还加() |
没考虑到这个冲突问题( |
现在这个wiki页面是改了什么?没太看懂( |
Wiki 页面现在基本没改,只是把一些数据的初始化拿出了 useEffect |
说到编辑冲突,那现在维基是怎么处理编辑冲突的,就 A B 一起编辑,然后 A 先提交,B再提交,B 覆盖了 A 的编辑。 |
编辑被覆盖掉。 这个等再解决一下 |
持久化存储
在退出页面时存储,进入页面时消费
目前该 pr 对 website 不产生影响,只是增加了一些工具