We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
sync 里说可以返回Promise,可以返回Promise没有响应,但是resolve和reject是好的,影响不大。 另外一个建议: 最开始看到sync这个功能的时候,眼前一亮,我第一感觉是这个可以让storage做一个中间层,请求过的数据自动保存在storage,所有请求全部放在sync里。实际发现如果不手动save,及时经过sync获取的数据仍然不会自动保存到对应的key里,这样这个sync存在的意义就没那么大了。 建议作者考虑一下这个需求,至少可以增加一个开关,这样就变成如果storage有则使用storage,没有则请求api,而请求过一次,自动保存,下次直接从storage取了。至于过期和刷新数据使用者自己处理就好了。 我现在就是自己蹩脚的每次从sync取出来手动保存一下。
The text was updated successfully, but these errors were encountered:
手动save一下并不费事吧,你也完全可以封装一个自动save的方法,在所有的sync里调用嘛。一般来说,服务器拿回来的数据多少需要处理一下吧?(比如报错了怎么办?) 像这样的需求五花八门,都做成配置显得有点繁琐
sync返回promise说实话我还没测试过,代码有点老了,有空我再重构一下。感谢建议。
Sorry, something went wrong.
受这个库的启发,我也捣鼓了个库,有这个同步数据的功能。 大兄弟 @whyming 可以看一下 https://github.com/tuateam/tua-storage
No branches or pull requests
sync 里说可以返回Promise,可以返回Promise没有响应,但是resolve和reject是好的,影响不大。
另外一个建议:
最开始看到sync这个功能的时候,眼前一亮,我第一感觉是这个可以让storage做一个中间层,请求过的数据自动保存在storage,所有请求全部放在sync里。实际发现如果不手动save,及时经过sync获取的数据仍然不会自动保存到对应的key里,这样这个sync存在的意义就没那么大了。
建议作者考虑一下这个需求,至少可以增加一个开关,这样就变成如果storage有则使用storage,没有则请求api,而请求过一次,自动保存,下次直接从storage取了。至于过期和刷新数据使用者自己处理就好了。
我现在就是自己蹩脚的每次从sync取出来手动保存一下。
The text was updated successfully, but these errors were encountered: