ReactRedux的问题

React发展到目前，各种框架层出不穷，Redux目前相对知名度更大一些。

Redux在我们目前的app中，也有过几个模块的尝试，替换了正常的业务。目前redux将会被我们全部移除架，我们自己写了一套业务数据处理库，回到了简单的用state来刷新页面的简单逻辑。

不能直接的说redux不好，毕竟我用的不多，很多问题，可能是我们不会用造成的，我只说说我遇到的典型问题吧：

1

Redux采用函数命名调用的方式，打断了代码可读性与可调试性。正常的函数这么调用：

fun(param);

Redux里面竟然这么调用 dispatch(“fun”, param)；这个体验非常糟糕。用switch判断字符串然后决定去执行哪个步骤，不符合正常的代码逻辑了。导致可读性和可调试性都下降了不少。

2

本意是用Redux来简化业务，但发现越搞越复杂。一个页面通常有多个网络请求，可能网络请求之间还有关联，有前后关系，dispatch一个接一个的。Redux的Action越搞越复杂了。在改用我们自己的封装库之后，这个问题变得异常简单，业务处理好逻辑，只返回界面需要的数据，界面回到了简单的setState来处理，不用理会数据来源与处理问题。

3

状态传递问题，从顶层的 provider开始，一级级往下传。这个非常不合逻辑，重构与写代码都觉得无比麻烦。我们自有业务库则直接脱开了这个链路，主页面会自动把数据异步通知过来，各个控件则可以选择监听业务数据改变事件，不需要从根节点往下传状态改变了。

4

明明是一个业务，代码分散到好几个文件夹，reducer, action, store。坏处自己体会吧。我们业务库里面则一个业务的代码基本上在一个文件夹下面。

5

redux把所有状态都存起来，页面不用处理state了。只要响应props的改变即可。这种情况可能适用于一个数据改变很多页面。实际上这种情况在我们的页面里面非常少。多个页面的数据共享，在我们的业务库里面也可以做到。

一个App，不管底下框架如何，简化后都是业务数据处理，然后界面显示，flux, redux,mobx等等，都不例外。

正常的React，只需要把业务数据设置到state里面，页面就会自动刷新。Mobx则直接监听数据的改变。Redux则是把数据全部放到props里面，通过各种connect，bind等打通props和store的连接。

业务复杂后，业务代码和主页面分离，保持独立性和业务可移植性，比如业务要移植到其他平台（微信小程序），Redux在这方面就做的不好了，基本上还是在一个项目里面。目前我们的自有业务库则是一个独立的项目，适配很多平台。界面就只做界面的事情，响应state改变即可，经过这种剥离，页面又回到了简单的setState，非常易用。这让我想起来十几年前，学ACE的一句话：学之者生，用之者死。合适才是自己的吧。

转自自己的新浪博客：http://blog.sina.com.cn/s/blog_74661d9f0102x8rb.html