忍不住吐槽一下Flux和Redux，你们都是Facebook体量的应用？

[roytan883]

大家都是开发Facebook体量的应用吗？非要高大上的Redux？改一个isLogin要跳4到5个文件，经过7到8个函数，你们都不烦？Flux和Redux这套为了设计而设计的流程框架，真的适合大家吗？说句不好听的，真到了Facebook体量了，你还用别人家的框架？

忍不住吐槽一下是使用react体系实际项目有一年多了，antd系列是难得的高质量库。但是每次想用一下antd提供的现有demo来使用，总要花大力气来去除Flux和Redux系列的代码，真心烦。号称的解耦，其实是高度耦合。典型的理论脱离实际，搞不懂ant为什么一直大力推。别上来都以为自己是几百人团队合作，几千万用户使用。

我们自己团队只在最开始用了一次Flux和Redux流程就再也没有用过。现在使用的是MVVM架构的Mobx系列，直观高效优雅。微软的MVVM和Google的angular都是这类思想，而且都是工业化被广大使用的。真心不懂为什么react里面大家都要一股脑用什么Flux和Redux，极其难用，不说其它，项目团队里面推都推不动。

[ant-design-bot]

Translation of this issue:

---

Can't help telling about Flux and Redux. Are you all Facebook apps?

Are all Facebook developers developing apps? Do you want to have a big Redux? Change a isLogin to jump 45 files, after 78 functions, you are not bothered? Flux and Redux this process framework designed for the design, really suitable for everyone? It's not really easy to say, but it's true that Facebook is in the limelight. Do you still use the framework of other people's homes?

Can not help but Tucao is the use of react system actual project more than a year, antd series is a rare high-quality library. However, every time I want to use the existing demo provided by Antd, it is always annoying to take great effort to remove the Flux and Redux series of code. The decoupling known is actually highly coupled. The typical theory is out of practice, and why do you not understand ant? Do not think that they are a few hundred people teamwork, tens of millions of users.

Our own team has never used the Flux and Redux processes at the very beginning. Now using the Mobx family of MVVM architecture, intuitive and efficient. Both Microsoft's MVVM and Google's angular are such ideas, and they are all widely used for industrialization. Really do not understand why everyone in react must have a brain to use what Flux and Redux, extremely difficult to use, do not say the other, the project team inside push can not move.

[roytan883]

各位自行对比以下代码和在现有ant design pro里面做同样事情，你需要去看的文件和思考流程，这个成本差多少？

class UserStore {
  @observable isLogin = false

  @action async DoLogin(name, pw) {
    await this.isLogin = NetPostLogin(name, pw)
  }
}

@observer
class UiComponent extends Component {
  render() {
    return (
      <div>
        {UserStore.isLogin ? "LoginOK" : "LoginError"}
      </div>
    )
  }
}

[roytan883]

那些写demo练手的，学习框架的，学习设计模式的，不用来反驳我。
就想知道那些拿工资，做实际项目的人，你们的Flux和Redux用的愉快吗？

[afc163]

Redux、redux-saga 和 dva 都是 React 生态圈下非常优秀的状态管理工具，具体我们的选型过程可见：支付宝前端应用架构的发展和选择。

在 Redux 应用开发中，一个状态管理框架对 React 应用来说确实不是必需品。Redux 维护者本身也写了一篇文章来阐述这个观点：You Might Not Need Redux。

在我们自己的实践中，发现无论是前端团队协作（哪怕是只有自己在研发），还是和 Java 全栈工程师配合作战，如果没有一套合适的应用状态管理方案，随着项目的不断迭代，代码风格和可维护性很快就会失控。代码中会充斥各种 onXxxx、不必要的 ref 调用，层级非常深的 props 传递，额外的事件管理框架，甚至全局变量传递等奇葩用法。因此我们需要一个上层框架来统一协理，并且统一上百个前端应用的代码风格，降低迁移和学习成本。在蚂蚁内部的前端产品研发中，我们也是统一推行基于 dva 的 redux 解决方案，并且 Redux 的概念非常简单清晰，生态圈也异常活跃，可以享受到很多 middleware 和开发插件的优势。

