最近键盘出了点问题，总是一个键一个键的失灵，键帽拆下来戳一戳又好了，说实话，很烦，敢问巨友这是什么原因？
鲁迅曾经说过：
好的框架或者程序，并不是代码多么复杂或者高深，而是解决了什么问题，用起来爽不爽。
react用的比较多的朋友应该知道，redux-thunk(promise), redux-sage(generator),和 redux-observable(rx.js)这几种异步解决方案应该多多少少都听过。
thunk属于基础解决方案，这里暂且不谈。
我们先来聊一聊redux-observable 和 redux-sage的区别。
redux-observable
这是一段进行表单分页的redux-observable的代码：
image.png
说实话，简简单单不到40行代码，从读数据，到分页和loading就已经完成了，而且不会出错。会帅是不是？而且redux-observable自带各种操作符，很开心^ . ^
redux-sage
这里暂时没有，redux-saga的原生代码，我贴一段基于dva的代码，但是写法基本一样，重点看effect。
image.png
effect部分对应上图，也是对于一段异步数据的获取。说实话和observable的流程差不多。因为原理上和都是在dispatch之后，基于action.type做了一段副作用的处理。
两者选择
表面上看的话，我选observable，为什么呢？
1.逼格更高，有木有？
2.对数据的处理能力更强（基于fp）
但是我更看好redux-saga。为什么呢？仔细观察observable的代码。基于链式调用，fp的缘故，函数层层嵌套。
image.png
观察这里，如果代码写了一半，我想把switcMap干掉，后面的代码该如何修改?我只能说，非常痛苦，非常难改。不是observable不好，只是redux-observable对epic的封装上面，是否能有更优雅的解决方案？
dva
我觉得dva被推崇的地方，我们抛开一切外界因素不谈。我们仅看看dva的api设计。
image.png
image.png
第一次看到dva的时候，不觉得惊艳，不就是对于redux-saga在于应用层的封装吗？
当时我们的项目，还是基于redux-thunk的。有一些让人很难受的地方：
1.无尽的action.type的引用
2.无尽的reducer与reduce的编写
3.无尽的新建文件夹
后来我们自己针对开发中的通病，封装了一套基于thunk的东西，它可以，简化type,自动匹配reducer。后来再次看到dva的namespace,model,effect的时候，猛然发现这个不就是我们不断抽象封装的方向吗？
最后
程序是什么？
程序不也是人发明的吗。
任何东西都得符合人类的思维逻辑，就跟tcp协议3次握手一样。
“hello，服务器。”
"什么？你会english?"
"yes,let me make a love" 。（一段美丽的爱情故事...）。
tcp 4次挥手，如下：
“我们离婚吧，阿帕奇，你那个不太行。”
'什么？ 还不行？ 让我冷静冷静。'
'那就离吧，我不想大海捞针了。'
‘嗯，离。’
就像vue一样，很多人喷它low，新手专用，但是它就是火，为什么？简单，好用。
所以，一切能快速解决问题的东西，就是好东西。
网友评论