我知道我们前端圈很有意思，一天一个框架，但是...

[ruanyu1]

但是我又写了一个，因为是真的没找到合适的。

前提是我们有一个 10w+行代码的 react 前端项目，并且还在不断膨胀。

在过去的几年，我们一直使用的是 pure redux 的方案，顶多加一个 reducer map 和 redux-saga。 但是项目发展到今天，主要有以下痛点和需求：

• 小伙伴们写 redux 的 boilerplate 写到怀疑人生，迫切需要降低这方面的工作量。并且过多的 boilerplate，在重构的时候真的是噩梦

• 因为我们的项目代码量已经挺大了，全部用新框架重写是不可能的，所以这个框架必须足够轻量级，能够和现有代码共存，然后平滑迁移。

• 必须是‘ strong ’ typed，TS 对于代码量比较大的项目，是真的好用。

• 虽然有“模块”的概念，但是模块间的相互交叉，没有非常清晰的边界，导致其实模块很难被复用 /或者 code-splitting。这种结果是目前这种 setup 下很难避免的。

• 团队有不同经验的组员，在不同的国家。代码质量非常依赖 code review 和约定的 convention。code review 会消耗很多的时间，大家都不太乐意干。

---

基于以上的这些需求，于是便有了：

Reapex: https://github.com/ruanyl/reapex

相较于 pure react：

1. 极大的减少了 boilerplate
2. 模块动态加载
3. 支持 plugin，一些基础模块可以写成 plugin，方便在不同的项目复用
4. 通过框架来统一编码风格，适当的降低了 code review 的工作量

目前已经和我们的代码库整合，小伙伴们脸上又洋溢出了笑容 :) 欢迎讨论 /赐教，如果你觉得项目对你有帮助，please give it a star!

[KuroNekoFan]

看过很多人说讨厌 redux 的繁杂的，有点好奇，以我自己使用 react-redux 的体验来看，如果不遵循 cookbook 里面的 boilerplate，只使用 connect 和 dispatch，体验挺好的啊...

[luoway]

轻量级意味着高自由度，楼主的情况更应该往重量级框架迁，否则一个项目里杂揉三四个轻量级框架，只会越来越糟

[ruanyu1]

@SingeeKing 你说的有道理，我看看这么移动节点，找来找去没找到怎么操作

[russian]

总比机器学习圈要好。
这个圈里充斥了一堆代码写的很差的。。。真的是只懂机器学习算法的，然后写出来的 python 代码连调包都丑的一逼。然后不断有 bug，一直要改。

[rmlzy]

贵圈真乱

[rmlzy]

https://github.com/rematch/rematch

了解一下

[xichengh]

dva 好用

[IsaacYoung]

dva 下 一 题

[rrfeng]

跟风提一下 Angular （

[shadeofgod]

大概看了一下，例子只有一个 counter，你们是怎么处理 side effects 呢？

[shadeofgod]

用不用 ts 和 redux 没什么关系吧，那是工程化的问题，和用什么框架无关。
我们是个大概四十万行 js 代码的 electron app，以前是用的 dva，不过因为 dva namespace 和 action/reducer 一对一映射这两个糟糕的设计早就不用了，大到一定程度的话还是上数据库好。。。

[cjh1095358798]

厉害厉害，入圈感受，简直框架多到眼花缭乱。。

[mritd]

前段圈=娱乐圈

[paloalto]

export default connect(({ products }) => ({
products,
}))(Products);

dva 的代码这么丑吗？

[lonelygo]

下午面试前端，问：你怎么看前端圈子没事干就写个框架出来的现象？

[ruanyu1]

@shadeofgod 是的，用不用 ts 和 redux 没有关系，其实我想说的是，我没有找到一个我需要的并且是 strong typed 的 lib 来使用，我们需要从 action 到 state 都是 type-safe 的。所以才基于目前开发所遇到的问题和经验，做了一个小的总结。

effects 的处理在这里有例子： https://github.com/ReapexJS/reapex-example/blob/master/src/GithubSeacher.tsx

namespace 和 action/reducer 绑定，其实我觉得是“框架”层面制定的规则，是 dva 有意为之，这样能强制使用者在编码的时候去思考模块的边界。降低模块之间的耦合，增加代码的复用性和可维护性。

但是我并没有选择这样，`mutations()`和`effects()`都能接受其它 namespace 的 action。因为我们项目目前的情况无法做到这一点，而我们又无法重写整个项目，再者，我觉得没必要去牺牲这一部分的灵活性来换取所谓的模块化。

[ruanyu1]

准确的说是模块化和灵活性的一个 tradeoff @shadeofgod

[thelderfrog]

https://github.com/andycall/RCRE

[ruanyu1]

@ByZHkc3 @gxm44 @xichengh @IsaacYoung @rmlzy
dvajs 和 rematch 都有了解过，但是并没有满足我们的需求：
1. type-safe
2. less boilerplate
3. lightweight, 易整合，能和现有项目共存，然后平滑迁移
4. 模块化

dvajs 和 rematch 都很好，但是都或多或少的无法满足部分需求。

[ruanyu1]

对于说“贵圈真乱”的，其实我觉得前端圈并不是乱。而是前端的开发者多，技术栈相对开放，所以就有很多造轮子的空间。不过我不觉得这有什么不好的。同样的整天写业务代码和 CURD，也不是全都好。

顶尖的开源项目不是每个人想写都能写出来，前端的开发者愿意在自己熟悉的领域思考和动手，并且分享出来，我想大多数人希望看到的是他人的肯定或者质疑。V2EX：“请尽量让自己的回复能够对别人有帮助”