前端精读专栏，给大家拜年了！

趁着过年，先聊几句咱们前端精读：

前端精读不仅仅是知识的搬运工！前端精读不仅仅是知识的搬运工！重要的话重复两遍。

论搬运知识量，我们比不上前端周刊；论翻译水平，我们比不上专业翻译计划。各位读者也一定不是冲着这两点来的，恰好，我们也不是为这两点做的。

前端精读能带给读者的，是对如今互联网海量信息的思考能力。

想这么一个问题，当人人都能订阅鱼龙混的前端消息，真的是每天扫一眼就天下大势尽在手中了吗？说的不好听一点，可能啥都看个皮毛，最后什么都跟不上。

更可怕的是，多如牛毛的消息早已钝化了我们的神经，让我们养成了浮躁的性格，似乎提到一个单词，点一个头就心领神会了，其实什么也不会。而当真正好的思想出现时，可能已经被淹没在质量层次不齐的海洋中，就算有眼力识别出来，也早已对其麻木，更何况大部分人还做不到辨别消息的质量。

以前，前端精读想把有误导性的，不正确的文章挑出来加以指正。现在发现行不通，其一是具有误导性文章太多，实在是挑不完，其二是现在更多的文章如同白开水一般，味如嚼蜡，你挑不出毛病，但也挑不出亮点。

所以前端精读把我们认为有价值，值得大家关注的东西挑出来，深入的写一篇读后感。也许不是每一期选题都值得深入了解，但我们只求在广袤的知识沙漠中，画一个小圈，不断扎根。

