flutter的 redux,应该用还是不应该用.

flutter也算是火的了.

涉及到主要问题就是状态管理了,现在状态管理框架也非常多.其中redux就是从前端来的概念,也有人移植到了flutter里面了

阿里也出了fish-redux,这个定位是,不只是一个状态管理框架.

各种努力之下,我也用了一下redux,fish-redux.当然这些设计是非常优秀的.但是问题来了.

我花的时间太多了,我浪费了好多时间,画了类图,序列图,弄清楚了它是如何工作的,然后开始写代码了.

一堆的类,文件,函数,头疼.而且示例中的view,reducer,effect,名字也一样,当你看到一个函数,区分不了它是哪个文件的.

 

我下载了闲鱼,初步一看,apk里肯定是有libflutter.so, 但是我看到了更多的classes.dex,还有其它的东西.我不知道闲鱼有多少页面是用flutter开发的,只是猜测,也许只是一部分,甚至是一小部分用上它.

 

rn的时代,很多项目是用了rn,但是少有整个app用rn的,多数还是native为主,rn为辅,当年花了很多力气在rn上面,然后收益甚微,这难道要发生在flutter上?

还没有见过大型的app,全部,或是大多数用flutter开发的.

假如用它,更多的场景是,我在一个原有的大中型app上,嵌入部分的页面,但依然是native为主.

一个中小型的app,为了省时间,人力,资源,可能用它开发.

 

于是,我开始怀疑了, 如果我只是嵌入了少量的页面,我为何要用redux,它是贫血模型+reducer==oop ?,单向数据流.算是一种新的编程思想,我不关心它的好与坏, 但是它的成本高很多,虽然状态只能通过reducer改动, 也好管理, 可是我认为它的成本大于收益,就算只是简单修改一个属性值,我还是要写一堆的'无用'代码,我心累.

考虑到google的官方推荐provider,我开始认为,这也许是一种更好的方式,redux也许很优秀,react的前端还有许多框架,插件,来配合这一套操作.但是函数式的方式,难懂,我宁愿选择oop.因为我已经习惯了.我用flutter是基于成本, 效率上的考虑,但我用了redux, 洽洽又把这优势抵消了.

有人会怀疑,后期维护性,扩展性的问题, 但你要考虑到,80%的页面,都是简单的业务,真有必要考虑到这些?而且用一个优秀的框架,就能保证业务不会写烂? 是不是没见过用了spring,但业务依然写的很烂的, 难道是spring的错?

更新一个东西,我要发一个action,修改还不在这里. 除了一堆看似莫名其妙的函数, 我已经不想写代码了. 

用上flutter的app, 有多少是因为省资源的,假如为了省资源,那么开发人员很可能只有一个, 或是三四个, 那么不存在协作的问题.

 

于是,我的结论就是:

一个原有的app,嵌入的页面数量不大,功能不复杂,也没有那么多共享的状态需要管理. 就不要折腾自己了.provider更好.

一个新写的大中型app, 多人协作开发, 不仅共享状态,也可能多团队中共享基础业务, 我有理由使用redux,fish-redux, 因为它们更规范.

flutter_redux具有了redux的所有缺点,因为它基于redux写的.全局一个状态, p大点事,也要放全局, 这合理么?

fish_redux,为每一个page创建一个store,bus,等.这些页面销毁后,store也销毁了.它是基于redux的思想,但和redux这个库无关.当然它也有全局的store,假如要实现页面间的共享,同样还是,p大点的东西也要放全局. 产生的类尤其多,上层组装,下层实现,一个简单的页面,上下两层要10个文件.假如业务大了,那么可以看到一堆的view,reducer,state...... 函数名,文件名, 我更头疼了, dart也不要求类名与文件名一致, 顶级函数更是写哪里都可以.

等我更深入地理解了函数式编程, 我再来考虑这些东西吧.我只是一个习惯了oop编程思想的程序员.

 

除了根据嵌入的业务量来考量,人力成本也不可忽视,redux,单向数据流,reducer+middleware操作时,也没有上下文,只能用旧的状态复制出新的, 处理完成要根据各种状态进行判断, 晦涩难懂,虽然代码量极少. 

不可否认,它的设计是优秀的, 我想,如果整个app用这一种方式, 会是不一样的结果.可是rn也好flutter也好,都是半路出家的,不可能替代了native.所以它就是庶出,继承不了家产,于是这种方式,有时成为了一个负担.

不能因为一个女人长的漂亮,就认定她聪明,能干,有修养,颜值就是正义.