楼主如果认为 redux 不是最好的解决方案，也可以分享一下自己在前端应用研发中是如何解决组件数据共享，深层次的数据传递、代码一致性和可维护性等问题的。

[afc163]

关于 Redux 和 Mbox 的对比，也可以看我们工程师总结的文章：sorrycc/blog#5

[roytan883]

@afc163 以阿里和蚂蚁的体量来说，你的说法没毛病😄
但是以用户端来说，就像马总天天说的，为了帮助中小企业。但是中小企业，有多少是需要用这样体量和复杂的框架来开发，来组织自己的数据业务流的。我这里吐槽的原因，也是基于这一点。

[chenshuai2144]

Redux的却是有点复杂，一般中后台应该就是单纯的展示数据。 也许可以试试新的context

[afc163]

我们内部的大量中后台项目和中小企业的项目并无二致，基本上就是类似 http://preview.pro.ant.design/ 这样的控制台页面，更多还是表格的增删改查，我并不觉得只有类似 Facebook 首页这样级别的产品才用得上 Redux 或者 Mbox。

[afc163]

我个人觉得 Redux or dva 对于中后台研发的意义不只是在数据流或者跨组件传递上，更多是传递了一种编码约束。有经验的前端工程师就算是什么也不用，只用 smart component + dumb component 也可以组织出非常清晰优雅的应用框架。但是对于水平一般的前端和非专业的全栈工程师来说，没有约束就是魔鬼，代码腐化的速度是惊人的。当然我不是说用了 dva 或者 redux 就写不出烂代码了（比如我也见过非常奇葩的给每个 component connect 整个 store 的），但至少能给一线工程师一个好的方向和必要的约束。

[chenshuai2144]

Antd cloud为了简化使用就干掉了状态管理 Table传入一个url剩下的全部交给框架！ 感觉也很爽

[roytan883]

@afc163 可能你在阿里这样的企业呆久了，忽略了外面的中小企业的开发团队的人员构成，更多的参差不齐和思路各异。而怎么样在中小企业的技术团队里面推进新技术，个人认为Redux难度起码是Mobx的3倍。
作为技术和项目的管理者，我推广了一两次Redux以后，自己在反思，得到什么。结论是花了更多的资源，得到了一个看似美好的代码与框架，而实际上又脆弱不堪，甚至开发人员为了赶进度会搞一些超级全局变量和各种hack。真实的体会是理想与现实的距离。

[roytan883]

当然吐槽归吐槽，从技术的角度，Redux和Mobx各有优缺点

[afc163]

Mobx 和 Redux 确实是各有所长的，这个看自己团队的土壤去推行就好了，我们选 Redux + dva 的历程也不是一帆风顺的。

（说点不负责任的个人私货：用 Mbox 更像是 vue，如果 Mbox 比 Redux 好推，感觉是不是应该直接用 vue）。

[chenshuai2144]

也许我们可以想办法尽量不要使用状态管理。
很多场景状态管理本身就是负担。类似Table这种的 只是展示 交互也特别简单。只要传入一个url就好了

[afc163]

类似Table这种的 只是展示 交互也特别简单。只要传入一个url就好了

需求上的扩展怎么办呢，所有的功能都做到一个组件里么。

[roytan883]

@afc163 Vue的生态圈太窄了。React结合Mobx，用在React Native，Electron，Web，几乎涵盖了所有平台。而且Mobx的思路和React一致，只做一个层面的事情，Mobx只关心数据的管理与通知，这也是为什么喜欢React和Mobx的最大原因。

[roytan883]

@chenshuai2144

Antd cloud为了简化使用就干掉了状态管理 Table传入一个url剩下的全部交给框架！ 感觉也很爽

其实我没理解到你这话是什么意思。。。

[roytan883]

之前是直接使用antd和antd mobile，倒还好。这次想复用一下pro，快速撸一个后台，用于管理一个小应用的配置和数据。
现在我有点纠结了，是在现有pro上面改（去掉Redux改为Mobx），还是自己来重新搭建。。。两难

[afc163]