好了，废话不多说，本周精读的文章是：[introducing-rekit-studio-a-real-ide-for-react-and-redux-development](https://medium.com/@nate_wang/introducing-rekit-studio-a-real-ide-for-react-and-redux-development-baf0c99cb542)。

## 1 引言

以前，我们不断完善前端基础设施建设，现在前端不缺工具和库了，下一步怎么发展？

发展方向有很多，比如继续完善框架和库、争论数据流的取舍、推动 ECMA 规范打造未来蓝图、投入新语言的怀抱、可视化规范与平台的建设等等。

有一个没啥技术含量的领域正在成长，就是前端工具链整合。

我这里说的没技术含量可不是贬义，所谓有技术含量的 “造轮子” 才是贬义呢。当我们陶醉于前端技术能力时，产品和后端往往就认为我们是写网页的，根本没啥深奥技术，如果改个文案都喊着成本高，更会被人看不起。

前端的职责就是提升人机交互体验，这不是大话空话，蚂蚁的体验技术才代表了前端技术的精髓，代表了互联网大行业对前端的期望。

前端工具链的整合，拿的都是已有的技术，目标也是把复杂的项目维护变简单，最终要推动的是解放前端开发人员的精力，让我们不再陶醉于自己的一亩三分地，转而将精力投入到业务与人机交互体验的提升中。

正如之前所说，现在不缺前端基础设施了，我们对项目管理的思路也要有所转变。JS 无所不能，但做项目不能无法无天，约定产生效率，工具链保证约定。

当我们用工具链保证了项目结构的约定，就可以抽象出项目的**逻辑结构**。

有人走在更前面，[Rekit Studio](https://github.com/supnate/rekit)，就是根据文件结构解析出逻辑结构的工具，让开发以逻辑结构管理项目，真的可能带来项目维护、开发成本的大幅优化。

## 2 概述

<img src="https://img.alicdn.com/imgextra/i3/O1CN011IvrhL28NPVymhalL_!!6000000007920-2-tps-1600-1007.png" alt="logo" width="500" />

一图胜千言，仔细看完图，不然文章就漏掉了一半。

Rekit Studio 以逻辑视图重新组织了项目，文件目录不见了，取而代之的是路由、Action、组件等，原本若干文件拼凑成的 Action 被聚合成一个按钮，统一管理。

同时支持在线管理本地文件、集成了 [https://microsoft.github.io/monaco-editor/](monaco-editor) 在线编辑文件，以及在线构建、测试等功能。

同时利用和弦图分析了路由与数据流之间绑定关系，路由与文件绑定关系，可以很轻松找到被遗弃的孤立节点。项目维护时，以看图代替看代码，效率至少提升 2 3 倍。

### Cli 与可视化等效

Rekit Studio 还提供了 [Rekit CLI](http://rekit.js.org/docs/cli.html) 可以完全用命令行达到可视化的效果，在比如插件化、二次开发，或者特定场景下保留了通用拓展的能力。

### 只是辅助工具，而非必须

Rekit Studio 虽然拥有强大项目管理能力，但它不参与项目具体开发流程，项目可以脱离它独自开发，并且 Rekit 也不会内置任何 npm 包在项目中。

也就是说，Rekit Studio 的设计初衷，是为了增强项目管理能力，而不是参与到项目的开发流程中。

## 3 精读

传统的云端开发应该不会大规模普及，毕竟网页的体验和本地 IDE 差距还是非常大的。

但网页优势在与图形化表达，以及脚本化，如果一个按钮可以帮你管理许多本地文件，那这种混合式云端开发的价值就非常大。

Rekit Studio 的尝试，给我们打开了一个网页管理本地文件的脑洞，再结合 next.js 看看，可以碰撞出什么火花呢？

### next.js

next.js 支持许多约定，比如自动路由：

在 `pages` 下创建的文件会自动识别为路由，url 路径就是以 `pages` 开头的文件路径。

正因为如此，所以 next.js 对项目拥有强力的约束能力，支持了更多特性：

#### code splitting

因为路由和构建脚本都有 next.js 控制，因此支持将页面级别模块按需加载。

#### 静态文件处理

由于 next.js 包含对 node 端控制，自然可以处理静态文件：将 `static` 文件夹下的文件路由到 `/static` 路径。

#### 页面请求数据

每个页面级组件都支持静态函数 `getInitialProps`，这个方法的返回值不仅会注入到 `props`，更可以在 ssr 时预加载这部分数据。

#### 页面预加载

成为 `Prefetching Pages`，只要在 `Link` 标签添加 `prefetch` 属性，就会在空闲阶段预加载这个页面的按需 js 文件，几乎同时保证了整包的用户体验，与按需加载带来的 js 文件体积优化，只要用户别点击的太快。

#### Dynamic Import

支持动态 import，这个是 webpack 刚支持不久的 TC39 新特性，可以按需加载任何文件与 npm 包。详情见 [react-loadable](https://github.com/jamiebuilds/react-loadable).

#### 自定义配置

next.js 支持自定义错误处理、自定义 webpack、babel 和 next.js 导出配置等。比较有用的是 `publishPath`，因为大公司开发的 js 文件肯定会存储在专门的 CDN 节点。

#### 静态 html 文件导出

主要目的是做 GitHub Pages，这个功能与去年火起来的 [gatsby](https://github.com/gatsbyjs/gatsby) 比较像。天下技术一大抄，之前还有 [hexo](https://github.com/hexojs/hexo)、[jekyll](https://github.com/jekyll/jekyll) 几乎功能与 gatsby 一摸一样，起码应该在 readme 里写个 Inspired by hexo 吧。 

---

到这里，next.js 核心功能差不多介绍完了，大家可以发现，next.js 对项目自动化管理能力很强，唯独缺少了可视化管理功能。

### 尝试结合 Rekit Studio 与 next.js

实在对不起大家，这里要做一个硬广。

因为我同时看好 next.js 对项目约定化管理能力与 Rekit Studio 的可视化辅助能力，同时又很欣赏 [parcel](https://github.com/parcel-bundler/parcel) 的零配置理念，因此基于 parcel 做了一个三合一项目工具链：[pri](https://github.com/ascoders/pri)。

我真不是为了赚 star，这个项目在写文章时是 0 star，而且是过年这几天刚写的，很多功能还没开发完，就又赶着写精读了，所以不指望通过这篇文章赚粉，而是希望抛砖引玉，看看能不能吸引志同道合的朋友。

此刻想吐槽的同学别着急，等过段时间我写一篇彻彻底底的硬广软文时，再吐槽也不急。

硬广时间结束。下面重点说说为什么做 pri，以及制作过程中的一些思考。

#### 各取所长

提取这三个框架的精华：

1. 融化在项目中的脚手架 - next.js。
2. 网页也能管理代码 - Rekit Studio。
3. 坚持零配置到底 - parcel。

我为什么觉得这三点叠加起来一起提高项目的开发效率和可维护性？

##### 融化在项目中的脚手架

都说一个项目中一百个文件可能有一百种写法，这就是为什么要约法三章。不仅约束目录结构，我们还约束 npm 包，固定 react/vue/ag 的版本号，提交时不仅强制 lint，还强制检测文件结构是否符合约定。

项目开发时，遵守约定可能带来一点的不自由的感觉，但是对项目进度影响微乎其微，不稳定的项目结构对后期维护成本的影响，可能导致 “这个文案改不了”。

构建脚本也固化下来，云构建时使用的就是项目依赖的脚手架做编译，脚手架不再游离于项目之外。

最后不用说的，满足条件后，就可以前面罗列的 next.js 强大的功能。

##### 网页也能管理代码

我看中的可不是 Rekit Studio 在线写代码的功能，那个是鸡肋！而是按照规范自动生成文件的功能，恰恰可以解决约定带来的不适感。

任何上手的人，不需要了解约定，就可以通过可视化界面看到项目拥有几个路由、数据流、组件等等，然后在网页上一键创建新页面，新数据流、新组件，不仅省去了机械化劳动，省去了查看约定规范文档的时间，还带来可模版市场的可能性。

可视化带来的不仅是项目理解成本大大降低，**由于项目约定的存在，网页管理可以更加智能**。甚至是自动检测项目是否有文件存在异常、通过语法树，比如 `typescript` 包分析各文件中语法层面的关联，让可视化界面显示更加详细的项目关系图。

当新版本脚手架发布时，如果对项目约定产生了修改，也可以按照规则写出固定的升级方案，并通过可视化界面提示用户如何一步步升级到新版约定结构，甚至一键升级。

**正因为对项目拥有强力约束，所以脚手架才知道老项目该如何升级**。唯一的缺点是，不要有任何项目开发细节游离于规则之外，这需要对业务方案进行完整设计，当产生新需求时，将其固化到规则中，而不是任其自由发展。

##### 坚持零配置到底

parcel 坚持认为，如果提供了配置文件，那和 webpack 有什么区别呢？pri 的理念也一样，如果提供了配置文件，那抛开可视化功能，和 next.js 以及其他脚手架又有什么区别呢？

配置是为了扩大通用范围而产生的，设想 webpack 如果只解决简单的 commonjs 脚本引用，那也不需要复杂的配置。parcel 内置了对 sass less typescript png json html 等等文件的处理，所以也不需要配置。

但是，没有配置的 webpack（且不说 4.0）无法解决基本项目开发需要，而无配置的 parcel 几乎可以胜任任何项目开发，而它唯一的缺点就是，可能无法胜任未来某个新语法的支持。但只要 parcel 继续维护，这个语法需求足够大，都可以继续内置进去。

可以看到，parcel 与 webpack 的竞争，是开源界一场配置战争的缩影，大到对所有类型项目的支持，parcel 都敢坚持无配置，那么小到某条业务线的管理，真的还需要配置吗？

> 对于 `publicUrl` 这种参数，或者页面 `title` 之类的本身就无法确定的项目，还是需要提供配置的，当然这种配置是可控的。

项目开发中，遇到新需求，就将这个特殊处理逻辑内置到管理脚本中，恰恰解决了程序员最头疼的 “历史包袱” 问题。

同时对特殊逻辑内置的取舍、讨论，可以促进项目积极的发展，而不是配置能力过强，导致开发者时不时偷偷给项目增加一些新逻辑，以满足业务临时需求，累积到最后导致项目无人能接手。

## 4 总结

谈来谈去，并没有涉及到复杂的算法或者新技术，讨论的只是一种项目管理思想的不断自我挑战，整合与创新。

我并没有打算留下一个中庸的结局，我现在正在积极投入文中提及的三条思路的整合开发，并相信这是未来的趋势之一，并且确实能解决项目开发与维护遇到的难题。

我列出我认为应当拥有的所有功能与特性，欢迎大家在评论区补充，或者给 pri 提 [issue](https://github.com/ascoders/pri/issues)：

### 功能

- 页面即路由。
- 支持 layouts 布局。
- 404 处理。
- 自定义配置。 - 主要解决 `publicUrl` 等无法给出标准值的配置。
- 内置数据流并自动绑定到页面。
- 前端环境变量。 - 可以由自定义配置拓展，内置基本变量，比如是本地环境还是生产打包。
- Serve static files。
- 项目单测。
- 生成静态 HTML，支持 github pages。

### 特征

- 项目可视化管理仪表盘。 - 可视化管理代码，根据约定规范。
- typescript 支持（个人偏好的）。
- tslint（jslint）在执行任何脚本时强制校验。
- Dynamic import。
- 热更新 | HMR（parcel 内置）。
- code splitting（parcel 内置）。
- 公共依赖提取（parcel 内置）。
- 自动补全项目配置文件。 - 比如 `.gitignore` `tslint.json` 等等，可以以 merge 的方式保证基础配置存在。
- PWA 支持。
- Tree Shaking（parcel 暂时不支持，webpack 支持）。
- Scope Hoist（parcel 暂时不支持，webpack 支持）。
- Prefetching.

## 5 更多讨论

> 讨论地址是：[精读《Rekit Studio》 · Issue #63 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/63)

**如果你想参与讨论，请[点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，每周五发布。**