@roytan883 Fork 维护一个 ant-design-pro-mobx 吧，就和 https://github.com/boxcc/umi-pro 和 https://github.com/pythonsir/wx-react-app 一样。

[afc163]

好像已经有一个类似的了：https://github.com/dore-engineer/ant-design-pro-typescript-moxb

[roytan883]

@afc163 看吧，这又是理想和现实了。

现实是我想快速撸一个管理后台让新项目里马上能用，不耽误其它模块（工期卡在那里的）

理想当然是自己慢慢来撸一个mobx版本的antd pro，把现在里面的Redux和Dva系的全部干掉，换成超单纯的React + React-Router + Mobx

[chenshuai2144]

<Table url="/api/info" params={} />
这样一个 table 已经能满足大部分需求了

[roytan883]

@afc163
哈哈哈，其实，最根本原因，是我们弄了一套基于OpenAPI（Swagger）框架，自动生成API文档和模型说明，以及生成各个平台各种语言的数据模型和API调用代码。

所以，对我们来讲，干净的React，Antd，React-router，Mobx，Swagger Model + Api 组合在一起。涵盖了几乎所有层面的大部分工作，让开发人员可以专注于业务逻辑的开发。这也就是为什么每次我们都要剥离Redux和Dva体系的原因。

[afc163]

<Table url="/api/info" params={} />
这样一个 table 已经能满足大部分需求了

这种 API 灵活性太差，不是好的 React UI 实践。不过在业务同质化非常高和定制需求 0 的 CRUD 页面有一定的业务封装价值。

[chenshuai2144]

不同意，这种 API 灵活性太差，不是好的 React UI 实践。

但是速度非常快，如果需要更灵活的，可以自己用 Table 做一个

[kunhour]

用dva还好，要是直接用redux和saga去做，确实挺费劲；还不如直接用mbox；
如果dva和mobox半斤八两。

[okoala]

但是速度非常快，如果需要更灵活的，可以自己用 Table 做一个

这种都属于另外个 level 了，不可能在这里做，但是确实是有根据接口协议生成界面的方案。目前来说 dva 确实是比较理想的选择。

[liumin1128]

@roytan883 在下同时负责多个react,redux项目，深感过度redux是非常痛苦的，随着项目越来越大项目越来越难维护。。。但，可以封装再利用啊🙂。

细化颗粒度，抽出可以复用的部分，将重复又丑陋的部分藏好（redux还是蛮可靠的）。

关于全局数据、页面级数据的使用方法：

export default connect(
  ({ crm, loading }) => ({
    ...crm,
    fetchLoading: loading.effects['crm/fetch'],
  })
)(List);

这个组件在dva下的modal，其他redux形式也类似：

const namespace = 'crm';

export default {
  namespace,
  effects: {
    fetch: fetch({ namespace, api: CRM_SEARCH }),
    fetchOne: fetchOne(CRM_SEARCH),
    create: create(CRM_CREATE),
    update: update(CRM_UPDATE),
  },
  reducers: defaultReducers,
};

通用fetch的具体实现，其他类似：

export function fetch(args) {
  const options = typeof args === 'string' ? { api: args } : args;
  const {
    api,
    namespace,
    globalQuery = defaultQuery,
    resultChecker = defaultChecker,
    resultFarmat = defaultFormat,
  } = options;

  return function *f({ query = {} }, { call, put, select }) {
    try {
      const { [namespace]: { list: _list = [], query: _query } } = yield select();
      if (_list.length === 0 || stringify(query) !== stringify(_query)) {
        const params = { ...globalQuery, ...query };
        const data = yield call(runt, api, params);
        if (resultChecker(data)) {
          yield put({
            type: 'save',
            payload: {
              query,
              ...resultFarmat(data),
            },
          });
        }
      }
    } catch (error) {
      console.log(error);
      message.error('系统异常');
    }
  };
}

当然，即使如此，修改一个页组件，依然要动两个文件（view和modal），再不行就上ql吧。

至于组件级的数据，放在组件内部就好了。

[roytan883]

@liumin1128 现在我这边很多总共只有5~8个页面的小应用，我目前已经简化到只有GlobalData，GlobalStatus，GlobalMethod， 3个全局Mobx对象了。页面级别直接绑定前两个对象的Mobx观察值，组件则用标准props传值进去。既清晰也简单，组件复用度也高。

选用适度的设计模式才好，我一直觉得Redux和Dva这套东西有些过度了，体量和业务复杂度真有那么高才需要用。

Dva这类React的配合框架生态我其实感觉有点违背react的思想。总是想做整体解决方案，但其实这不是react提倡的。看看现在的react-router这类用户很多的库，它们都只专注于做好某类或者某个方面的事情，用不用选择权在用户。Dva这类框架有个致命问题，木桶效应，很难保证自己各方面的高度，路由，模型，通信，数据流等等，而且估计他们也没那么多人去维护把每个部分都做到顶尖。这样出现的问题就是上了船，开始感觉很舒服，但是当发现船上某个地方不好要改的时候就痛苦了。

这是我目前使用的组合，每部分每个层次都独立可定制，生态圈也挺好：
React + React-router + Antd（material-ui）+ Mobx + SwaggerAPI（SuperAgent）+ Webpack + Babel7

另外async/await 比yield/*f 看着和用着舒服多了，现在node和browser都支持

[sunny920406]

目前在做前端整合，一开始页面所有的状态都交给dva（Redux）管理，简单的页面还好。但是到复杂的页面（主要是交互多）时候，状态全部交个dva管理反而会导致页面性能降低（卡顿）。我的总结是全局状态交给dva,内部状态还是自己管理。

[liumin1128]

material-ui 、antd，redux + graphql

其他的随意

PS：有了新版context api，很多地方可以不用redux、mobx了

[HelloHxz]

mobx确实是很清新，代码量少，无论是学习编写难度以及后续的优化难度都比redux少很多很多·

[yeyuguo]

redux 刚上手的时候，真的是想吐槽有必要用那么复杂吗？但是项目越搞越深后，我想着自己简单写个数据应用能在项目里解决我的痛点就行了吧，按照需求来设计的时候，又回到了 redux 上来，这才感叹一句：redux 的业务数据和ui分离的真的太棒了！

[yyhuaisha]

mobx最近很火，是时候上手试试了

[sxlvalue]

我之前只做过react native的项目，感觉mbox确实比redux方便很多，redux要明白一大堆概念，mbox简单明了模型驱动，模型里可以有数据，也可以有action,这就是一个数据或叫状态，所有VIEW只是状态变化的一个展示。

[sxlvalue]

redux我硬是把那本书啃完了，最后项目上也没人愿意用，太费劲了。

[terminalqo]

mobx 就像德玛西亚，简单易上手，dva这套就像妖姬。 Faker: ???

[xiaohuoni]

很精彩的讨论。但是我觉得在中小企业的团队里面，推umi+dva应该是非常容易上手的。我带过实习生，一星期就能直接上手做业务的，而且，我都不用担心，他做的页面爆炸。分文件的形式，很好维护的，甚至写的实在是烂的不行，可以把整个文件夹删除。重新来过。关于mobx版本的adtn-pro。我觉得，其实可以试试umi+antd+umi-plugin-mobx-state-tree+ant-design-pro

[Cygra]

redux配合redux-thunk和redux-actions来入手学习应该说整体逻辑是很清晰的，之后再来学习saga、dva等等。

[codthing]

看你们讨论得那么热闹，我也想表达一下自己的看法，现在前端的代码量是服务端的好几倍甚至十倍，大家不觉得走错路了吗？我觉得迟早有一天会变革，但创造者不会在大陆。

[ctq123]

现在我选这一套antd design pro 也是非常痛苦，看demo感觉好强大高大上，但其实开发流程反而复杂了，前端代码比后端还重，正如楼主所说，其实我们要的就是既快简单，又能直接上手的脚手架，有些东西封装得太好，要修改起来反而很痛苦

[ctq123]

我觉得这一套封装得太好了，正是太好了反而不好，耦合度不要太高了。我们是不是应该从用户的角度考虑，将初始的小盒子交给用户，各种功能拆分开来，将选择权真正交给用户，让用户选择。

[zjafei]

这样的组件 很有想象力啊

[owendswang]

今天2019年3月21日，我一个写过微信小程序前端后端的人，被这个数据传输部分难住了，这个redux太复杂了……ant design pro的demo是很好，但数据传输这块，我真的不知道咋办了……

[whatwg6]

我觉得楼主没有深入了解和非常全面的使用过 redux

[roytan883]

@77xi

我觉得楼主没有深入了解和非常全面的使用过 redux

我觉得你是没有看上面大家的回复，你有真实带过团队？

react的哲学本来就是专一，每个部分聚焦自己的纯粹功能，在react上面搞这个大而全的东西，为什么我不去用更严谨更全面工业化的angular？

[chloesun]

有同感，我想用ANT DESIGN PRO， 但是也是被DVA等等高大上的库拦住，不想特意增加项目的复杂度，想用CONTEXT 和GRAPHQL 取代复杂的状态管理， 看到这篇文章 高效的 GraphQL + Antd， 希望官方能出一些教程，可以灵活地使用ANTD PRO和GRAPHQL, 谢谢

[yezongyang]

一个state 的事，用了redux 更加复杂化

[lirenhao]

那为啥还用react？用vue不就得了

[simpleman315]

ant-pro不是银弹，redux不是银弹，适者用之，任何事物刚好适合才是最好的，但是框架设计者往往很难把控这个度，ant-pro的设计愿景应该就是一个大而全的整合式脚手架，而不是一个可插拔的渐渐式脚手架，从生存能力讲肯定是集合了越多功能的东西生命力越脆弱，但是它的使命就是在有限的生命力做出力所能及最大的贡献，这就好比人类和病毒的区别，病毒简单所以生存能力强，人类机体复杂随便哪个器官没了就不行了，ant-desing感觉就比较聪明，本来就是一个react组件库，它硬是把设计理念加在上面，react不久的将来会死，设计理念将会永存。

[pxim]

好用才是真理，入门就使用Redux ，后来用了Mobx，就删了以前的Redux , 代码量，组件污染，嵌套层级，都不是一个级别。redux只是占了先手，我觉得用这两个都做过实际项目，才有资格评论。不是光看看文档。

[roytan883]

就我知道的，围绕着antd，他们自己官方都出了几个轮子大框架了，什么dora，dva，umi，......, 大公司，各种轮子自己造，后来团队打前面团队的脸。外围的我们难道也更着起哄，有空大家自己去看看，这些kpi项目，有的已经两年不更新了，不知道当时上船的人现在什么感想。（昨天我发现，我们有一个小项目，那个开发人员用的当时官方推荐的dora，现在把项目转手给新人运维，完全搞不动，上去一看dora那个轮子项目已经死了两年了。。。）

我还是这样认为，在我接触过用过的阿里系项目里面，唯一靠谱的，就是单纯的antd本身，其它都是kpi或者个人兴趣项目，用了都坑，大家自行体会。比如最大的那个坑：Weex

靠谱的还是：react，react-router，webpack，create-react-app，mobx，redux，这些标配，起码不会用着用着就GG了。现在来看，其实投入成本来讲，反而划算，虽然前期自己弄费事一点，但是搞懂了，可以一次用几年。不想这些阿里的轮子，学起来用起来当时是快，各种爽，但是没多久就挂了，然后又用阿里的新轮子，重复这个过程。总结来看反而没有前者省事。

[empty916]

@roytan883 那就推荐你使用natur了😂

[20ikun]

今天2019年3月21日，我一个写过微信小程序前端后端的人，被这个数据传输部分难住了，这个redux太复杂了……ant design pro的demo是很好，但数据传输这块，我真的不知道咋办了……
前端的很好解决，用官方的IDE工具，我不太推荐使用Uniapp等等一端发布多端通用的IDE，始终只是在技术和工程化层面实现了灵活性，微信、支付宝、抖音、小红书他们的宿主环境是独立的，而不是相互依赖的。每个小程序为行业提供的业务支持能力、方向都是不同的。成熟的官方API和模板语法，主打的轻量运营。用redux，react等框架语言反而舍近求远，跟楼上讨论的概念是一致的，找到适合自身所在业务的开发方式。