Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 ascoders
|
5c44507443 | ||
|
ascoders
|
ffb736eb6d | ||
|
黄子毅
|
abc677a5f0 | ||
|
ascoders
|
3c78a1a659 | ||
|
ascoders
|
507df796b0 | ||
|
ascoders
|
0f58ce27dc | ||
|
ascoders
|
51c8f3bb69 | ||
|
vivaxy
|
c4da7262cb | ||
|
ascoders
|
a513286318 | ||
|
ascoders
|
509dfe2c97 | ||
|
ascoders
|
806ee0177a | ||
|
ascoders
|
fe4afdf89c | ||
|
ascoders
|
caec16066a | ||
|
ascoders
|
7f53bde9a3 | ||
|
ascoders
|
63e2ca4d0d | ||
|
黄子毅
|
9dbd1fb7b9 | ||
|
黄子毅
|
7d8816c2c2 | ||
|
黄子毅
|
44ae420f52 | ||
|
mr_left
|
683b22d1ae | ||
|
mr_left
|
4e58379585 | ||
|
mr_left
|
1342144fef | ||
|
ascoders
|
a41f452df0 |
@@ -214,7 +214,7 @@ class Component extends React.PureComponent<Props, State> {
|
||||
this.rootDom = ReactDOM.findDOMNode(this.rootDomRef) as HTMLDivElement;
|
||||
|
||||
this.chart = new G2.Chart({
|
||||
container: document.getElementById("chart"),
|
||||
container: this.rootDom,
|
||||
forceFit: true,
|
||||
height: 300
|
||||
});
|
||||
|
||||
@@ -259,7 +259,7 @@ const { loading, error, result } = useAsync(fetchUser, [id]);
|
||||
实现：在 Promise 的初期设置 loading，结束后设置 result，如果出错则设置 error，这里可以将请求对象包装成 `useAsyncState` 来处理，这里就不放出来了。
|
||||
|
||||
```tsx
|
||||
export function useAsync(asyncFunction) {
|
||||
export function useAsync(asyncFunction: any, params: any[]) {
|
||||
const asyncState = useAsyncState(options);
|
||||
|
||||
useEffect(() => {
|
||||
@@ -326,8 +326,8 @@ const fetchUser = id =>
|
||||
});
|
||||
|
||||
function useFetchUser(id) {
|
||||
const asyncFetchUser = useAsync(fetchUser, id);
|
||||
return asyncUser;
|
||||
const asyncFetchUser = useAsync(fetchUser, [id]);
|
||||
return asyncFetchUser;
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@@ -813,25 +813,30 @@ function Parent() {
|
||||
换一个例子就可以看得更清楚：
|
||||
|
||||
```js
|
||||
function Parent() {
|
||||
function Parent(props) {
|
||||
const [count, setCount] = useState(0);
|
||||
const [step, setStep] = useState(0);
|
||||
const [other, setOther] = useState(0);
|
||||
const drag = useDraggable(count, step); // 封装了拖拽函数
|
||||
const drag = useDraggable(props.dom, count, step); // 封装了拖拽函数
|
||||
|
||||
useEffect(() => {
|
||||
// dom 变化时重新实例化
|
||||
drag()
|
||||
}, [drag])
|
||||
}
|
||||
```
|
||||
|
||||
假设我们使用 [Sortablejs](https://github.com/SortableJS/Sortable) 对某个区域进行拖拽监听，这个函数每次都重复执行的性能损耗非常大，**然而这个函数内部可能因为仅仅要上报一些日志，所以依赖了没有实际被使用的 `count` `step` 变量：**
|
||||
|
||||
```js
|
||||
function useDraggable(count, step) {
|
||||
function useDraggable(dom, count, step) {
|
||||
return useCallback(() => {
|
||||
// 上报日志
|
||||
report(count, step);
|
||||
|
||||
// 对区域进行初始化，非常耗时
|
||||
// ... 省略耗时代码
|
||||
}, [count, step]);
|
||||
}, [dom, count, step]);
|
||||
}
|
||||
```
|
||||
|
||||
@@ -1130,7 +1135,7 @@ const Step = () => {
|
||||
一个普通的 Redux 组件：
|
||||
|
||||
```js
|
||||
const mapStateToProps = state => (count: state.count);
|
||||
const mapStateToProps = state => ({count: state.count});
|
||||
|
||||
const mapDispatchToProps = dispatch => dispatch;
|
||||
|
||||
|
||||
+1
-1
@@ -92,7 +92,7 @@
|
||||
|
||||
**中南半岛由 5 个国家组成，从西到东分别是：缅甸、泰国、柬埔寨、老挝、越南**，其中缅、老、 越与中国接壤，除了老挝外都有足够的海岸线。这些国家大部分是殖民时代的遗产，英法分别在缅甸、越南发力，将泰国定位缓冲国。法国人曾将柬埔寨、老挝、越南合并成 “印支联邦” 与英国对抗，虽然现在又分裂成三个国家，因此却为越南埋下了大国梦。
|
||||
|
||||
缅甸在位置上，可以在陆地及海洋延伸中国的地缘影响力，而且也曾成为支持中国抗战的重要援助物资运输线。在缅甸西边是 “金三角地区”：
|
||||
缅甸在位置上，可以在陆地及海洋延伸中国的地缘影响力，而且也曾成为支持中国抗战的重要援助物资运输线。在缅甸东边是 “金三角地区”：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1iwnRchD1gK0jSZFKXXcJrVXa-1396-1266.png">
|
||||
|
||||
|
||||
@@ -0,0 +1,290 @@
|
||||
## 简介
|
||||
|
||||
React 16.8 于 2019.2 正式发布，这是一个能提升代码质量和开发效率的特性，笔者就抛砖引玉先列出一些实践点，希望得到大家进一步讨论。
|
||||
|
||||
然而需要理解的是，没有一个完美的最佳实践规范，对一个高效团队来说，稳定的规范比合理的规范更重要，因此这套方案只是最佳实践之一。
|
||||
|
||||
## 精读
|
||||
|
||||
### 环境要求
|
||||
|
||||
- 拥有较为稳定且理解函数式编程的前端团队。
|
||||
- 开启 ESLint 插件：[eslint-plugin-react-hooks](https://www.npmjs.com/package/eslint-plugin-react-hooks)。
|
||||
|
||||
### 组件定义
|
||||
|
||||
Function Component 采用 `const` + 箭头函数方式定义：
|
||||
|
||||
```tsx
|
||||
const App: React.FC<{ title: string }> = ({ title }) => {
|
||||
return React.useMemo(() => <div>{title}</div>, [title]);
|
||||
};
|
||||
|
||||
App.defaultProps = {
|
||||
title: 'Function Component'
|
||||
}
|
||||
```
|
||||
|
||||
上面的例子包含了：
|
||||
|
||||
1. 用 `React.FC` 申明 Function Component 组件类型与定义 Props 参数类型。
|
||||
2. 用 `React.useMemo` 优化渲染性能。
|
||||
3. 用 `App.defaultProps` 定义 Props 的默认值。
|
||||
|
||||
#### FAQ
|
||||
|
||||
> 为什么不用 React.memo?
|
||||
|
||||
推荐使用 `React.useMemo` 而不是 `React.memo`，因为在组件通信时存在 `React.useContext` 的用法，这种用法会使所有用到的组件重渲染，只有 `React.useMemo` 能处理这种场景的按需渲染。
|
||||
|
||||
> 没有性能问题的组件也要使用 useMemo 吗？
|
||||
|
||||
要，考虑未来维护这个组件的时候，随时可能会通过 `useContext` 等注入一些数据，这时候谁会想起来添加 `useMemo` 呢？
|
||||
|
||||
> 为什么不用解构方式代替 defaultProps?
|
||||
|
||||
虽然解构方式书写 `defaultProps` 更优雅，但存在一个硬伤：对于对象类型每次 Rerender 时引用都会变化，这会带来性能问题，因此不要这么做。
|
||||
|
||||
### 局部状态
|
||||
|
||||
局部状态有三种，根据常用程度依次排列： `useState` `useRef` `useReducer` 。
|
||||
|
||||
#### useState
|
||||
|
||||
```tsx
|
||||
const [hide, setHide] = React.useState(false);
|
||||
const [name, setName] = React.useState('BI');
|
||||
```
|
||||
|
||||
状态函数名要表意，尽量聚集在一起申明，方便查阅。
|
||||
|
||||
#### useRef
|
||||
|
||||
```tsx
|
||||
const dom = React.useRef(null);
|
||||
```
|
||||
|
||||
`useRef` 尽量少用，大量 Mutable 的数据会影响代码的可维护性。
|
||||
|
||||
但对于不需重复初始化的对象推荐使用 `useRef` 存储，比如 `new G2()` 。
|
||||
|
||||
#### useReducer
|
||||
|
||||
局部状态不推荐使用 `useReducer` ，会导致函数内部状态过于复杂，难以阅读。 `useReducer` 建议在多组件间通信时，结合 `useContext` 一起使用。
|
||||
|
||||
#### FAQ
|
||||
|
||||
> 可以在函数内直接申明普通常量或普通函数吗？
|
||||
|
||||
不可以，Function Component 每次渲染都会重新执行，常量推荐放到函数外层避免性能问题，函数推荐使用 `useCallback` 申明。
|
||||
|
||||
### 函数
|
||||
|
||||
所有 Function Component 内函数必须用 `React.useCallback` 包裹，以保证准确性与性能。
|
||||
|
||||
```tsx
|
||||
const [hide, setHide] = React.useState(false);
|
||||
|
||||
const handleClick = React.useCallback(() => {
|
||||
setHide(isHide => !isHide)
|
||||
}, [])
|
||||
```
|
||||
|
||||
`useCallback` 第二个参数必须写，[eslint-plugin-react-hooks](https://www.npmjs.com/package/eslint-plugin-react-hooks) 插件会自动填写依赖项。
|
||||
|
||||
### 发请求
|
||||
|
||||
发请求分为操作型发请求与渲染型发请求。
|
||||
|
||||
#### 操作型发请求
|
||||
|
||||
操作型发请求，作为回调函数：
|
||||
|
||||
```tsx
|
||||
return React.useMemo(() => {
|
||||
return (
|
||||
<div onClick={requestService.addList} />
|
||||
)
|
||||
}, [requestService.addList])
|
||||
```
|
||||
|
||||
#### 渲染型发请求
|
||||
|
||||
渲染型发请求在 `useAsync` 中进行，比如刷新列表页，获取基础信息，或者进行搜索， **都可以抽象为依赖了某些变量，当这些变量变化时要重新取数** ：
|
||||
|
||||
```tsx
|
||||
const { loading, error, value } = useAsync(async () => {
|
||||
return requestService.freshList(id);
|
||||
}, [requestService.freshList, id]);
|
||||
```
|
||||
|
||||
### 组件间通信
|
||||
|
||||
简单的组件间通信使用透传 Props 变量的方式，而频繁组件间通信使用 `React.useContext` 。
|
||||
|
||||
以一个复杂大组件为例，如果组件内部拆分了很多模块， **但需要共享很多内部状态** ，最佳实践如下：
|
||||
|
||||
#### 定义组件内共享状态 - store.ts
|
||||
|
||||
```tsx
|
||||
export const StoreContext = React.createContext<{
|
||||
state: State;
|
||||
dispatch: React.Dispatch<Action>;
|
||||
}>(null)
|
||||
|
||||
export interface State {};
|
||||
|
||||
export interface Action { type: 'xxx' } | { type: 'yyy' };
|
||||
|
||||
export const initState: State = {};
|
||||
|
||||
export const reducer: React.Reducer<State, Action> = (state, action) => {
|
||||
switch (action.type) {
|
||||
default:
|
||||
return state;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
#### 根组件注入共享状态 - main.ts
|
||||
|
||||
```tsx
|
||||
import { StoreContext, reducer, initState } from './store'
|
||||
|
||||
const AppProvider: React.FC = props => {
|
||||
const [state, dispatch] = React.useReducer(reducer, initState);
|
||||
|
||||
return React.useMemo(() => (
|
||||
<StoreContext.Provider value={{ state, dispatch }}>
|
||||
<App />
|
||||
</StoreContext.Provider>
|
||||
), [state, dispatch])
|
||||
};
|
||||
```
|
||||
|
||||
#### 任意子组件访问/修改共享状态 - child.ts
|
||||
|
||||
```tsx
|
||||
import { StoreContext } from './store'
|
||||
|
||||
const app: React.FC = () => {
|
||||
const { state, dispatch } = React.useContext(StoreContext);
|
||||
|
||||
return React.useMemo(() => (
|
||||
<div>{state.name}</div>
|
||||
), [state.name])
|
||||
};
|
||||
```
|
||||
|
||||
如上解决了 **多个联系紧密组件模块间便捷共享状态的问题** ，但有时也会遇到需要共享根组件 Props 的问题，**这种不可修改的状态不适合一并塞到 `StoreContext` 里**，我们新建一个 `PropsContext` 注入根组件的 Props：
|
||||
|
||||
```tsx
|
||||
const PropsContext = React.createContext<Props>(null)
|
||||
|
||||
const AppProvider: React.FC<Props> = props => {
|
||||
return React.useMemo(() => (
|
||||
<PropsContext.Provider value={props}>
|
||||
<App />
|
||||
</PropsContext.Provider>
|
||||
), [props])
|
||||
};
|
||||
```
|
||||
|
||||
#### 结合项目数据流
|
||||
|
||||
参考 [react-redux hooks](https://github.com/reduxjs/react-redux/blob/master/docs/api/hooks.md)。
|
||||
|
||||
### debounce 优化
|
||||
|
||||
比如当输入框频繁输入时，为了保证页面流畅，我们会选择在 `onChange` 时进行 `debounce` 。然而在 Function Component 领域中，我们有更优雅的方式实现。
|
||||
|
||||
> 其实在 Input 组件 `onChange` 使用 `debounce` 有一个问题，就是当 Input 组件 **受控** 时， `debounce` 的值不能及时回填，导致甚至无法输入的问题。
|
||||
|
||||
我们站在 Function Component 思维模式下思考这个问题：
|
||||
|
||||
1. React [scheduling](https://github.com/dt-fe/weekly/blob/v2/099.%E7%B2%BE%E8%AF%BB%E3%80%8AScheduling%20in%20React%E3%80%8B.md) 通过智能调度系统优化渲染优先级，我们其实不用担心频繁变更状态会导致性能问题。
|
||||
2. 如果联动一个文本还觉得慢吗？ `onChange` 本不慢，大部分使用值的组件也不慢，没有必要从 `onChange` 源头开始就 `debounce` 。
|
||||
3. 找到渲染性能最慢的组件（比如 iframe 组件），**对一些频繁导致其渲染的入参进行 `useDebounce`** 。
|
||||
|
||||
下面是一个性能很差的组件，引用了变化频繁的 `text` （这个 `text` 可能是 `onChange` 触发改变的），我们利用 `useDebounce` 将其变更的频率慢下来即可：
|
||||
|
||||
```typescript
|
||||
const App: React.FC = ({ text }) => {
|
||||
// 无论 text 变化多快，textDebounce 最多 1 秒修改一次
|
||||
const textDebounce = useDebounce(text, 1000)
|
||||
|
||||
return useMemo(() => {
|
||||
// 使用 textDebounce，但渲染速度很慢的一堆代码
|
||||
}, [textDebounce])
|
||||
};
|
||||
```
|
||||
|
||||
使用 `textDebounce` 替代 `text` 可以将渲染频率控制在我们指定的范围内。
|
||||
|
||||
### useEffect 注意事项
|
||||
|
||||
事实上，`useEffect` 是最为怪异的 Hook，也是最难使用的 Hook。比如下面这段代码：
|
||||
|
||||
```tsx
|
||||
useEffect(() => {
|
||||
props.onChange(props.id)
|
||||
}, [props.onChange, props.id])
|
||||
```
|
||||
|
||||
如果 `id` 变化，则调用 `onChange`。但如果上层代码并没有对 `onChange` 进行合理的封装，导致每次刷新引用都会变动，则会产生严重后果。我们假设父级代码是这么写的：
|
||||
|
||||
```tsx
|
||||
class App {
|
||||
render() {
|
||||
return <Child id={this.state.id} onChange={id => this.setState({ id })} />
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
这样会导致死循环。虽然看上去 `<App>` 只是将更新 id 的时机交给了子元素 `<Child>`，但由于 `onChange` 函数在每次渲染时都会重新生成，因此引用总是在变化，就会出现一个无限死循环：
|
||||
|
||||
新 `onChange` -> `useEffect` 依赖更新 -> `props.onChange` -> 父级重渲染 -> 新 `onChange`...
|
||||
|
||||
想要阻止这个循环的发生，只要改为 `onChange={this.handleChange}` 即可，**`useEffect` 对外部依赖苛刻的要求，只有在整体项目都注意保持正确的引用时才能优雅生效。**
|
||||
|
||||
然而被调用处代码怎么写并不受我们控制，这就导致了不规范的父元素可能导致 React Hooks 产生死循环。
|
||||
|
||||
因此在使用 `useEffect` 时要注意调试上下文，注意父级传递的参数引用是否正确，如果引用传递不正确，有两种做法：
|
||||
|
||||
1. 使用 [useDeepCompareEffect](https://github.com/streamich/react-use/blob/master/docs/useDeepCompareEffect.md) 对依赖进行深比较。
|
||||
2. 使用 `useCurrentValue` 对引用总是变化的 props 进行包装：
|
||||
|
||||
```tsx
|
||||
function useCurrentValue<T>(value: T): React.RefObject<T> {
|
||||
const ref = React.useRef(null);
|
||||
ref.current = value;
|
||||
return ref;
|
||||
}
|
||||
|
||||
const App: React.FC = ({ onChange }) => {
|
||||
const onChangeCurrent = useCurrentValue(onChange)
|
||||
};
|
||||
```
|
||||
|
||||
`onChangeCurrent` 的引用保持不变，但每次都会指向最新的 `props.onChange`，从而可以规避这个问题。
|
||||
|
||||
## 总结
|
||||
|
||||
如果还有补充，欢迎在文末讨论。
|
||||
|
||||
如需了解 Function Component 或 Hooks 基础用法，可以参考往期精读：
|
||||
|
||||
- [精读《React Hooks》](https://github.com/dt-fe/weekly/blob/v2/079.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Hooks%E3%80%8B.md)
|
||||
- [精读《怎么用 React Hooks 造轮子》](https://github.com/dt-fe/weekly/blob/v2/080.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%80%8E%E4%B9%88%E7%94%A8%20React%20Hooks%20%E9%80%A0%E8%BD%AE%E5%AD%90%E3%80%8B.md)
|
||||
- [精读《useEffect 完全指南》](https://github.com/dt-fe/weekly/blob/v2/096.%E7%B2%BE%E8%AF%BB%E3%80%8AuseEffect%20%E5%AE%8C%E5%85%A8%E6%8C%87%E5%8D%97%E3%80%8B.md)
|
||||
- [精读《Function Component 入门》](https://github.com/dt-fe/weekly/blob/v2/104.精读《Function%20Component%20入门》.md)
|
||||
|
||||
> 讨论地址是：[精读《React Hooks 最佳实践》 · Issue #202 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/202)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,175 @@
|
||||
## 简介
|
||||
|
||||
商业智能（Business Intelligence）简称 BI，即通过数据挖掘与分析找到商业洞察，助力商业成功。
|
||||
|
||||
一个完整的 BI 链路包含数据采集、数据清洗、数据挖掘、数据展现，其本质是对数据进行多维分析。前端的主要工作在数据展现环节，由于展示方式繁多、分析模型复杂且数据量大，前端环节的复杂度很高。
|
||||
|
||||
在 BI 做前端非常有挑战，开发者需要充分理解数据概念，而本身复杂度较高的可视化建站也只是 BI 的基础能力，想要建设 BI 的上层能力，比如探索式分析和数据洞察，都需要在前后端引入更复杂的计算模型。
|
||||
|
||||
本文作为一个引子，简单介绍笔者做 BI 的经验，后面如果有机会再写一个系列文章对细节进行阐述。
|
||||
|
||||
## 精读
|
||||
|
||||
国内目前处于 BI 1.0 阶段，也就是报表阶段，因此笔者将阐述这个阶段 BI 的核心开发概念。
|
||||
|
||||
> BI 2.0 探索式分析阶段是国内数据分析最前沿领域，这部分等开发完成后再分享。
|
||||
|
||||
BI 1.0 阶段的核心概念包括 **数据集、渲染引擎、数据模型、可视化** 这四个技术模块。
|
||||
|
||||
### 数据集
|
||||
|
||||
数据集即数据的集合，在 BI 领域更多指一种标准化的数据结构。
|
||||
|
||||
任何数据都可以封装成数据集，比如 txt 文本、excel、mysql 数据库等等。
|
||||
|
||||
数据集的基本形态是二维表格，列头表示字段，每一行就是一份数据，数据展示就是通过对这些数据字段进行多维度分析。
|
||||
|
||||
#### 数据集导入
|
||||
|
||||
一般来说数据集导入有两种方式，分别是本地文件上传与数据库链接。本地文件上传又分为多种文件类型处理，比如对 excel 的解析，可能还包括数据清洗；数据库链接分析可视化导入与 SQL 输入。
|
||||
|
||||
可视化导入需要提前对数据库进行结构分析，绘制出表结构与字段结构，不用理解 SQL 也可以进行可视化操作。
|
||||
|
||||
SQL 输入可以利用 [monaco-editor](https://github.com/microsoft/monaco-editor) 等 web 代码编辑器作为输入框，最好能结合智能提示提高 sql 编写效率。sql 智能提示可以参考往期精读 [精读《手写 SQL 编译器 - 智能提示》](https://github.com/dt-fe/weekly/blob/v2/085.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E6%99%BA%E8%83%BD%E6%8F%90%E7%A4%BA%E3%80%8B.md)。
|
||||
|
||||
#### 数据集建模
|
||||
|
||||
数据集建模一般包含 **维度度量建模、字段配置、层系建模**。
|
||||
|
||||
维度度量建模需要智能分析出字段属于维度还是度量，一般会结合字段实际的值或者字段名来智能判断字段类型，如果数据库信息中已存储了字段类型，就可以 100% 准确归类。
|
||||
|
||||
字段配置即对字段进行增删或修改，还可以新增聚合字段或对比字段。
|
||||
|
||||
聚合字段是指将一个字段表达式封装为一个新字段，这里也会用到一个简单的 sql 编辑器，只需要支持四则运算、字段提示、以及一些基本函数的组合即可。
|
||||
|
||||
对比字段是指新增的字段是基于已有字段在某个时间周期内的对比，比如对 UV 字段的年同比就可以封装为一个对比字段。对比字段在前端技术上没有什么难度，仅需理解概念即可。
|
||||
|
||||
### 渲染引擎
|
||||
|
||||
渲染引擎包括了对报表进行编辑与渲染的引擎，理论上可以合二为一。
|
||||
|
||||
渲染引擎的重要模块包括：画布拖拽、组件编辑、事件中心。
|
||||
|
||||
画布拖拽其实包含了组件自定义开发流程，到 CDN 发布、CDN 加载、组件拖拽、画布排版等一系列技术点，每个点展开都有写不完的细节，但好在这套功能属于通用建站基础功能点，本文就不再赘述。
|
||||
|
||||
组件编辑中，基本属性的编辑与属于通用建站领域的表单模型范畴，一般通过 UISchema 来描述通用表单，这块也不再赘述。组件编辑的另一部分就是数据编辑，这部分在后面数据模型章节里详细讲。
|
||||
|
||||
事件中心是渲染引擎部分，此功能在编辑状态需要禁用。这个功能可以实现图表联动、上卷下钻等数据能力。一个通用事件中心一般包括 **事件触发** 与 **事件响应** 两部分，基本结构如下：
|
||||
|
||||
```typescript
|
||||
interface Event {
|
||||
trigger:
|
||||
| {
|
||||
type: 'callback';
|
||||
callbackName: string;
|
||||
}
|
||||
| {
|
||||
type: 'listener';
|
||||
eventName: string;
|
||||
}
|
||||
| {
|
||||
type: 'system';
|
||||
name: string;
|
||||
};
|
||||
|
||||
action:
|
||||
| {
|
||||
type: 'dispatch';
|
||||
eventName: string;
|
||||
}
|
||||
| {
|
||||
type: 'jumpUrl';
|
||||
url: string;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`trigger` 即事件触发，包括基本的系统事件 `system`，比如定时器或者初始化自动触发；组件的回调 `callback` 比如当按钮被点击时；事件监听 `listener` 比如另一个事件被触发时，这个事件可能来自于 `action`。
|
||||
|
||||
`action` 即事件响应，包括基本的事件触发 `dispatch`，可以触发其他事件，可以构成一个事件链路；其他的 `action` 就是数据相关，可以用来做条件联动、字段联动、数据集联动等等，因为实现各异这里不做介绍。
|
||||
|
||||
事件机制还需要支持值传递，即事件触发源的值可以传递到事件响应方。值传递可以在触发源内部进行，比如当触发源是回调函数时，函数参数就自然作为值传递过去，触发源通过 `...args` 方式接收。
|
||||
|
||||
#### 数据钻取
|
||||
|
||||
配置了层系的字段都可以进行数据钻取。层系可以在数据集配置，也可以在报表编辑页配置，可以理解为一个顺序有关的文件夹，将文件夹作为字段使用时，默认生效的是第一个子元素，之后可以按照顺序分别进行下钻。
|
||||
|
||||
比如 “地区” 层系包含了国家、省、市、区，那么就可以按照这个层级进行数据上卷下钻。
|
||||
|
||||
如果一个字段是层系字段，图表需要有对应的操作区域进行上卷下钻，数据编辑区域也可以进行同样操作。数据钻取的计算过程不在图表内部处理，而是触发一个状态后，由渲染引擎将这个层系字段实例状态改为下钻到第 N 层，并且每下钻一次就多拿到一列的数据，由图表组件进行下钻展示。
|
||||
|
||||
一般来说下钻后数据仍是全量的，有时候为了避免数据量过大，比如在柱状图点击某个柱子进行下钻，只想看这个柱子下钻后的数据：比如 2017、2018、2019 年三年的数据，下钻到月后数据量是 3 x 12 = 36 条，但如果仅在 2019 年进行下钻，只想看 2019 年的 12 条数据，可以转化为下钻 + 筛选条件的模式：全局下钻展开后 36 条，在 2019 年上点击下钻后，增加一个筛选条件（年 = 2019），这样就达到了效果，整个流程对图表组件是无感知的。
|
||||
|
||||
### 数据模型
|
||||
|
||||
与通用表单模型 UISchema 相对应，数据模型笔者称之为 CubeSchema，因为 BI 领域对数据的多维处理模型成为 Cube 立方体，数据配置即表示如何对这个立方体进行查询，因此其配置表单成为 CubeSchema。
|
||||
|
||||
不管是探索式分析还是 BI 1.0 的报表阶段，数据模型的基本概念是通用的（探索式分析固定了行列，且增加了标记）：将字段放置到不同的区域，这些区域的划分方式可以按照功能：横轴、纵轴；按照概念：维度、度量；按照探索分析思路：固化为行、列等等。
|
||||
|
||||
这块可能涉及到的技术点有：拖拽、批量选择+拖拽、双击后按照维度度量自动添加、图表切换后区域字段自动迁移、对字段拖拽的系列配置：限制数量、限制类型、限制数据集、是否重复等等。
|
||||
|
||||
拖拽可以用 [react-beautiful-dnd](https://github.com/atlassian/react-beautiful-dnd) 等库，与渲染引擎拖拽方案基本类似，遇到有层系的数据集还需支持嵌套层级的拖拽。
|
||||
|
||||
图表切换后字段迁移，可以将每个拖拽区域设置若干类型：
|
||||
|
||||
```json
|
||||
{
|
||||
"dataType": ["dimension"]
|
||||
}
|
||||
```
|
||||
|
||||
这样在切换后，维度类型的字段可以自动迁移到维度类型区域，如果对应区域字段数量达到了 `limit` 限制，就继续填充到下一个区域，直到字段用尽或区域填充完为止。
|
||||
|
||||
如果在探索式分析场景里，需要提前对字段进行维度度量建模，在切换时按照图表情况进行相应的处理。比如折线图切换到表格的情况：折线图是天然一个维度（主轴） + N 个度量的场景，表格是天然两个维度（行、列）+ 1 个度量的场景（也可以支持多个，对单元格进行再切分即可），那么从折线图切换到表格时，度量就会落到标记的文本区域；如果从拥有行和列的表格切换到柱状图（之所以无法切换到折线图，是因为表格的度量值一般是离散的，而折线图度量值一般是连续的），表格的行与列的字段会落到柱状图的维度轴，表现效果是对维度轴进行下钻。
|
||||
|
||||
> [精读《Tableau 探索式模型》](https://github.com/dt-fe/weekly/blob/v2/117.%E7%B2%BE%E8%AF%BB%E3%80%8ATableau%20%E6%8E%A2%E7%B4%A2%E5%BC%8F%E6%A8%A1%E5%9E%8B%E3%80%8B.md) 了解更多探索式分析。
|
||||
|
||||
数据模型还包括数据分析相关配置，比如设置对比字段，或者均值线等分析功能。这些数据计算工作放在后端，前端需要将配置项整理到取数接口中，并按照数据驱动的方式展现。
|
||||
|
||||
对于对比字段等 “拓展字段” 的分析功能，可以拓展通用取数接口，图表组件无感知，相当于多添加了几个隐藏字段；去特殊值等对标准数据进行操作的情况图表组件也无需感知。
|
||||
|
||||
聚类、均值线等需要图表组件额外展示的部分抽象为一套固定的数据格式透传给图表组件，由图表组件自行处理。
|
||||
|
||||
可以看出来，都是取数 + 展示，普通的前端业务与 BI 业务开发的区别：
|
||||
|
||||
普通前端业务是以业务逻辑为核心的，根据业务需要确定接口格式；BI 业务是以数据为核心的，围绕数据计算模型确定一套固定的接口格式，取数不依赖组件，所有组件对标准数据都有对应的展现。
|
||||
|
||||
### 可视化
|
||||
|
||||
与普通可视化组件不同，BI 可视化组件需要对接 CubeSchema 模型，同时还要支持 **大数据性能优化、边界数据展示优化、交互响应**。
|
||||
|
||||
对接 CubeSchema 即统一对接二维表格的数据，大部分组件都是二维以上结构展示，因此对接起来并不困难，有一些一维数据结构的组件比如单指标块就要舍弃其中的某一维，需要确定一套规则。
|
||||
|
||||
二维以上部分是较为通用的，虽然计算模型是基于 Cube N 维的，但组件可以通过标准轴进行多维度展开，或者说下钻来实现类似效果。对于折线图来说，轴的含义有限，可以用分面的方式展示多维数据。当然也有一些组件只适合展示特定维度数量的数据。
|
||||
|
||||
#### 大数据性能优化
|
||||
|
||||
可视化组件特别需要关注性能优化，因为 BI 查询出的数据量可能非常大，特别是多层下钻或基于地理的数据。
|
||||
|
||||
技术手段包括 GPU 渲染、缓存 canvas、多线程运算等，业务手段包括数据抽样、按需渲染可视区域、限制数据条数等等。
|
||||
|
||||
#### 边界数据展示优化
|
||||
|
||||
永远不知道数据集会给出怎样的数据，因此 BI 边界情况特别多，可能点非常密集，也可能丢失一些数据导致渲染异常。图表组件需要利用避让算法将密集的数据打散或着色，目的是为了容易阅读，对于丢失的异常数据也要有保护性的补全机制。
|
||||
|
||||
#### 交互响应
|
||||
|
||||
包括上卷下钻、点选、圈选、高亮等交互操作，这些操作反馈到渲染引擎导致数据变化并将新的数据灌入图表组件。
|
||||
|
||||
业务逻辑上这些交互操作并不复杂，难点在使用的可视化库是否有这个能力，以及如何统一交互行为。
|
||||
|
||||
## 总结
|
||||
|
||||
BI 领域的四大方向：数据集、渲染引擎、数据模型与可视化都有许多可以做深的技术点，每一块都需要深入沉淀几年技术经验才能做好，需要大量优秀人才通力协作才有可能做好。
|
||||
|
||||
目前我们在阿里数据中台正在打造一款面向未来的优秀 BI 工具，如果 BI 领域让你觉得有挑战，随时欢迎你的加入，联系邮箱：ziyi.hzy@alibaba-inc.com
|
||||
|
||||
> 讨论地址是：[精读《前端与 BI》 · Issue #208 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/208)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,293 @@
|
||||
## 1 概述
|
||||
|
||||
本期精读的是有限状态机管理工具 [robot](https://github.com/matthewp/robot) 源码。
|
||||
|
||||
有限状态机是指有限个数的状态之间相互切换的数学模型，在业务与游戏开发中有限状态都很常见，包括发请求也是一种有限状态机的模型。
|
||||
|
||||
笔者将在简介中介绍这个库的使用方式，在精读中介绍实现原理，最后总结在业务中使用的价值。
|
||||
|
||||
## 2 简介
|
||||
|
||||
这个库的核心就是利用 `createMachine` 创建一个有限状态机：
|
||||
|
||||
```typescript
|
||||
import { createMachine, state, transition } from 'robot3';
|
||||
|
||||
const machine = createMachine({
|
||||
inactive: state(
|
||||
transition('toggle', 'active')
|
||||
),
|
||||
active: state(
|
||||
transition('toggle', 'inactive')
|
||||
)
|
||||
});
|
||||
|
||||
export default machine;
|
||||
```
|
||||
|
||||
如上图所示，我们创建了一个有限状态机 `machine`，包含了两种状态：`inactive` 与 `active`，并且可以通过 `toggle` 动作在两种状态间做切换。
|
||||
|
||||
与 React 结合则有 [react-robot](https://github.com/matthewp/react-robot):
|
||||
|
||||
```tsx
|
||||
import { useMachine } from 'react-robot';
|
||||
import React from 'react';
|
||||
import machine from './machine'
|
||||
|
||||
function App() {
|
||||
const [current, send] = useMachine(machine);
|
||||
|
||||
return (
|
||||
<button type="button" onClick={() => send('toggle')}>
|
||||
State: {current.name}
|
||||
</button>
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
通过 `useMachine` 拿到的 `current.name` 表示当前状态值，`send` 用来发送改变状态的指令。
|
||||
|
||||
至于为什么要用有限状态机管理工具，官方文档举了个例子 - 点击编辑后进入编辑态，点击保存后返回原始状态的例子：
|
||||
|
||||
|
||||
|
||||
点击 Edit 按钮后，将进入下图的状态，点击 Save 后如果输入的内容校验通过保存后再回到初始状态：
|
||||
|
||||
|
||||
|
||||
如果不用有限状态机，我们首先会创建两个变量存储是否处于编辑态，以及当前输入文本是什么：
|
||||
|
||||
```js
|
||||
let editMode = false;
|
||||
let title = '';
|
||||
```
|
||||
|
||||
如果再考虑和后端的交互，就会增加三个状态 - 保存中、校验、保存是否成功：
|
||||
|
||||
```js
|
||||
let editMode = false;
|
||||
let title = '';
|
||||
let saving = false;
|
||||
let validating = false;
|
||||
let saveHadError = false;
|
||||
```
|
||||
|
||||
就算使用 React、Vue 等框架数据驱动 UI，我们还是免不了对复杂状态进行管理。如果使用有限状态机实现，将是这样的：
|
||||
|
||||
```js
|
||||
import { createMachine, guard, immediate, invoke, state, transition, reduce } from 'robot3';
|
||||
|
||||
const machine = createMachine({
|
||||
preview: state(
|
||||
transition('edit', 'editMode',
|
||||
// Save the current title as oldTitle so we can reset later.
|
||||
reduce(ctx => ({ ...ctx, oldTitle: ctx.title }))
|
||||
)
|
||||
),
|
||||
editMode: state(
|
||||
transition('input', 'editMode',
|
||||
reduce((ctx, ev) => ({ ...ctx, title: ev.target.value }))
|
||||
),
|
||||
transition('cancel', 'cancel'),
|
||||
transition('save', 'validate')
|
||||
),
|
||||
cancel: state(
|
||||
immediate('preview',
|
||||
// Reset the title back to oldTitle
|
||||
reduce(ctx => ({ ...ctx, title: ctx.oldTitle })
|
||||
)
|
||||
),
|
||||
validate: state(
|
||||
// Check if the title is valid. If so go
|
||||
// to the save state, otherwise go back to editMode
|
||||
immediate('save', guard(titleIsValid)),
|
||||
immediate('editMode')
|
||||
)
|
||||
save: invoke(saveTitle,
|
||||
transition('done', 'preview'),
|
||||
transition('error', 'error')
|
||||
),
|
||||
error: state(
|
||||
// Should we provide a retry or...?
|
||||
)
|
||||
});
|
||||
```
|
||||
|
||||
其中 `immediate` 表示直接跳到下一个状态，`reduce` 则可以对状态机内部数据进行拓展。比如 `preview` 返回了 `oldTitle`，那么 `cancle` 时就可以通过 `ctx.oldTitle` 拿到；`invoke` 表示调用第一个函数后，再执行 `state`。
|
||||
|
||||
通过上面的代码我们可以看到使用状态机的好处：
|
||||
|
||||
1. 状态清晰，先罗列出某个业务逻辑的全部状态，避免遗漏。
|
||||
2. 状态转换安全。比如 `preview` 只能切换到 `edit` 状态，这样就算在错误的状态发错指令也不会产生异常情况。
|
||||
|
||||
## 3 精读
|
||||
|
||||
[robot](https://github.com/matthewp/robot) 重要的函数有 `createMachine, state, transition, immediate`，下面一一拆解说明。
|
||||
|
||||
### createMachine
|
||||
|
||||
[createMachine](https://github.com/matthewp/robot/blob/master/machine.js#L122) 表示创建状态机：
|
||||
|
||||
```js
|
||||
export function createMachine(current, states, contextFn = empty) {
|
||||
if(typeof current !== 'string') {
|
||||
contextFn = states || empty;
|
||||
states = current;
|
||||
current = Object.keys(states)[0];
|
||||
}
|
||||
if(d._create) d._create(current, states);
|
||||
return create(machine, {
|
||||
context: valueEnumerable(contextFn),
|
||||
current: valueEnumerable(current),
|
||||
states: valueEnumerable(states)
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，如果传递了一个对象，通过 `Object.keys(states)[0]` 拿到第一个状态作为当前状态（标记在 `current`），最终将保存三个属性：
|
||||
|
||||
- `context` 当前状态机内部属性，初始化是空的。
|
||||
- `current` 当前状态。
|
||||
- `states` 所有状态，也就是 `createMachine` 传递的第一个参数。
|
||||
|
||||
再看 `create` 函数：
|
||||
|
||||
```js
|
||||
let create = (a, b) => Object.freeze(Object.create(a, b));
|
||||
```
|
||||
|
||||
也就是创建了一个不修改的对象作为状态机。
|
||||
|
||||
这个是 `machine` 对象：
|
||||
|
||||
```js
|
||||
let machine = {
|
||||
get state() {
|
||||
return {
|
||||
name: this.current,
|
||||
value: this.states[this.current]
|
||||
};
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
也就是说，状态机内部的状态管理是通过对象完成的，并提供了 `state()` 函数拿到当前的状态名和状态值。
|
||||
|
||||
### state
|
||||
|
||||
[state](https://github.com/matthewp/robot/blob/master/machine.js#L70) 用来描述状态支持哪些转换：
|
||||
|
||||
```js
|
||||
export function state(...args) {
|
||||
let transitions = filter(transitionType, args);
|
||||
let immediates = filter(immediateType, args);
|
||||
let desc = {
|
||||
final: valueEnumerable(args.length === 0),
|
||||
transitions: valueEnumerable(transitionsToMap(transitions))
|
||||
};
|
||||
if(immediates.length) {
|
||||
desc.immediates = valueEnumerable(immediates);
|
||||
desc.enter = valueEnumerable(enterImmediate);
|
||||
}
|
||||
return create(stateType, desc);
|
||||
}
|
||||
```
|
||||
|
||||
`transitions` 与 `immediates` 表示从 `args` 里拿到 `transition` 或 `immediate` 的结果。
|
||||
|
||||
方法是通过如下方式定义 `transition` 与 `immediate`:
|
||||
|
||||
```js
|
||||
export let transition = makeTransition.bind(transitionType);
|
||||
export let immediate = makeTransition.bind(immediateType, null);
|
||||
|
||||
function filter(Type, arr) {
|
||||
return arr.filter(value => Type.isPrototypeOf(value));
|
||||
}
|
||||
```
|
||||
|
||||
**那么如果一个函数是通过 `immediate` 创建的，就可以通过 `immediateType.isPrototypeOf()` 的校验，此方法适用范围很广，在任何库里都可以用来校验拿到对应函数创建的对象。**
|
||||
|
||||
如果参数数量为 0，表示这个状态是最终态，无法进行转换。**最后通过 `create` 创建一个对象，这个对象就是状态的值**。
|
||||
|
||||
### transition
|
||||
|
||||
[transition](https://github.com/matthewp/robot/blob/master/machine.js#L53) 是写在 `state` 中描述当前状态可以如何变换的函数，其实际函数是 `makeTransistion`:
|
||||
|
||||
```js
|
||||
function makeTransition(from, to, ...args) {
|
||||
let guards = stack(filter(guardType, args).map(t => t.fn), truthy, callBoth);
|
||||
let reducers = stack(filter(reduceType, args).map(t => t.fn), identity, callForward);
|
||||
return create(this, {
|
||||
from: valueEnumerable(from),
|
||||
to: valueEnumerable(to),
|
||||
guards: valueEnumerable(guards),
|
||||
reducers: valueEnumerable(reducers)
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
由于：
|
||||
|
||||
```js
|
||||
export let transition = makeTransition.bind(transitionType);
|
||||
export let immediate = makeTransition.bind(immediateType, null);
|
||||
```
|
||||
|
||||
可见 `from` 为 `null` 即表示立即转换到状态 `to`。`transition` 最终返回一个对象，其中 `guards` 是从 `transition` 或 `immediate` 参数中找到的，由 `guards` 函数创建的对象，当这个对象回调函数执行成功时此状态才生效。
|
||||
|
||||
`...args` 对应 `transition('toggle', 'active')` 或 `immediate('save', guard(titleIsValid))`，而 `stack(filter(guardType, args).map(t => t.fn), truthy, callBoth)` 这句话就是从 `...args` 中寻找是否有 `guards`，`reducers` 同理。
|
||||
|
||||
最后看看状态是如何改变的，设置状态改变的函数是 [transitionTo](https://github.com/matthewp/robot/blob/master/machine.js#L136):
|
||||
|
||||
```js
|
||||
function transitionTo(service, fromEvent, candidates) {
|
||||
let { machine, context } = service;
|
||||
for(let { to, guards, reducers } of candidates) {
|
||||
if(guards(context)) {
|
||||
service.context = reducers.call(service, context, fromEvent);
|
||||
|
||||
let original = machine.original || machine;
|
||||
let newMachine = create(original, {
|
||||
current: valueEnumerable(to),
|
||||
original: { value: original }
|
||||
});
|
||||
|
||||
let state = newMachine.state.value;
|
||||
return state.enter(newMachine, service, fromEvent);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，如果存在 `guards`，则需要在 `guards` 执行返回成功时才可以正确改变状态。同时 `reducers` 可以修改 `context` 也在 `service.context = reducers.call(service, context, fromEvent);` 这一行体现了出来。最后通过生成一个新的状态机，并将 `current` 标记为 `to`。
|
||||
|
||||
最后我们看 `state.enter` 这个函数，这个函数在 [state](https://github.com/matthewp/robot/blob/master/machine.js#L79) 函数中有定义，其本质是继承了 `stateType`:
|
||||
|
||||
```js
|
||||
let stateType = { enter: identity };
|
||||
```
|
||||
|
||||
而 `identity` 这个函数就是立即执行函数：
|
||||
|
||||
```js
|
||||
let identity = a => a;
|
||||
```
|
||||
|
||||
因此相当于返回了新的状态机。
|
||||
|
||||
## 4 总结
|
||||
|
||||
有限状态机相比普通业务描述，其实是增加了一些状态间转化的约束来达到优化状态管理的目的，并且状态描述也会更规范一些，在业务中具有一定的实用性。
|
||||
|
||||
当然并不是所有业务都适用有限状态机，因为新框架还是有一些学习成本要考虑。最后通过源码的学习，我们又了解到一些新的框架级小技巧，可以灵活应用到自己的框架中。
|
||||
|
||||
> 讨论地址是：[精读《robot 源码 - 有限状态机》 · Issue #209 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/209)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,486 @@
|
||||
## 1 引言
|
||||
|
||||
在写这次精读之前，我想谈谈前端精读可以为读者带来哪些价值，以及如何评判这些价值。
|
||||
|
||||
前端精读已经写到第 123 篇了，大家已经不必担心它突然停止更新，因为我已养成每周写一篇文章的习惯，而读者也养成了每周看一篇的习惯。所以我想说的其实是一种更有生命力的自媒体运作方式，定期更新。一个定期更新的专栏比一个不不定期更新的专栏更有活力，也更受读者喜爱，因为读者能看到文章之间的联系，跟随作者一起成长。个人学习也是如此，养成定期学习的习惯，比在培训班突击几个月更有用，学会在生活中规律的学习，甚至好过读几年名牌大学。
|
||||
|
||||
前端精读想带给读者的不仅是一篇篇具体的内容和知识，知识是无穷无尽的，几万篇文章也说不完，但前端精读一直沿用了“引言-概述-精读-总结”这套学习模式，无论是前端任何领域的问题，还是对人生和世界的思考都可以套用，希望能为读者提供一套学习思维框架，让你能学习到如何找到好的文章，以及如何解读它。
|
||||
|
||||
至今已经选择了许多源码解读的题材，与培训思维的源码解读不同，我希望你不要带着面试的目的学习源码，因为这样会让你只局限在 react、vue 这种热门的框架上。前端精读选取的框架类型之所以广泛，是希望你能静下心来，吸取不同框架风格与作者的优势，培养一种优雅编码的气质。
|
||||
|
||||
进入正题，这次选择的文章 [《用 Babel 创造自定义 JS 语法》](https://lihautan.com/creating-custom-javascript-syntax-with-babel/) 也是培养编码气质的一类文章，虽然对你实际工作用处不大，但这篇文章可以培养几个程序员梦寐以求的能力：深入理解 Babel、深入理解框架拓展机制。理解一个复杂系统或培养框架思维不是一朝一夕的，但持续阅读这种文章可以让你越来越接近掌握它。
|
||||
|
||||
之所以选择 Babel，是因为 Babel 处理的一直是语法树相关的底层逻辑，编译原理是程序世界的基座之一，拥有很大的学习价值。所以我们的目的并不是像文章标题说的 - 创造一个自定义 JS 语法，因为你创造的语法只会让 JS 复杂体系更加混乱，但可以让你理解 Babel 解析标准 JS 语法的原理，以及看待新语法提案时，拥有从实现层面思考的能力。
|
||||
|
||||
最后，不必多说，能重温 Babel 经典的插件机制，你可以发现 Babel 的插件拓展机制和 Antrl4 很像，在设计业务模块拓展方案时也可以作为参考。
|
||||
|
||||
## 2 概述
|
||||
|
||||
我们要利用 Babel 实现 `function @@` 的新语法，用 `@@` 装饰的函数会自动柯里化：
|
||||
|
||||
```js
|
||||
// '@@' makes the function `foo` curried
|
||||
function @@ foo(a, b, c) {
|
||||
return a + b + c;
|
||||
}
|
||||
console.log(foo(1, 2)(3)); // 6
|
||||
```
|
||||
|
||||
可以看到，`function @@ foo` 描述的函数 `foo` 支持 `foo(1, 2)(3)` 这种柯里化调用。
|
||||
|
||||
实现方式分为两步：
|
||||
|
||||
1. Fork babel 源码。
|
||||
2. 创建一个 babel 转换器插件。
|
||||
|
||||
不要畏惧这些步骤，“如果你读完了这篇文章，你将成为同事眼中的 Babel 大神” - 原文。
|
||||
|
||||
首先 Fork babel 源码到本地，执行下面的命令可以初始化并编译 babel：
|
||||
|
||||
```bash
|
||||
$ make bootstrap
|
||||
$ make build
|
||||
```
|
||||
|
||||
babel 使用 [Makefile](https://opensource.com/article/18/8/what-how-makefile) 执行编译命令，并且采用 monorepo 管理，我们这次要关心的是 `package/babel-parser` 这个模块。
|
||||
|
||||
### 词法
|
||||
|
||||
首先要了解词法知识，更详细的可以阅读原文或精读之前的一篇系列文章：[精读《词法分析》](https://github.com/dt-fe/weekly/blob/v2/064.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%8D%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md)。
|
||||
|
||||
要解析语法，首先要进行词法分析。任何语法输入都是一个字符串，比如 `function @@ foo(a, b, c)`，词法分析就是要将这个长度为 24 的字符拆分为一个个有语义的单词片段：`function` `@@` `foo` `(` `a` ..
|
||||
|
||||
由于 `@@` 是我们创造的语法，所以我们第一个任务就是让 babel 词法分析可以识别它。
|
||||
|
||||
下面是 `package/babel-parser` 的文件结构：
|
||||
|
||||
```text
|
||||
- src/
|
||||
- tokenizer/
|
||||
- parser/
|
||||
- plugins/
|
||||
- jsx/
|
||||
- typescript/
|
||||
- flow/
|
||||
- ...
|
||||
- test/
|
||||
```
|
||||
|
||||
可以看到，分为词法分析 `tokenizer`，语法分析 `parser`，以及支持一些特殊语法的插件，以及测试用例 `test`。
|
||||
|
||||
推荐使用 **Test-driven development (TDD) - 测试驱动开发的方式**，就是先写测试用例，再根据测试用例开发。这种开发方式在后端或者 babel 这种底层框架很常见，因为 TDD 方式开发的逻辑能保证测试用例 100% 覆盖，同时先看测试用例也是个很好的切面编程思维。
|
||||
|
||||
```js
|
||||
// packages/babel-parser/test/curry-function.js
|
||||
|
||||
import { parse } from '../lib';
|
||||
|
||||
function getParser(code) {
|
||||
return () => parse(code, { sourceType: 'module' });
|
||||
}
|
||||
|
||||
describe('curry function syntax', function() {
|
||||
it('should parse', function() {
|
||||
expect(getParser(`function @@ foo() {}`)()).toMatchSnapshot();
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
可以利用 jest 直接测试这段代码：
|
||||
|
||||
```bash
|
||||
BABEL_ENV=test node_modules/.bin/jest -u packages/babel-parser/test/c
|
||||
```
|
||||
|
||||
结果会出现如下报错：
|
||||
|
||||
```text
|
||||
SyntaxError: Unexpected token (1:9)
|
||||
|
||||
at Parser.raise (packages/babel-parser/src/parser/location.js:39:63)
|
||||
at Parser.raise [as unexpected] (packages/babel-parser/src/parser/util.js:133:16)
|
||||
at Parser.unexpected [as parseIdentifierName] (packages/babel-parser/src/parser/expression.js:2090:18)
|
||||
at Parser.parseIdentifierName [as parseIdentifier] (packages/babel-parser/src/parser/expression.js:2052:23)
|
||||
at Parser.parseIdentifier (packages/babel-pars
|
||||
```
|
||||
|
||||
第 9 个字符就是 `@`，说明程序现在还不支持函数前面的 `@` 解析。我们还可以在错误堆栈中找到报错位置，并把当前 Token 与下一个 Token 打印出来：
|
||||
|
||||
```js
|
||||
// packages/babel-parser/src/parser/expression.js
|
||||
|
||||
parseIdentifierName(pos: number, liberal?: boolean): string {
|
||||
if (this.match(tt.name)) {
|
||||
// ...
|
||||
} else {
|
||||
console.log(this.state.type); // current token
|
||||
console.log(this.lookahead().type); // next token
|
||||
throw this.unexpected();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`this.state.type` 代表当前 Token，`this.lookahead().type` 表示下一个 Token。`lookahead` 是词法分析的专有词，表示向后查看。打印之后，我们会发现输出了两个 `@` Token:
|
||||
|
||||
```js
|
||||
TokenType {
|
||||
label: '@',
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
下一步，我们需要让 babel 词法分析识别 `@@` 这个 Token。首先需要注册这个 Token：
|
||||
|
||||
```js
|
||||
// packages/babel-parser/src/tokenizer/types.js
|
||||
|
||||
export const types: { [name: string]: TokenType } = {
|
||||
// ...
|
||||
at: new TokenType('@'),
|
||||
atat: new TokenType('@@'),
|
||||
};
|
||||
```
|
||||
|
||||
注册了之后，我们要在遍历 Token 时增加判断 “如果当前字符是 `@` 且下一个字符也是 `@`，则整体构成了 `@@` Token 并且光标向后移动两格”：
|
||||
|
||||
```js
|
||||
// packages/babel-parser/src/tokenizer/index.js
|
||||
|
||||
getTokenFromCode(code: number): void {
|
||||
switch (code) {
|
||||
// ...
|
||||
case charCodes.atSign:
|
||||
// if the next character is a `@`
|
||||
if (this.input.charCodeAt(this.state.pos + 1) === charCodes.atSign) {
|
||||
// create `tt.atat` instead
|
||||
this.finishOp(tt.atat, 2);
|
||||
} else {
|
||||
this.finishOp(tt.at, 1);
|
||||
}
|
||||
return;
|
||||
// ...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
再次运行测试文件，输出变成了：
|
||||
|
||||
```js
|
||||
// current token
|
||||
TokenType {
|
||||
label: '@@',
|
||||
// ...
|
||||
}
|
||||
|
||||
// next token
|
||||
TokenType {
|
||||
label: 'name',
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
到这一步，已经能正确解析 `@@` Token 了。
|
||||
|
||||
## 语法
|
||||
|
||||
词法已经可以将 `@@` 解析为 `atat` Token，下一步我们就要利用这个 Token，让生成的 AST 结构中包含柯里化函数的信息，并利用 babel 插件在解析时实现柯里化功能。
|
||||
|
||||
首先我们可以在 [Babel AST explorer](https://lihautan.com/babel-ast-explorer/#?eyJiYWJlbFNldHRpbmdzIjp7InZlcnNpb24iOiI3LjYuMCJ9LCJ0cmVlU2V0dGluZ3MiOnsiaGlkZUVtcHR5Ijp0cnVlLCJoaWRlTG9jYXRpb24iOnRydWUsImhpZGVUeXBlIjp0cnVlfSwiY29kZSI6ImZ1bmN0aW9uICogZm9vKCkge30ifQ==) 看到 AST 解析的结构，我们拿 generator 函数测试，因为这个函数结构与柯里化函数类似：
|
||||
|
||||
|
||||
|
||||
可以看到，babel 通过 `generator` `async` 属性来标识函数是否为 generator 或者 async 函数。同理，增加一个 `curry` 属性就可以实现第一步了：
|
||||
|
||||
|
||||
|
||||
要实现如上效果，只需在词法分析 `parser/statement` 文件的 `parseFunction` 处新增 `atat` 解析即可：
|
||||
|
||||
```js
|
||||
// packages/babel-parser/src/parser/statement.js
|
||||
|
||||
export default class StatementParser extends ExpressionParser {
|
||||
// ...
|
||||
parseFunction<T: N.NormalFunction>(
|
||||
node: T,
|
||||
statement?: number = FUNC_NO_FLAGS,
|
||||
isAsync?: boolean = false
|
||||
): T {
|
||||
// ...
|
||||
node.generator = this.eat(tt.star);
|
||||
node.curry = this.eat(tt.atat);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`eat` 是吃掉的意思，实际上可以理解为吞掉这个 Token，这样做有两个效果：1. 为函数添加了 `curry` 属性 2. 吞掉了 `@@` 标识，保证所有 Token 都被识别是 AST 解析正确的必要条件。
|
||||
|
||||
关于递归下降语法分析的更多知识，可以参考 [精读《手写 SQL 编译器 - 语法分析》](https://github.com/dt-fe/weekly/blob/v2/066.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%AD%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md)，或者阅读原文。
|
||||
|
||||
我们再次执行测试函数，发现测试通过了，一切都在预料中。
|
||||
|
||||
## babel 插件
|
||||
|
||||
现在我们得到了标记了 `curry` 的 AST，那么最后需要一个 babel 解析插件，实现柯里化。
|
||||
|
||||
首先我们通过修改 babel 源码的方式实现的效果，是可以转化为自定义 babel parser 插件的：
|
||||
|
||||
```js
|
||||
// babel-plugin-transformation-curry-function.js
|
||||
|
||||
import customParser from './custom-parser';
|
||||
|
||||
export default function ourBabelPlugin() {
|
||||
return {
|
||||
parserOverride(code, opts) {
|
||||
return customParser.parse(code, opts);
|
||||
},
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
这样就可以实现修改 babel 源码一样的效果，这也是做框架常用的插件机制。
|
||||
|
||||
其次我们要理解如何实现柯里化。柯里化可以通过柯里函数包装后实现：
|
||||
|
||||
```js
|
||||
function currying(fn) {
|
||||
const numParamsRequired = fn.length;
|
||||
function curryFactory(params) {
|
||||
return function (...args) {
|
||||
const newParams = params.concat(args);
|
||||
if (newParams.length >= numParamsRequired) {
|
||||
return fn(...newParams);
|
||||
}
|
||||
return curryFactory(newParams);
|
||||
}
|
||||
}
|
||||
return curryFactory([]);
|
||||
}
|
||||
|
||||
// from
|
||||
function @@ foo(a, b, c) {
|
||||
return a + b + c;
|
||||
}
|
||||
|
||||
// to
|
||||
const foo = currying(function foo(a, b, c) {
|
||||
return a + b + c;
|
||||
})
|
||||
```
|
||||
|
||||
柯里化函数通过构造参数数量相关的递归，当参数传入不足时返回一个新函数，并持久化之前传入的参数，最后当参数齐全后一次性调用函数。
|
||||
|
||||
我们需要做的是，将 `@@ foo` 解析为 `currying()` 函数包裹后的新函数。
|
||||
|
||||
下面就是我们熟悉的 babel 插件部分了：
|
||||
|
||||
```js
|
||||
// babel-plugin-transformation-curry-function.js
|
||||
|
||||
export default function ourBabelPlugin() {
|
||||
return {
|
||||
// ...
|
||||
visitor: {
|
||||
FunctionDeclaration(path) {
|
||||
if (path.get('curry').node) {
|
||||
// const foo = curry(function () { ... });
|
||||
path.node.curry = false;
|
||||
path.replaceWith(
|
||||
t.variableDeclaration('const', [
|
||||
t.variableDeclarator(
|
||||
t.identifier(path.get('id.name').node),
|
||||
t.callExpression(t.identifier('currying'), [
|
||||
t.toExpression(path.node),
|
||||
])
|
||||
),
|
||||
])
|
||||
);
|
||||
}
|
||||
},
|
||||
},
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
`FunctionDeclaration` 就是 AST 的 visit 钩子，这个钩子在执行到函数时被触发，我们通过 `path.get('curry')` 拿到 **柯里化函数**，并利用 `replaceWith` 将这个函数构造为一个被 `currying` 函数包裹的新函数。
|
||||
|
||||
剩下最后一个问题：`currying` 函数源码放在哪里。
|
||||
|
||||
第一种方式，创建类似 `babel-plugin-transformation-curry-function` 这样的插件，在 babel 解析时将 `currying` 函数注册到全局，这是全局思维的方案。
|
||||
|
||||
第二种是模块化解决方案，创建一个自定义的 `@babel/helpers`，注册一个 `currying` 标识：
|
||||
|
||||
```js
|
||||
// packages/babel-helpers/src/helpers.js
|
||||
helpers.currying = helper("7.6.0")`
|
||||
export default function currying(fn) {
|
||||
const numParamsRequired = fn.length;
|
||||
function curryFactory(params) {
|
||||
return function (...args) {
|
||||
const newParams = params.concat(args);
|
||||
if (newParams.length >= numParamsRequired) {
|
||||
return fn(...newParams);
|
||||
}
|
||||
return curryFactory(newParams);
|
||||
}
|
||||
}
|
||||
return curryFactory([]);
|
||||
}
|
||||
`;
|
||||
```
|
||||
|
||||
在 visit 函数使用 `addHelper` 方式拿到 `currying`：
|
||||
|
||||
```js
|
||||
path.replaceWith(
|
||||
t.variableDeclaration('const', [
|
||||
t.variableDeclarator(
|
||||
t.identifier(path.get('id.name').node),
|
||||
t.callExpression(this.addHelper("currying"), [
|
||||
t.toExpression(path.node),
|
||||
])
|
||||
),
|
||||
])
|
||||
);
|
||||
```
|
||||
|
||||
这样在 babel 转换后，就会自动 import helper，并引用 helper 中导出的 `currying`。
|
||||
|
||||
最后原文末尾留下了一些延伸阅读内容，感兴趣的同学可以 [点击到原文](https://lihautan.com/creating-custom-javascript-syntax-with-babel/)。
|
||||
|
||||
## 3 精读
|
||||
|
||||
读完这篇文章，相信你不仅对 babel 插件有了更深刻的认识，而且还掌握了如何为 js 添加新语法这种黑魔法。
|
||||
|
||||
我来帮你从 babel 这篇文章总结一些编程模型和知识点，借助 babel 创造自定义语法的实例，加深对它们的理解。
|
||||
|
||||
### TDD
|
||||
|
||||
Test-driven development 即测试驱动的开发模式。
|
||||
|
||||
从文章的例子可以看出，创造一个新语法，可以先在测试用例先写上这个语法，通过执行测试命令通过报错堆栈一步步解决问题。这种方式开发可以让测试覆盖率更高，目的更专注，更容易保障代码质量。
|
||||
|
||||
### 联想编程
|
||||
|
||||
联想编程不属于任何编程模型，但从简介的思路来看，作者把 “为 babel 创建一个新 js 语法” 看作一种探案式探索过程，通过错误堆栈和代码阅读，一步一步通过合理联想实现最终目的。
|
||||
|
||||
在 AST 那一节，还借助了 [Babel AST explorer](https://lihautan.com/babel-ast-explorer/#?eyJiYWJlbFNldHRpbmdzIjp7InZlcnNpb24iOiI3LjYuMCJ9LCJ0cmVlU2V0dGluZ3MiOnsiaGlkZUVtcHR5Ijp0cnVlLCJoaWRlTG9jYXRpb24iOnRydWUsImhpZGVUeXBlIjp0cnVlfSwiY29kZSI6ImZ1bmN0aW9uICogZm9vKCkge30ifQ==) 工具查看 AST 结构，通过联想到 generator 函数找到类似的 AST 结构，并找到拓展 AST 的突破口。
|
||||
|
||||
随着解决问题的不同，联想方式也不同，如果能够举一反三，对不同场景都能合理的联想，才算是具备了技术专家的软素质。
|
||||
|
||||
### 词法、语法分析
|
||||
|
||||
词法、语法分析属于编译原理的知识，理解词法拆分、递归下降，可以帮助你技术走的更深。
|
||||
|
||||
不论是 Babel 插件的使用、还是 Babel 增加自定义 JS 语法，都要具备基本编译原理知识。编译原理知识还能帮助你开发在线编辑器，做智能语法提示等等。
|
||||
|
||||
### 插件机制
|
||||
|
||||
如下是 babel 自定义 parser 的插件拓展方式：
|
||||
|
||||
```js
|
||||
export default function ourBabelPlugin() {
|
||||
return {
|
||||
parserOverride(code, opts) {
|
||||
return customParser.parse(code, opts);
|
||||
},
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
这只是插件拓展的一种，有申明式，也有命令式；有用 JS 书写的，也有用 JSON 书写的。babel 选择了通过对象方式拓展，是比较适合对 AST 结构统一处理的。
|
||||
|
||||
做框架首先要确定接口规范，比如 parser，先按照接口规范实现一套官方解析，对接时按照接口进行对接，就可以自然而然被用户自定义插件替代了。
|
||||
|
||||
可以参考的文章： [精读《插件化思维》](https://github.com/dt-fe/weekly/blob/v2/053.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%8F%92%E4%BB%B6%E5%8C%96%E6%80%9D%E7%BB%B4%E3%80%8B.md)
|
||||
|
||||
### 柯里化
|
||||
|
||||
柯里化是面试经常考察的一个知识点，我们能学到的有两点：理解递归、理解如何将函数变成柯里化。
|
||||
|
||||
这里再拓展一下，我们还可以想到 JS 尾递归优化。如何快速写一个支持尾递归的函数？
|
||||
|
||||
```js
|
||||
const fn = tailCallOptimize(() => {
|
||||
if ( /* xxx */ ) {
|
||||
fn()
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
通过封装 `tailCallOptimize` 函数，可以很方便的构造一个支持尾递归的函数，这个函数可以这么写：
|
||||
|
||||
```js
|
||||
export function tailCallOptimize<T>(f: T): T {
|
||||
let value: any;
|
||||
let active = false;
|
||||
const accumulated: any[] = [];
|
||||
return function accumulator(this: any) {
|
||||
accumulated.push(arguments);
|
||||
if (!active) {
|
||||
active = true;
|
||||
while (accumulated.length) {
|
||||
value = (f as any).apply(this, accumulated.shift());
|
||||
}
|
||||
active = false;
|
||||
return value;
|
||||
}
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
感兴趣的读者可以在评论里解释一下这个函数的原理。
|
||||
|
||||
### AST visit
|
||||
|
||||
遍历 AST 树常采用的方案是做一个遍历器 visitor，所以在遍历过程中进行拓展常采用 babel 这种方式：
|
||||
|
||||
```js
|
||||
return {
|
||||
// ...
|
||||
visitor: {
|
||||
FunctionDeclaration(path) {
|
||||
if (path.get('curry').node) {
|
||||
// const foo = curry(function () { ... });
|
||||
path.node.curry = false;
|
||||
path.replaceWith(
|
||||
t.variableDeclaration('const', [
|
||||
t.variableDeclarator(
|
||||
t.identifier(path.get('id.name').node),
|
||||
t.callExpression(t.identifier('currying'), [
|
||||
t.toExpression(path.node),
|
||||
])
|
||||
),
|
||||
])
|
||||
);
|
||||
}
|
||||
},
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
`visitor` 下每一个 key 名都是遍历过程中的拓展点，比如上面的例子，我们可以对函数定义位置进行拓展和改写。
|
||||
|
||||
### 内置函数注册
|
||||
|
||||
babel 提供了两种内置函数注册方式，一种类似 polyfill，在全局注册 window 级的变量，另一种是模块化的方式。
|
||||
|
||||
除此之外，可以学习的是 babel 通过 `this.addHelper("currying")` 这种插件拓展方式，在编译后会自动从 helper 引入对应的模块，前提是 `@babel/helper` 需要注册 `currying` 这个 helper。
|
||||
|
||||
babel 将编译过程隐藏了起来，通过一些高度封装的函数调用，以较为语义化方式书写插件，这样写出来的代码也容易理解。
|
||||
|
||||
## 4 总结
|
||||
|
||||
《用 Babel 创造自定义 JS 语法》这篇文章虽然说的是 babel 相关知识，但可以从中提取到许多通用知识，这就是现在还去理解 babel 的原因。
|
||||
|
||||
从某个功能点为切面，走一遍框架的完整流程是一种高效的进阶学习方式，如果你也有看到类似这样的文章，欢迎推荐出来。
|
||||
|
||||
> 讨论地址是：[精读《用 Babel 创造自定义 JS 语法》 · Issue #210 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/210)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,372 @@
|
||||
## 1 引言
|
||||
|
||||
Flex 与 Grid 相比就像功能键盘和触摸屏。触摸屏的控制力相比功能键盘来说就像是降维打击，因为功能键盘只能上下左右控制（x、y 轴），而触摸屏打破了布局障碍，直接从（z 轴）触达，这样 **无论 UI 内部布局再复杂，都可以通过 touch 直接定位。**
|
||||
|
||||
Flex 是一维布局方式，我们需要不断嵌套 Div 才能形成复杂结构，而一旦布局产生了变化，原有嵌套结构如果不能 “兼容变化” 到新结构，代码就需要重构。而 Grid 就像触摸屏一样，可以二维布局，即便布局方式做了翻天覆地的调整，也仅需少量修改就能适配。
|
||||
|
||||
这就是这次精读 [用 css grid 重新思考布局](https://www.freecodecamp.org/news/css-grid-changes-how-we-can-think-about-structuring-our-content/) 的原因，理解这个革命性布局技术给布局，甚至代码逻辑组织带来的变化。
|
||||
|
||||
## 2 概述
|
||||
|
||||
作者首先抛出了 Flex 的问题，其实是 `block` `float` `flex` 这三种布局模式的通病：
|
||||
|
||||
- 布局结构由 Div 层级结构描述，导致 Div 层级复杂且遇到结构变更时难以维护。
|
||||
- 定制能力弱。Flex 布局有一些不受控制的智能设定，比如宽度 50% 的子元素会被同级元素挤到 50% 以下，这种智能化在某些场景是需要的，但由于没有提供像 Grid 的 `minmax` 之类的 API，所以定制型不足。
|
||||
|
||||
|
||||
|
||||
举个例子，上图的结构用 Flex 描述可能是这样的：
|
||||
|
||||
```html
|
||||
<div class="card">
|
||||
<div class="profile-sidebar">
|
||||
<img src="https://i.pravatar.cc/125?image=3" alt="" class="profile-img" />
|
||||
<ul class="social-list">
|
||||
<li>
|
||||
<a href="#" class="social-link"
|
||||
><i class="fab fa-dribbble-square"></i
|
||||
></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#" class="social-link"
|
||||
><i class="fab fa-facebook-square"></i
|
||||
></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#" class="social-link"
|
||||
><i class="fab fa-twitter-square"></i
|
||||
></a>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="profile-body">
|
||||
<h2 class="profile-name">Ramsey Harper</h2>
|
||||
<p class="profile-position">Graphic Designer</p>
|
||||
<p class="profile-info">
|
||||
Lorem ipsum dolor sit amet consectetur adipisicing elit. Facere a tempore,
|
||||
dignissimos odit accusantium repellat quidem, sit molestias dolorum
|
||||
placeat quas debitis ipsum esse rerum?
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
利用 HTML 嵌套结构，我们将图形纵向分成两大块，然后在每块内部继续嵌套划分布局，这是最经典的布局行为了。
|
||||
|
||||
|
||||
|
||||
样式文件里，我们需要对每层布局进行描述，同时支持多分辨率弹性布局，包括顶层 `card` 容器在内的一些样式需要做一定调整：
|
||||
|
||||
```scss
|
||||
.card {
|
||||
width: 80%;
|
||||
margin: 0 auto;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
max-width: 600px;
|
||||
background: #005e9b;
|
||||
flex-basis: 250px;
|
||||
color: white;
|
||||
padding: 2em;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.profile-info {
|
||||
font-weight: 300;
|
||||
opacity: 0.7;
|
||||
}
|
||||
|
||||
.profile-sidebar {
|
||||
margin-right: 2em;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.profile-name {
|
||||
letter-spacing: 1px;
|
||||
font-size: 2rem;
|
||||
margin: 0.75em 0 0;
|
||||
line-height: 1;
|
||||
}
|
||||
|
||||
.profile-name::after {
|
||||
content: "";
|
||||
display: block;
|
||||
width: 2em;
|
||||
height: 1px;
|
||||
background: #5bcbf0;
|
||||
margin: 0.5em auto 0.65em;
|
||||
opacity: 0.25;
|
||||
}
|
||||
|
||||
.profile-position {
|
||||
text-transform: uppercase;
|
||||
font-size: 0.875rem;
|
||||
letter-spacing: 3px;
|
||||
margin: 0 0 2em;
|
||||
line-height: 1;
|
||||
color: #5bcbf0;
|
||||
}
|
||||
|
||||
.profile-img {
|
||||
max-width: 100%;
|
||||
border-radius: 50%;
|
||||
border: 2px solid white;
|
||||
}
|
||||
|
||||
.social-list {
|
||||
list-style: none;
|
||||
justify-content: space-evenly;
|
||||
display: flex;
|
||||
min-width: 125px;
|
||||
max-width: 175px;
|
||||
margin: 0 auto;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
.social-link {
|
||||
color: #5bcbf0;
|
||||
opacity: 0.5;
|
||||
}
|
||||
|
||||
.social-link:hover,
|
||||
.social-link:focus {
|
||||
opacity: 1;
|
||||
}
|
||||
|
||||
.bio {
|
||||
padding: 2em;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
justify-content: center;
|
||||
}
|
||||
|
||||
@media (min-width: 450px) {
|
||||
.bio {
|
||||
text-align: left;
|
||||
max-width: 350px;
|
||||
}
|
||||
}
|
||||
|
||||
.bio-title {
|
||||
color: #0090d1;
|
||||
font-size: 1.25rem;
|
||||
letter-spacing: 1px;
|
||||
text-transform: uppercase;
|
||||
line-height: 1;
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
.bio-body {
|
||||
color: #555;
|
||||
}
|
||||
|
||||
.profile {
|
||||
display: flex;
|
||||
align-items: flex-start;
|
||||
}
|
||||
|
||||
@media (min-width: 450px) {
|
||||
.card {
|
||||
flex-direction: row;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.profile-name::after {
|
||||
margin-left: 0;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
让我们看看 Grid 是怎么做的吧！Grid 有许多 API，我们重点看 `grid-template-areas` 这个属性，利用它，我们可以不关心模块的 HTML 结构，直接平铺方式描述：
|
||||
|
||||
```html
|
||||
<div class="card">
|
||||
<img src="https://i.pravatar.cc/125?image=3" alt="" class="profile-img" />
|
||||
<ul class="social-list">
|
||||
<li>
|
||||
<a href="#" class="social-link"><i class="fab fa-dribbble-square"></i></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#" class="social-link"><i class="fab fa-facebook-square"></i></a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="#" class="social-link"><i class="fab fa-twitter-square"></i></a>
|
||||
</li>
|
||||
</ul>
|
||||
<h2 class="profile-name">Ramsey Harper</h2>
|
||||
<p class="profile-position">Graphic Designer</p>
|
||||
<p class="profile-info">
|
||||
Lorem ipsum dolor sit amet consectetur adipisicing elit. Facere a tempore,
|
||||
dignissimos odit accusantium repellat quidem, sit molestias dolorum placeat
|
||||
quas debitis ipsum esse rerum?
|
||||
</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
可以看到，使用 Grid 可以将 UI 结构与 HTML 结构分离，HTML 结构仅描述包含关系，我们只需在样式文件中描述具体 UI 结构。
|
||||
|
||||
样式文件只截取 Grid 相关部分：
|
||||
|
||||
```scss
|
||||
.card {
|
||||
width: 80%;
|
||||
margin: 0 auto;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
max-width: 600px;
|
||||
background: #005e9b;
|
||||
flex-basis: 250px;
|
||||
color: white;
|
||||
padding: 2em;
|
||||
text-align: left;
|
||||
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 3fr;
|
||||
grid-column-gap: 2em;
|
||||
grid-template-areas:
|
||||
"image name"
|
||||
"image position"
|
||||
"social description";
|
||||
}
|
||||
|
||||
.profile-name {
|
||||
grid-area: name;
|
||||
}
|
||||
.profile-position {
|
||||
grid-area: position;
|
||||
}
|
||||
.profile-info {
|
||||
grid-area: description;
|
||||
}
|
||||
.profile-img {
|
||||
grid-area: image;
|
||||
}
|
||||
.social-list {
|
||||
grid-area: social;
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，`grid-template-areas` 是进一步抽象的语法，将页面结构通过直观的文本描述，无论是理解还是修改都更为轻松。
|
||||
|
||||
这种描述方式适配不同分辨率下也具有优势，只要重组 `grid-template-areas` 即可：
|
||||
|
||||
```scss
|
||||
@media (min-width: 600px) {
|
||||
.card {
|
||||
text-align: left;
|
||||
grid-template-columns: 1fr 3fr;
|
||||
grid-template-areas:
|
||||
"image name"
|
||||
"image position"
|
||||
"social description";
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
归根结底，Grid 通过二维结构描述，将子元素布局控制收到了父级，使布局描述更加直观。
|
||||
|
||||
最后作者也提到，Flex 依然有使用场景，即简单的一维结构，或者 `space-between` 等 Flex 独有语法的情况。因此推荐整体、复杂的二维布局采用 Grid，一维的简单布局采用 Flex。
|
||||
|
||||
## 3 精读
|
||||
|
||||
Grid 的布局思路给了我很多启发，HTML 结构与 UI 结构的分离有助于减少 DIV 的层级结构，使代码看上去更清晰。
|
||||
|
||||
也许有人会疑惑，Grid 无非将 HTML 布局部分功能挪到了 CSS，整体复杂度应该不变。其实，从 `grid-template-areas` 这个 API 可以看到，Grid 不仅仅将布局功能抽到 CSS 中，更是将布局描述进行了一层抽象，使代码更易维护。
|
||||
|
||||
### 抽象，再抽象
|
||||
|
||||
为什么 Grid 可以对布局进行抽象？因为 Grid 将二维结构都掌握在手中，得到了更大的布局能力，才能进一步将结构化语法抽象为字符串的描述。
|
||||
|
||||
抽象的好处是不言而喻的，你觉得一堆嵌套的 DIV 与下面的代码，哪个更易读呢？
|
||||
|
||||
```scss
|
||||
.card {
|
||||
grid-template-areas:
|
||||
"image name"
|
||||
"image position"
|
||||
"social description";
|
||||
}
|
||||
```
|
||||
|
||||
这就是抽象的好处，一般来说，代码抽象程度越高就越易读，越易维护。
|
||||
|
||||
再看一个 Chrome Grid 插件，将 Grid 可视化显示出来，并可以以 UI 方式进行调整：
|
||||
|
||||
|
||||
|
||||
UI 是对文本的再抽象，同时可以规避一些不可能存在的语法，比如：
|
||||
|
||||
```scss
|
||||
.card {
|
||||
grid-template-areas:
|
||||
"image name"
|
||||
"image position"
|
||||
"social image";
|
||||
}
|
||||
```
|
||||
|
||||
布局只能以凸多边形方式拓展，不可能分离，也不可能突然插入一个其他模块而变成凹多边形。因此 UI 可以将这个错误规避，并简化为横竖多条线的方式对 UI 进行划分，显然这种描述方式效率更高。
|
||||
|
||||
不得不说，Grid 以及图形化插件的探索，是布局领域的一大进步，是不断抽象的尝试，要解决的问题只有一个：如何提供一种更直观的描述 UI 的方式。
|
||||
|
||||
### 布局对模块化的影响
|
||||
|
||||
Grid 将布局方式提高了一个维度，会直接影响到 JS 模块化方式。
|
||||
|
||||
尤其是以 JSX 组织代码的情况下，一个模块等于 UI + JS，通过嵌套方式的布局会让我们更倾向于站在 UI 视角划分模块。
|
||||
|
||||
|
||||
|
||||
比如对于上图模块，如果用 Flex 方式布局，我们可能会首先创建模块 X 作为左侧容器，子元素是 A 和 B，创建模块 Y 作为右侧容器，子元素是 C 以及新容器 Z，Z 容器的子元素是 D 和 E。
|
||||
|
||||
如果你的第一印象是这么组织代码，不得不承认模块化会受到布局方式的影响。虽然许多时候这样划分是正确的，但当这 5 个模块各自没有关联时，我们创建的容器 X、Y、Z 就失去了复用性，在新的组合场景我们又要重新组合一遍。
|
||||
|
||||
但是在 Grid 语法中，我们不需要 X、Y、Z，只需要用 [css grid generator](https://cssgrid-generator.netlify.com/) 按照上图的方式拖拖拽拽即可自动生成如下布局代码：
|
||||
|
||||
```scss
|
||||
.parent {
|
||||
display: grid;
|
||||
grid-template-columns: 3fr repeat(2, 1fr);
|
||||
grid-template-rows: repeat(5, 1fr);
|
||||
grid-column-gap: 0px;
|
||||
grid-row-gap: 0px;
|
||||
}
|
||||
|
||||
.div1 {
|
||||
grid-area: 1 / 1 / 3 / 2;
|
||||
}
|
||||
.div2 {
|
||||
grid-area: 3 / 1 / 6 / 2;
|
||||
}
|
||||
.div3 {
|
||||
grid-area: 1 / 2 / 2 / 4;
|
||||
}
|
||||
.div4 {
|
||||
grid-area: 2 / 2 / 6 / 3;
|
||||
}
|
||||
.div5 {
|
||||
grid-area: 2 / 3 / 6 / 4;
|
||||
}
|
||||
```
|
||||
|
||||
其实 `grid-template-columns` `grid-template-rows` 组合起来使用比 `grid-template-areas` 更强大，但是纯代码方式描述没有 `grid-template-areas` 直观，可是配合一些可视化系统就非常直观了：
|
||||
|
||||
|
||||
|
||||
将 A ～ E 这 5 个模块布局抽出来后，它们之间的关系就打平了，我们可以完全从逻辑视角审视如何做模块化了。
|
||||
|
||||
## 4 总结
|
||||
|
||||
CSS Grid 本质上是一种二维布局的语法，相比 [Block](https://www.w3schools.com/Css/css_inline-block.asp)、[Flex](https://www.w3schools.com/Css/css3_flexbox.asp) 等一维布局方案，多了一个维度可以同时从行与列角度定义布局，因此派生出 `grid-template-areas` 等语法，整体上更内聚更直观，抽象度也更高了。
|
||||
|
||||
理解了这些也就理解了布局未来的发展方向，**让布局与 Dom 分离** 一直是前端的一个梦想，开发 UI 部分时，只需关心页面由哪些模块组成，去实现这些模块就行了，而不需要关心模块之间应该如何组合。在描述组合时，可以通过可视化或比较抽象的字符串描述布局的结构，并对应到写好的模块上，这样的代码维护性远高于用 DIV 描述结构的方案。
|
||||
|
||||
> 讨论地址是：[精读《用 css grid 重新思考布局》 · Issue #211 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/211)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,136 @@
|
||||
## 1 引言
|
||||
|
||||
函数式语言在深度学习领域应用很广泛，因为函数式与深度学习模型的契合度很高，[The Beauty of Functional Languages in Deep Learning — Clojure and Haskell](https://www.welcometothejungle.co/fr/articles/btc-deep-learning-clojure-haskell) 就很好的诠释了这个道理。
|
||||
|
||||
通过这篇文章可以加深我们对深度学习与函数式编程的理解。
|
||||
|
||||
## 2 概述与精读
|
||||
|
||||
深度学习是机器学习中基于人工神经网络模型的一个分支，通过模拟多层神经元的自编码神经网络，将特征逐步抽象化，这需要多维度、大数据量的输入。[TensorFlow](https://www.tensorflow.org/) 和 [PyTorch](https://pytorch.org/) 是比较著名的 Python 深度学习框架，同样 [Keras](https://blog.rstudio.com/2017/09/05/keras-for-r/) 在 R 语言中也很著名。然而在生产环境中，基于 **性能和安全性** 的考虑，一般会使用函数式语言 [Clojure](https://www.clojure.org/) 或 [Haskell](https://www.haskell.org/)。
|
||||
|
||||
在生产环境中，可能要并发出里几百万个参数，因此面临的挑战是：如何高效、安全的执行这些运算。
|
||||
|
||||
**所以为什么函数式编程语言可以胜任深度学习的计算要求呢？** 深度学习的计算模型本质上是数学模型，而数学模型本质上和函数式编程思路是一致的：数据不可变且函数间可以任意组合。这意味着使用函数式编程语言可以更好的表达深度学习的计算过程，因此更容易理解与维护，同时函数式语言内置的 Immutable 数据结构也保障了并发的安全性。
|
||||
|
||||
另外函数式语言的函数之间都是相互隔离的，即便在多线程环境下也不会发生竞争和死锁的情况，函数式编程语言会自动处理这些情况。
|
||||
|
||||
比如说 [Clojure](https://www.clojure.org/)，**它甚至可在两个同时修改同一引用的程序并发运行时，自动重试其中之一，而不需要手动加锁**：
|
||||
|
||||
```clojure
|
||||
(import ‘(java.util.concurrent Executors))
|
||||
(defn test-stm [nitems nthreads niters]
|
||||
(let [refs (map ref (repeat nitems 0))
|
||||
pool (Executors/newFixedThreadPool nthreads)
|
||||
tasks (map (fn [t]
|
||||
(fn []
|
||||
(dotimes [n niters]
|
||||
(dosync
|
||||
(doseq [r refs]
|
||||
(alter r + 1 t))))))
|
||||
(range nthreads))]
|
||||
(doseq [future (.invokeAll pool tasks)]
|
||||
(.get future))
|
||||
(.shutdown pool)
|
||||
(map deref refs)))
|
||||
(test-stm 10 10 10000) -> (550000 550000 550000 550000 550000 550000 550000 550000 550000 550000)
|
||||
```
|
||||
|
||||
上面的代码创建了引用（refs），同时创建了多个线程自增这个引用对象，按理说每个线程都修改这个引用会导致竞争状态出现，但从结果来看是正常的，说明 Clojure 引擎在执行时会自动解决这个问题。实际上当两个线程出现竞争而失败时，Clojure 会自动重试其中之一。
|
||||
|
||||
> [原文介绍](https://clojure.org/about/concurrent_programming)
|
||||
|
||||
**Clojure 的另一个优势是并行效率高：**
|
||||
|
||||
```clojure
|
||||
(defn calculate-pixels-2 []
|
||||
(let [n (* *width* *height*)
|
||||
work (partition (/ n 16) (range 0 n))
|
||||
result (pmap (fn [x]
|
||||
(doall (map
|
||||
(fn [p]
|
||||
(let [row (rem p *width*) col (int (/ p *height*))]
|
||||
(get-color (process-pixel (/ row (double *width*)) (/ col (double *height*))))))
|
||||
x)))
|
||||
work)]
|
||||
(doall (apply concat result))))
|
||||
```
|
||||
|
||||
使用 `partition` 结合 `pmap` 可以使并发效率达到最大化，也就是 CPU 几乎都消耗在实际计算上，而不是并行的任务管理与上下文切换。Clojure 凭借 `partition` 对计算进行分区，采取分而治之并对分区计算结果进行合并的思路优化了并发性能。
|
||||
|
||||
> [原文介绍](http://www.fatvat.co.uk/2009/05/jvisualvm-and-clojure.html)
|
||||
|
||||
Clojure 另一个特性是函数链式调用：
|
||||
|
||||
```clojure
|
||||
;; pipe arg to function
|
||||
(-> "x" f1) ; "x1"
|
||||
|
||||
;; pipe. function chaining
|
||||
(-> "x" f1 f2) ; "x12"
|
||||
```
|
||||
|
||||
其中 `(-> "x" f1 f2)` 等价于 `f2(f1("x"))`，这种描述不仅更简洁清晰，也更接近于实际数学模型。
|
||||
|
||||
> [原文介绍](http://xahlee.info/clojure/clojure_function_chaining.html)
|
||||
|
||||
最后，Clojure 还具备计算安全性，计算过程不会修改已有的数据，因此在神经网络的任何一层的原始值都会保留，每层计算都可以独立运行且函数永远幂等。
|
||||
|
||||
[Haskell](https://www.haskell.org/) 也有独特的优势，**它具有类型推断、惰性求值等特性**，被认为更适合用于机器学习。
|
||||
|
||||
类型推断即 Haskell 类型都是静态的，如果试图赋予错误的类型会报错。
|
||||
|
||||
Haskell 的另一个优势是可以非常清晰的描述数学模型。
|
||||
|
||||
想想一般数学模型是怎么描述函数的：
|
||||
|
||||
```text
|
||||
fn =>
|
||||
f1 = 1
|
||||
f2 = 9
|
||||
f3 = 16
|
||||
n > 2, fn = 3fn-3 + 2fn-2 + fn-1
|
||||
```
|
||||
|
||||
一般语言用 `if-else` 描述等价关系，但 Haskell 可以几乎原汁原味的还原函数定义过程：
|
||||
|
||||
```haskell
|
||||
solve :: Int -> Interger
|
||||
solve 1 = 1
|
||||
solve 2 = 9
|
||||
solve 3 = 16
|
||||
solve n = 3 * solve (n - 3) + 2 * solve (n - 2) + solve (n - 1)
|
||||
```
|
||||
|
||||
这使得阅读 Haskell 代码和阅读数学公式一样轻松。
|
||||
|
||||
> [原文](https://blog.jle.im/entry/purely-functional-typed-models-1.html)
|
||||
|
||||
Haskell 另一个优势是惰性求值，即计算会在真正用到时才进行，而不会在计算前提前消费掉，比如：
|
||||
|
||||
```haskell
|
||||
let x = [1..]
|
||||
let y = [2,4 ..]
|
||||
head (tail tail( (zip x y)))
|
||||
```
|
||||
|
||||
可以看到，`x` 与 `y` 分别是 `1,2,3,4,5,6...` 与 `2,4,6,8...` 的无限数组，而 `zip` 函数将其整合为一个新数组 `(1,2),(2,4),(3,6),(4,8)...` 这也是无限数组，如果将 `zip` 函数执行完那么程序就会永远执行下去。但 Haskell 却不会陷入死循环，而是直接输出第一位数字 `1`。这就是惰性计算的特性，无论数组有多长，只有真正用到某项时才对其进行计算，所以哪怕初始数据量或计算量很大，实际消耗的运算资源只取决于这次计算实际用到的部分。
|
||||
|
||||
由于深度学习数据量巨大，惰性求值可以忽略海量数据输入，大大提升计算性能。
|
||||
|
||||
## 3 总结
|
||||
|
||||
本文介绍了为什么深度学习更适合使用函数式语言，以及介绍了 Clojure 与 Haskell 语言的共性：安全性、高性能，以及各自独有的特性，证明了为何这两种语言更适合用在深度学习中。
|
||||
|
||||
在前端领域说到函数式或函数之美，大部分时候想到的是 Class Component 与 Function Component 的关系，这个理解是较为片面的。通过本文我们可以了解到，函数式的思想与数学表达式思想如出一辙，以写数学公式的思维方式写代码，就是一种较好的函数式编程思路。
|
||||
|
||||
函数式应该只有表达式，没有语句，这是因为函数式是为了处理运算而诞生的，因此很适合用在深度学习领域。
|
||||
|
||||
> 讨论地址是：[精读《深度学习 - 函数式之美》 · Issue #212 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/212)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,309 @@
|
||||
## 1 引言
|
||||
|
||||
[Nuxt](https://github.com/nuxt/nuxt.js) 是基于 Vue 的前端开发框架，这次我们通过 [Introduction toNuxtJS](https://www.youtube.com/watch?v=NS0io3Z75GI) 视频了解框架特色以及前端开发框架的基本要素。
|
||||
|
||||
> nuxt 与 [next](https://github.com/zeit/next.js) 结构很像，可以结合在一起看
|
||||
|
||||
视频介绍了 NuxtJs 的安装、目录结构、页面路由、导航模版、asyncData、meta、vueX。
|
||||
|
||||
这是一个入门级视频，所以上面所列举的特征都是一个前端开发框架的最核心的基本要素。一个前端开发框架，安装、目录结构、页面路由、导航模版一定是最要下功夫认真设计的。
|
||||
|
||||
asyncData 和 Vuex 都在解决数据问题，meta 则是通过约定语法控制网页 meta 属性，这部分值得与 React 体系做对比，在精读部分再展开。
|
||||
|
||||
Nuxtjs 前端开发框架不仅提供了脚手架的基本功能，还对项目结构、代码做了约定，以减少代码量。从这点可以看出，脚手架永远围绕两个核心目标：**让每一行源码都在描述业务逻辑；让每个项目结构都相同且易读**。
|
||||
|
||||
20 年前，几百行 HTML、Css、Js 代码就能完成一个完整的项目，只需要遵守 W3C 的基本规范就足够了，每一个项目代码都简单清晰，而且由于没有复杂的业务逻辑，导致代码结构也非常简单。但现在前端项目复杂度逐渐升高，一个大型项目源码数量可能达到几十万行、几百万行，这是 W3C 规范没有设想到的，因此出现了各种工程化与模块化方案解决这个复杂度问题，也引发了各个框架间约定的割裂，且设计合理程度各不相同。
|
||||
|
||||
Nuxtjs 等框架要做的就是定义支持现代大型项目的前端研发标准，这个规范具有网络效应，即用的人越多，价值越大。
|
||||
|
||||
接下来我们进入正题，看看 Nuxt 脚手架定义了怎样的开发规范。
|
||||
|
||||
## 2 概述
|
||||
|
||||
### 安装
|
||||
|
||||
使用 `npx create-nuxt-app app-name` 创建新项目。这个命令与 `create-react-app` 一样，区别主要是模版以及配置不同。
|
||||
|
||||
这个命令本质上是拉取一个模版到本地，并安装 `nuxt` 系列脚本作为项目依赖，并自动生成一系列 npmScripts：
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"dev": "nuxt",
|
||||
"build": "nuxt build",
|
||||
"start": "nuxt start",
|
||||
"generate": "nuxt generate",
|
||||
"lint": "eslint --ext .js,.vue --ignore-path .gitignore .",
|
||||
"test": "jest"
|
||||
},
|
||||
"dependencies": {
|
||||
"nuxt": "^2.0.0"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
之后即可通过 `npm start` 等命令开发项目，对大部分项目来说，npmScripts 启动是最能达成共识的。
|
||||
|
||||
这种安装方式另一个好处是，依赖都被安装在了本地，即开发环境 100% 内置在项目中。Nuxt 没有采用全局 cli 命令方式执行，第一是 npmScripts 更符合大家通用习惯，不需要记住不同脚手架繁琐的名称与不同约定的启动命令，第二是全局脚手架一旦进行不兼容升级，老项目就面临维护难题。
|
||||
|
||||
### 目录结构
|
||||
|
||||
```text
|
||||
├── .nuxt
|
||||
├── layouts
|
||||
├── pages
|
||||
├── store
|
||||
├── assets
|
||||
├── static
|
||||
├── middleware
|
||||
├── plugins
|
||||
├── nuxt.config.js
|
||||
```
|
||||
|
||||
**pages**
|
||||
|
||||
页面文件存放的目录，路径 + 文件名即路由名，关于更多约定路由的信息，在下一节页面路由详细说明。
|
||||
|
||||
**layouts**
|
||||
|
||||
模版文件存放的目录，文件名即模版名，页面可以通过定义模版在选择使用的模版。
|
||||
|
||||
**store**
|
||||
|
||||
全局数据流目录，在 vueX 章节介绍。
|
||||
|
||||
**assets**、**static**
|
||||
|
||||
分别存放不需被编译的资源文件与非 `.vue` 的静态文件，比如 scss 文件。
|
||||
|
||||
由于 `.vue` 文件集成了 html、js、css，因此一般不会再额外定义样式文件在 static 文件夹中。
|
||||
|
||||
当然，这是 Vue 生态的特别之处，在 React 生态中会存在大量 `.scss` 文件混杂在各个目录中，比较影响阅读。
|
||||
|
||||
**middleware**、**plugins**
|
||||
|
||||
中间件与插件，这两个目录是可选的，作为一种定制化拓展能力。
|
||||
|
||||
**.nuxt**
|
||||
|
||||
为实现约定路由等便捷功能，启动项目时需要自动生成一些文件作为真正项目入口，这些文件就存储在 `.nuxt` 目录下，gitingore 且无需手动修改。
|
||||
|
||||
**nuxt.config.js**
|
||||
|
||||
nuxt 使用 js 文件作为配置文件，比 json 配置文件拓展性更好一些，这个文件也是整个项目唯一的配置文件。
|
||||
|
||||
基本上 **pages**、**layouts**、**store**、**assets**、以及唯一的配置文件基本成为现代前端开发框架的标配。
|
||||
|
||||
### 页面路由
|
||||
|
||||
nuxt 支持约定路由：
|
||||
|
||||
```text
|
||||
├── pages
|
||||
│ ├── home.vue
|
||||
│ └── index.vue
|
||||
```
|
||||
|
||||
上述目录结构描述了两个路由：`/` 与 `/home`。
|
||||
|
||||
也支持参数路由，只要以下划线作为前缀命名文件，就定义了一个动态参数路由：
|
||||
|
||||
```text
|
||||
├── pages
|
||||
│ ├── videos
|
||||
│ │ └── _id.vue
|
||||
```
|
||||
|
||||
`/videos/*` 都会指向这个文件，且可以通过 `$route.params.id` 拿到这个 url 参数。
|
||||
|
||||
另一个特性是嵌套路由：
|
||||
|
||||
```text
|
||||
├── pages
|
||||
│ ├── videos
|
||||
│ │ └── index.vue
|
||||
│ └── videos.vue
|
||||
```
|
||||
|
||||
`videos.vue` 与 `videos/index.vue` 都指向 `/videos` 这个路由，如果这两个文件同时存在，那么外层的 videos 就会作为外层拦截所有 `/videos` 文件夹下的路由，可以通过 `nuxt-child` 透出子元素：
|
||||
|
||||
```html
|
||||
# pages/videos.vue
|
||||
<template>
|
||||
<div>
|
||||
videos
|
||||
<nuxt-child />
|
||||
</div>
|
||||
</template>
|
||||
```
|
||||
|
||||
### 导航模版
|
||||
|
||||
页面公共逻辑，比如导航条可以放在模版里，模版的目录在 `layouts` 文件夹下。
|
||||
|
||||
默认 `layouts/default.vue` 对所有页面生效，但也可以创建例如 `layouts/videos.vue` 特殊导航文件，在 `pages/` 页面文件通过如下申明指定使用这个模版：
|
||||
|
||||
```html
|
||||
<script>
|
||||
export default {
|
||||
layout: "videos"
|
||||
};
|
||||
</script>
|
||||
```
|
||||
|
||||
### asyncData
|
||||
|
||||
`asyncData` 是 nuxt 支持的异步取数函数，可以替代 `data`。
|
||||
|
||||
`data` 函数：
|
||||
|
||||
```html
|
||||
<script>
|
||||
export default {
|
||||
data() {
|
||||
return {};
|
||||
}
|
||||
};
|
||||
</script>
|
||||
```
|
||||
|
||||
对于异步场景，可以用 `asyncData` 替代：
|
||||
|
||||
```html
|
||||
<script>
|
||||
export default {
|
||||
async asyncData() {
|
||||
return await fetch("/");
|
||||
}
|
||||
};
|
||||
</script>
|
||||
```
|
||||
|
||||
### meta
|
||||
|
||||
nuxt 允许在 `.vue` 页面文件自定义 head 标签信息：
|
||||
|
||||
```html
|
||||
<script>
|
||||
export default {
|
||||
headr() {
|
||||
return {
|
||||
title: "",
|
||||
meta: {
|
||||
charset: "utf-8"
|
||||
}
|
||||
};
|
||||
}
|
||||
};
|
||||
</script>
|
||||
```
|
||||
|
||||
这是开发框架提供的特性，不过在 React 体系下可以通过 `useTitle` 等自定义 Hooks 解决此问题，将框架功能降维到代码功能，会更容易理解些。
|
||||
|
||||
### vueX
|
||||
|
||||
nuxt 集成了 [vuex](https://github.com/vuejs/vuex)，在 `store/` 文件夹下创建数据模型：
|
||||
|
||||
```js
|
||||
export const state = () => ({
|
||||
videos: [],
|
||||
currentVideo: {}
|
||||
})
|
||||
|
||||
export const mutations = {
|
||||
SET_VIDEOS (state, videos) {
|
||||
state.videos = videos
|
||||
}
|
||||
SET_CURRENT_VIDEO (state, video) {
|
||||
state.currentVideo = video
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
接下来就能在 `pages` 文件夹下的页面组件使用了：
|
||||
|
||||
```html
|
||||
<script>
|
||||
import { mapState } from "vuex";
|
||||
|
||||
export default {
|
||||
async fetch({ $axios, params, store }) {
|
||||
const reponse = await $axios.get(`/videos/${params.id}`);
|
||||
const video = response.data.data.arrtibutes;
|
||||
store.commit("SET_CURRENT_VIDEO", video);
|
||||
}
|
||||
};
|
||||
</script>
|
||||
```
|
||||
|
||||
将 `return` 替换为 `store.commit` 即可，更多语法可以参考 [vuex 文档](https://github.com/vuejs/vuex)。
|
||||
|
||||
## 3 精读
|
||||
|
||||
Nuxtjs 框架做了几件事情：
|
||||
|
||||
1. 统一执行命令。
|
||||
2. 统一开发框架。
|
||||
3. 统一目录与代码规范。
|
||||
4. 内置公共 utils 函数。
|
||||
|
||||
### 统一执行命令
|
||||
|
||||
命令行是所有开发者每天都要用上十几次甚至几十次的场景，试想一下团队中项目分别有如下这么多不同的启动命令会怎么样？
|
||||
|
||||
1. npm start.
|
||||
2. monkey dev.
|
||||
3. npm run ng.
|
||||
4. npm run bootstrap & banana start.
|
||||
5. ...
|
||||
|
||||
我永远不知道下一个项目该如何启动，这大大降低了开发效率。更严重的是，有的项目可以通过 `npm run docs` 查看文档，有的项目不能；有的项目 `npm run build` 可以触发编译，有的项目却无需编译，等等，所谓的环境不一致或者说迁移成本，学习成本，都是由最开始负责搭建项目脚手架的同学对架构设计不一致导致的，**然而没有必须用 `monkey dev` 才能运行起来的项目，但项目却可能因为被设计为 `monkey dev` 启动而显得与其他项目格格不入，甚至难以统一维护。**
|
||||
|
||||
Nuxtjs 等前端开发框架统一执行命令就是为了解决这个问题，统一开发者习惯需要很长的时间周期，但这个趋势不可挡。
|
||||
|
||||
### 统一开发框架
|
||||
|
||||
**虽然现在 React、Vue、Angular 框架各有利弊，但如果一个团队的项目同时使用了两个以上的框架，没有人会觉得这是一件好事。**
|
||||
|
||||
诚然每个框架都有自己的特点，在不同维度都一些优势，但三大框架能并存，说明各自都没有绝对的杀手锏来消灭对方。
|
||||
|
||||
对开源来说，多元化是活力的源动力，但对一家公司来说，多元化就是一场灾难，至今没有一个框架敢说自己的优势是 “与其他框架混合使用可以提升整体开发效率”。
|
||||
|
||||
前端开发框架要解决的最重要问题也是这一点，无论如何只能选择一种开发框架，Nuxtjs 选择了 Vue，Nextjs 选择了 React。
|
||||
|
||||
### 统一目录与代码规范
|
||||
|
||||
目录和代码规范不会从根本上影响项目的通用性，因为不同的目录结构可以通过映射来兼容，不同的代码规范不会影响代码执行。所以目录与代码规范真正影响的是一个程序员对项目的 “解码成本”。
|
||||
|
||||
所谓解码成本，就是程序员理解项目逻辑所需要的成本。如果你是一个销售主管，让团队周报统一用一种格式汇总绝对比 “用自己喜欢的方式汇总” 效率高，而对编程也一样，一个完全不同的目录结构和代码规范对程序员来说是巨大的阅读阻碍，甚至可能引发恶心反应。
|
||||
|
||||
所以不同的目录结构和代码规范是没有必要的壁垒，除非你的团队已经对某种规范产生达成了牢固的共识，否则最好和其他团队共享相同的目录结构与代码规范。改变代码规范是一件很难得事情，但只要不同规范的团队间产生了长期合作关系，规范统一就势必会被提上议程，那么为何不能在公司层面早一点达成共识，提前消除这种痛苦呢？
|
||||
|
||||
所以统一目录与代码规范是前端开发框架需要优先确定的，很多时候不要去质疑为什么目录叫 `layouts` 而不叫 `layout`，因为这个规范背后形成的协同网络规模越大，叫什么名字就越不重要。
|
||||
|
||||
### 内置公共 utils 函数
|
||||
|
||||
让业务开发更聚焦，还可以通过抽取通用的逻辑的方式解决，但需要解决两个问题：
|
||||
|
||||
1. 虽然将公共函数抽成 npm 包可以解决代码复用问题，但关键是怎么保证你的代码能被别人复用？
|
||||
2. 如何让业务通用的 utils 代码有效沉淀并从项目中移除？
|
||||
|
||||
脚手架内置公共 utils 函数就为了解决这个问题。上面几个小节解决了通用命令、框架、规范，但实际代码中，`router` `history` `fetch` `store` 等等概念也都是可以统一的，**没有一个项目必须用定制的 `fetch` 函数才能取数，但一开始就定制了 `fetch` 会导致耦合了不可预期的、没有必要的业务逻辑，成为理解与提效的阻碍。**
|
||||
|
||||
所以统一这些能统一的包，是进一步提效的关键。也许有人会觉得断了自己造轮子的路，但就像我们如今都不会重写浏览器内核逻辑一样，稳定的逻辑不仅带来了全行业的提效，还催生了前端岗位带来大量的就业，同样的，统一底层通用函数，其实是断了无意义产出这条路，每个人都有追求更高价值事情的权利，不要把自己困在反复造 `fetch` 函数这个低水平的活里。
|
||||
|
||||
## 4 总结
|
||||
|
||||
如果一个项目没有使用类似 Nuxtjs 开发框架，它面临的不仅仅是技术选型不统一的问题，久而久之这种项目势必成为 **代码孤岛**，当尘封在代码仓库几年后，一系列文档工具链接都失效后，就成为谁也不想碰，不敢碰的高危代码。
|
||||
|
||||
所以我们今天不仅要看到 Nuxtjs 提供的能力对项目开发有多么便捷，更要看到这类框架带来的协同效应有多么巨大，如果它不能成为整个前端的标准，至少要成为你们公司，或者你们团队的标准。
|
||||
|
||||
> 讨论地址是：[精读《Nuxtjs》 · Issue #213 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/213)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,702 @@
|
||||
## 1 引言
|
||||
|
||||
[React Conf 2019](https://www.youtube.com/watch?v=RCiccdQObpo) 在今年 10 月份举办，内容质量还是一如既往的高，如果想进一步学习前端或者 React，这个大会一定不能错过。
|
||||
|
||||
希望前端精读成为你学习成长路上的布道者，所以本期精读就介绍 React Conf 2019 - Day1 的相关内容。
|
||||
|
||||
总的来看，React Conf 今年的内容视野更广了，不仅仅有技术内容，还有宣扬公益、拓展到移动端、后端，最后还有对 web 发展的总结与展望。
|
||||
|
||||
前端世界正变得越来越复杂，可以看到大家对未来都充满了希望，永不停歇的探索精神是这场大会的主旋律。
|
||||
|
||||
## 2 概述 & 精读
|
||||
|
||||
本期大会思想、设计上的内容较多，具体实现层内容较少，因为行业领导者需要引领规范，而真正技术价值在于思维模型与算法，理解了解题思路，实现它其实并不难。
|
||||
|
||||
### 开发者体验与用户体验
|
||||
|
||||
- 开发者体验：DX（develop experience）
|
||||
- 用户体验：UX（user experience）
|
||||
|
||||
技术人解决的问题总是围绕 DX 与 UX，而一般来说，优化了 DX 往往会带来 UX 的提升，这是因为一个解决开发者体验的技术创新往往也会带来用户体验的升级，至少也能让开发者有更好的心情、更充足的时间做出好产品。
|
||||
|
||||
如何优化开发者体验呢？
|
||||
|
||||
**易上手**
|
||||
|
||||
React 确实致力于解决这个问题，因为 React 实际上是一个开发者桥梁，无论你开发 web、ios 还是单片机，都可以通过一套统一的语法去实现。React 是一个协议标准（读到 reactReconciler 章节会更有体感），React 像 HTML，但 React 不止能构建 HTML 应用，React 希望构建一切。
|
||||
|
||||
**高效开发**
|
||||
|
||||
React 解决调试、工具问题，让开发者更高效的完成工作，这也是开发者体验重要组成部分。
|
||||
|
||||
**弹性**
|
||||
|
||||
React 编写的程序拥有良好可维护性，包括数据驱动、模块化等等特征都是为了更好服务于不同规模的团队。
|
||||
|
||||
对于 UX 问题，React 也有 Concurrent mode、Suspense 等方案。
|
||||
|
||||
虽然 React 还不完美，但 React 致力于解决 DX 与 UX 的目标和效果都是我们有目共睹的，更好的 DX、UX 一定是前端技术未来发展的大趋势。
|
||||
|
||||
### 样式方案
|
||||
|
||||
Facebook 使用 css-in-js，而今年的 React conf 给出了一种技术方案，将 413 kb 的样式文件体积降低到 74kb！
|
||||
|
||||
一步步了解这个方案，从用法开始：
|
||||
|
||||
```tsx
|
||||
const styles = stylex.create({
|
||||
blue: { color: "blue" },
|
||||
red: { color: "red" }
|
||||
});
|
||||
|
||||
function MyComponent(props) {
|
||||
return <span className={styles("blue", "red")}>I'm red now!</span>;
|
||||
}
|
||||
```
|
||||
|
||||
如上是这个方案的写法，通过 `stylex.create` 创建样式，通过 `styles()` 使用样式。
|
||||
|
||||
**主题方案**
|
||||
|
||||
如果使用 CSS 变量定义主题，那么换肤就可以由最外层 `class` 轻松决定了：
|
||||
|
||||
```scss
|
||||
.old-school-theme {
|
||||
--link-text: blue;
|
||||
}
|
||||
|
||||
.text-link {
|
||||
color: var(--link-text);
|
||||
}
|
||||
```
|
||||
|
||||
字体颜色具体的值由外层 `class` 决定，因此外层的 `class` 就可以控制所有子元素的样式：
|
||||
|
||||
```html
|
||||
<div class="old-school-theme">
|
||||
<a class="text-link" href="...">
|
||||
I'm blue!
|
||||
</a>
|
||||
</div>
|
||||
```
|
||||
|
||||
将其封装成 React 组件，也不需要用 `context` 等 JS 能力，而是包裹一层 `class` 即可。
|
||||
|
||||
```tsx
|
||||
function ThemeProvider({ children, theme }) {
|
||||
return <div className={themes[theme]}>{children}</div>;
|
||||
}
|
||||
```
|
||||
|
||||
**图标方案**
|
||||
|
||||
下面是设计师给出的 svg 代码：
|
||||
|
||||
```tsx
|
||||
<svg viewBox="0 0 100 100">
|
||||
<path d="M9 25C8 25 8..." />
|
||||
</svg>
|
||||
```
|
||||
|
||||
将其包装为 React 组件：
|
||||
|
||||
```tsx
|
||||
function SettingsIcon(props) {
|
||||
return (
|
||||
<SVGIcon viewBox="0 0 100 100" {...props}>
|
||||
<path d="M9 25C8 25 8..." />
|
||||
</SVGIcon>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
结合上面提到的主题方案，就可以控制 svg 的主题颜色。
|
||||
|
||||
```tsx
|
||||
const styles = stylex.create({
|
||||
primary: { fill: "var(--primary-icon)" },
|
||||
gighlight: { fill: "var(--highlight-icon)" }
|
||||
});
|
||||
|
||||
function SVGIcon(color, ...props) {
|
||||
return (
|
||||
<svg>
|
||||
{...props}
|
||||
className={styles({
|
||||
primary: color === "primary",
|
||||
highlight: color === "highlight"
|
||||
})}
|
||||
{children}
|
||||
</svg>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
**减少样式大小的秘密**
|
||||
|
||||
```tsx
|
||||
const styles = stylex.create({
|
||||
blue: { color: "blue" },
|
||||
default: { color: "red", fontSize: 16 }
|
||||
});
|
||||
|
||||
function MyComponent(props) {
|
||||
return <span className={styles("default", props.isBlue && "blue")} />;
|
||||
}
|
||||
```
|
||||
|
||||
对于上述样式文件代码，最终会编译成 `c1`、`c2`、`c3` 三个 `class`：
|
||||
|
||||
```scss
|
||||
.c1 {
|
||||
color: blue;
|
||||
}
|
||||
.c2 {
|
||||
color: red;
|
||||
}
|
||||
.c3 {
|
||||
font-size: 16px;
|
||||
}
|
||||
```
|
||||
|
||||
出乎意料的是，并没有根据 `blue` 和 `default` 生成对应的 `class`，而是根据实际样式值生成 `class`，这样做有什么好处呢？
|
||||
|
||||
首先是加载顺序，`class` 生效的顺序与加载顺序有关，而按照样式值生成的 `class` 可以精确控制样式加载顺序，使其与书写顺序对应：
|
||||
|
||||
```tsx
|
||||
// 效果可能是 blue 而不是 red
|
||||
<div className="blue red" />
|
||||
|
||||
// 效果一定是 red，因为 css-in-js 在最终编排 class 时，虽然两种样式都存在，但书写顺序导致最后一个优先级最高，
|
||||
// 合并的时候就会舍弃失效的那个 class
|
||||
<div className={styles('blue', 'red')} />
|
||||
```
|
||||
|
||||
这么做永远不会出现头疼的样式覆盖问题。
|
||||
|
||||
更重要的是，随着样式文件的增多，`class` 总量会减少。这是因为新增的 `class` 涵盖的属性可能已经被其他 `class` 写到并生成了，此时会直接复用对应属性生成的 `class` 而不会生成新的：
|
||||
|
||||
```tsx
|
||||
<Component1 className=".class1"/>
|
||||
<Component2 className=".class2"/>
|
||||
```
|
||||
|
||||
```scss
|
||||
.class1 {
|
||||
background-color: mediumseagreen;
|
||||
cursor: default;
|
||||
margin-left: 0px;
|
||||
}
|
||||
.class2 {
|
||||
background-color: thistle;
|
||||
cursor: default;
|
||||
justify-self: flex-start;
|
||||
margin-left: 0px;
|
||||
}
|
||||
```
|
||||
|
||||
正如这个 Demo 所示，正常情况的 `class1` 与 `class2` 存在许多重复定义的属性，但换成 css-in-js 的方案，编译后的效果等价于将 `class` 复用并拆解了：
|
||||
|
||||
```tsx
|
||||
<Component1 classNames=".classA .classB .classD">
|
||||
|
||||
<Component2 classNames=".classA .classC .classD .classE">
|
||||
```
|
||||
|
||||
```scss
|
||||
.classA {
|
||||
cursor: default;
|
||||
}
|
||||
.classB {
|
||||
background-color: mediumseagreen;
|
||||
}
|
||||
.classC {
|
||||
background-color: thistle;
|
||||
}
|
||||
.classD {
|
||||
margin-left: 0px;
|
||||
}
|
||||
.classE {
|
||||
justify-self: flex-start;
|
||||
}
|
||||
```
|
||||
|
||||
这种方式不仅节省空间、还能自动计算样式优先级避免冲突，并将 413 kb 的样式文件体积降低到 74kb。
|
||||
|
||||
### 字体大小方案
|
||||
|
||||
`rem` 的好处是相对的字体大小，使用 `rem` 作为单位可以很方便实现网页字体大小的切换。
|
||||
|
||||
但问题是现在工业设计都习惯了以 px 作为单位，所以一种全新的编译方案产生了：在编译阶段将 `px` 自动转换成 `rem`。
|
||||
|
||||
这等于让以 `px` 为单位的字体大小可以跟随根节点字体大小随意缩放。
|
||||
|
||||
### 代码检测
|
||||
|
||||
静态检测类型错误、拼写错误、浏览器兼容问题。
|
||||
|
||||
在线检测 dom 节点元素问题，比如是否有可访问性，比如替代文案 aria-label。
|
||||
|
||||
### 提升加载速度
|
||||
|
||||
普通网页的加载流程是这样的：
|
||||
|
||||
|
||||
|
||||
先加载代码，然后会渲染页面，在渲染的同时发取数请求，等取数完成后才能渲染出真实数据。
|
||||
|
||||
那么如何改善这个情况呢？首先是预取数，提前解析出请求并在脚本加载的同时取数，可以节省大量时间：
|
||||
|
||||
|
||||
|
||||
那么下载的代码可以再拆分吗？注意到并不是所有代码都作用于 UI 渲染，我们可以将模块分为 `ImportForDisplay` 与 `importForAfterDisplay` ：
|
||||
|
||||
|
||||
|
||||
这样就可以优先加载与 UI 相关的代码，其余逻辑代码在页面展示出之后再加载：
|
||||
|
||||
|
||||
|
||||
这样可以实现源码分段加载，并分段渲染：
|
||||
|
||||
|
||||
|
||||
对取数来说也是如此，并不是所有取数都是初始化渲染阶段必须用上的。可以通过 `relay` 的特性 `@defer` 标记出可以延迟加载的数据：
|
||||
|
||||
```relay
|
||||
fragment ProfileData on User {
|
||||
classNameprofile_picture { ... }
|
||||
|
||||
...AdditionalData @defer
|
||||
}
|
||||
```
|
||||
|
||||
这下取数也可以分段了，首屏的数据会优先加载：
|
||||
|
||||
|
||||
|
||||
利用 `relay` 还可以以数据驱动方式结合代码拆分：
|
||||
|
||||
```relay
|
||||
... on Post {
|
||||
... on PhotoPost {
|
||||
@module('PhotoComponent.js')
|
||||
photo_data
|
||||
}
|
||||
|
||||
... on VideoPost {
|
||||
@module('VideoComponent.js')
|
||||
video_data
|
||||
}
|
||||
|
||||
... on SongPost {
|
||||
@module('SongComponent.js')
|
||||
song_data
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
这样首屏数据中也只会按需加载用到的部分，请求时间可以再次缩短：
|
||||
|
||||
|
||||
|
||||
可以看到，与 relay 结合可以进一步优化加载性能。
|
||||
|
||||
### 加载体验
|
||||
|
||||
可以 `React.Suspense` 与 `React.lazy` 动态加载组件。通过 `fallback` 指定元素的占位图可以提升加载体验：
|
||||
|
||||
```tsx
|
||||
<React.Suspense fallback={<MyPlaceholder />}>
|
||||
<Post>
|
||||
<Header />
|
||||
<Body />
|
||||
<Reactions />
|
||||
<Comments />
|
||||
</Post>
|
||||
</React.Suspense>
|
||||
```
|
||||
|
||||
`Suspense` 可以被嵌套，资源会按嵌套顺序加载，保证一个自然的视觉连贯性。
|
||||
|
||||
### 智能文档
|
||||
|
||||
通过解析 Markdown 自动生成文档大家已经很熟悉了，也有很多现成的工具可以用，但这次分享的文档系统有意思之处在于，可以动态修改源码并实时生效。
|
||||
|
||||
|
||||
|
||||
不仅如此，还利用了 Typescript + MonacoEditor 在网页上做语法检测与 API 自动提示，这种文档体验上升了一个档次。
|
||||
|
||||
虽然没有透露技术实现细节，但从热更新的操作来看像是把编译工作放在了浏览器 web worker 中，如果是这种实现方式，原理与 [CodeSandbox 实现原理](https://segmentfault.com/a/1190000019679430) 类似。
|
||||
|
||||
### GraphQL and Stuff
|
||||
|
||||
这一段在安利利用接口自动生成 Typescript 代码提升前后端联调效率的工具，比如 go2dts。
|
||||
|
||||
我们团队也开源了基于 swagger 的 Typescript 接口自动生成工具 [pont](https://github.com/alibaba/pont)，欢迎使用。
|
||||
|
||||
### React Reconciler
|
||||
|
||||
这是知识密度最大的一节，介绍了如何使用 React Reconclier。
|
||||
|
||||
React Reconclier 可以创建基于任何平台的 React 渲染器，也可以理解为通过 React Reconclier 可以创建自定义的 ReactDOM。
|
||||
|
||||
比如下面的例子，我们尝试用自定义函数 `ReactDOMMini` 渲染 React 组件：
|
||||
|
||||
```jsx
|
||||
import React from "react";
|
||||
import logo from "./logo.svg";
|
||||
import ReactDOMMini from "./react-dom-mini";
|
||||
import "./App.css";
|
||||
|
||||
function App() {
|
||||
const [showLogo, setShowLogo] = React.useState(true);
|
||||
|
||||
let [color, setColor] = React.useState("red");
|
||||
React.useEffect(() => {
|
||||
let colors = ["red", "green", "blue"];
|
||||
let i = 0;
|
||||
let interval = setInterval(() => {
|
||||
i++;
|
||||
setColor(colors[i % 3]);
|
||||
}, 1000);
|
||||
|
||||
return () => clearInterval(interval);
|
||||
});
|
||||
|
||||
return (
|
||||
<div
|
||||
className="App"
|
||||
onClick={() => {
|
||||
setShowLogo(show => !show);
|
||||
}}
|
||||
>
|
||||
<header className="App-header">
|
||||
{showLogo && <img src={logo} className="App-logo" alt="logo /" />}
|
||||
// 自创语法
|
||||
<p bgColor={color}>
|
||||
Edit <code>src/App.js</code> and save to reload.
|
||||
</p>
|
||||
<a
|
||||
className="App-link"
|
||||
href="https://reactjs.org"
|
||||
target="_blank"
|
||||
rel="noopener noreferrer"
|
||||
>
|
||||
Learn React{" "}
|
||||
</a>
|
||||
</header>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
ReactDOMMini.render(<App />, codument.getElementById("root"));
|
||||
```
|
||||
|
||||
`ReactDOMMini` 是利用 `ReactReconciler` 生成的自定义组件渲染函数，下面是完整的代码：
|
||||
|
||||
```typescript
|
||||
import ReactReconciler from "react-reconciler";
|
||||
|
||||
const reconciler = ReactReconciler({
|
||||
createInstance(
|
||||
type,
|
||||
props,
|
||||
rootContainerInstance,
|
||||
hostContext,
|
||||
internalInstanceHandle
|
||||
) {
|
||||
const el = document.createElement(type);
|
||||
|
||||
["alt", "className", "href", "rel", "src", "target"].forEach(key => {
|
||||
if (props[key]) {
|
||||
el[key] = props[key];
|
||||
}
|
||||
});
|
||||
|
||||
// React 事件代理
|
||||
if (props.onClick) {
|
||||
el.addEventListener("click", props.onClick);
|
||||
}
|
||||
|
||||
// 自创 api bgColor
|
||||
if (props.bgColor) {
|
||||
el.style.backgroundColor = props.bgColor;
|
||||
}
|
||||
|
||||
return el;
|
||||
},
|
||||
|
||||
createTextInstance(
|
||||
text,
|
||||
rootContainerInstance,
|
||||
hostContext,
|
||||
internalInstanceHandle
|
||||
) {
|
||||
return document.createTextNode(text);
|
||||
},
|
||||
|
||||
appendChildToContainer(container, child) {
|
||||
container.appendChild(child);
|
||||
},
|
||||
appendChild(parent, child) {
|
||||
parent.appendChild(child);
|
||||
},
|
||||
appendInitialChild(parent, child) {
|
||||
parent.appendChild(child);
|
||||
},
|
||||
|
||||
removeChildFromContainer(container, child) {
|
||||
container.removeChild(child);
|
||||
},
|
||||
removeChild(parent, child) {
|
||||
parent.removeChild(child);
|
||||
},
|
||||
insertInContainerBefore(container, child, before) {
|
||||
container.insertBefore(child, before);
|
||||
},
|
||||
insertBefore(parent, child, before) {
|
||||
parent.insertBefore(child, before);
|
||||
},
|
||||
|
||||
prepareUpdate(
|
||||
instance,
|
||||
type,
|
||||
oldProps,
|
||||
newProps,
|
||||
rootContainerInstance,
|
||||
currentHostContext
|
||||
) {
|
||||
let payload;
|
||||
if (oldProps.bgColor !== newProps.bgColor) {
|
||||
payload = { newBgCOlor: newProps.bgColor };
|
||||
}
|
||||
return payload;
|
||||
},
|
||||
commitUpdate(
|
||||
instance,
|
||||
updatePayload,
|
||||
type,
|
||||
oldProps,
|
||||
newProps,
|
||||
finishedWork
|
||||
) {
|
||||
if (updatePayload.newBgColor) {
|
||||
instance.style.backgroundColor = updatePayload.newBgColor;
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
const ReactDOMMini = {
|
||||
render(wahtToRender, div) {
|
||||
const container = reconciler.createContainer(div, false, false);
|
||||
reconciler.updateContainer(whatToRender, container, null, null);
|
||||
}
|
||||
};
|
||||
|
||||
export default ReactDOMMini;
|
||||
```
|
||||
|
||||
笔者拆解一下说明：
|
||||
|
||||
React 之所以具备跨平台特性，是因为其渲染函数 `ReactReconciler` **只关心如何组织组件与组件间关系，而不关心具体实现**，所以会暴露出一系列回调函数。
|
||||
|
||||
**创建实例**
|
||||
|
||||
由于 React 组件本质是一个描述，即 `tag` + 属性，所以 `Reconciler` 不关心元素是如何创建的，需要通过 `createInstance` 拿到组件基本属性，在 Web 平台利用 DOM API 实现：
|
||||
|
||||
```typescript
|
||||
createInstance(
|
||||
type,
|
||||
props,
|
||||
rootContainerInstance,
|
||||
hostContext,
|
||||
internalInstanceHandle
|
||||
) {
|
||||
const el = document.createElement(type);
|
||||
|
||||
["alt", "className", "href", "rel", "src", "target"].forEach(key => {
|
||||
if (props[key]) {
|
||||
el[key] = props[key];
|
||||
}
|
||||
});
|
||||
|
||||
// React 事件代理
|
||||
if (props.onClick) {
|
||||
el.addEventListener("click", props.onClick);
|
||||
}
|
||||
|
||||
// 自创 api bgColor
|
||||
if (props.bgColor) {
|
||||
el.style.backgroundColor = props.bgColor;
|
||||
}
|
||||
|
||||
return el;
|
||||
}
|
||||
```
|
||||
|
||||
之所以说 React 对 DOM 事件都做了一层代理，是因为 JSX 的所有函数都没有真正透传给 DOM，而是通过类似 `el.addEventListener("click", props.onClick)` 的方式代理实现的。
|
||||
|
||||
而自定义这个函数，我们甚至能创建例如 `bgColor` 这种特殊语法，只要解析引擎实现了这个语法的 Handler。
|
||||
|
||||
除此之外，还有 **创建、删除实例** 的回调函数，我们都要利用 DOM 平台的 API 重新实现一遍，这样不仅可以实现对浏览器 API 的兼容，还可以对接到比如 react-native 等非 WEB 平台。
|
||||
|
||||
**更新组件**
|
||||
|
||||
实现了 `prepareUpdate` 与 `commitUpdate` 才能完成组件更新。
|
||||
|
||||
`prepareUpdate` 返回的 `payload` 被 `commitUpdate` 函数接收到，并根据接收到的信息决定如何更新实例节点。这个实例节点就是 `createInstance` 回调函数返回的对象，所以如果在 WEB 环境返回的 instance 就是 DOMInstance，后续所有操作都使用 DOMAPI。
|
||||
|
||||
总结一下：`react` 主要用平台无关的语法生成具有业务含义的 AST，而利用 `react-reconciler` 生成的渲染函数可以解析这个 AST，并提供了一系列回调函数实现完整的 UI 渲染功能，`react-dom` 现在也是基于 `react-reconciler` 写的。
|
||||
|
||||
### 图标体积优化
|
||||
|
||||
Facebook 团队通过优化，将图标大小从 4046.05KB 降低到了 132.95kb，体积减少了惊人的 96.7%，减少体积占总包体积的 19.6%！
|
||||
|
||||
实现方式很简单，下面是原始图标使用的代码：
|
||||
|
||||
```jsx
|
||||
<FontAwesomeIcon icon="coffee" />
|
||||
<Icon icon={["fab", "twitter"]} />
|
||||
<Button leftIcon="user" />
|
||||
<FeatureGroup.Item icon="info" />
|
||||
<FeatureGroup.Item icon={["fail", "info"]} />
|
||||
```
|
||||
|
||||
在编译期间通过 AST 分析，将所有字符串引用换成了图标实例的引用，利用 webpack 的 tree-shaking 功能实现按需加载，从而删除了没有使用到的图标。
|
||||
|
||||
```jsx
|
||||
import {faCoffee,faInfo,faUser} from "@fontawesome/free-solid-svg-icons"
|
||||
import {faTwitter} from '@fontawesome/free-brands-svg-icons'
|
||||
import {faInfo as faInfoFal} from '@fontawesome/pro-light-svg-icons'
|
||||
|
||||
<FontAwesomeIcon icon={faCoffee} />
|
||||
<Icon icon={faTwitter} />
|
||||
<Button leftIcon={faUser} />
|
||||
<FeatureGroup.Item icon={faInfo} />
|
||||
<FeatureGroup.Item icon={faInfoFal} />
|
||||
```
|
||||
|
||||
[替换工具](https://github.com/skovy/font-awesome-codemod) 的链接放出来了，感兴趣的同学可以点进去了解更多。
|
||||
|
||||
这也从某种意义上说明了 iconFont 注定被淘汰，因为字体文件目前无法按需加载，只有全部使用 SVG 图标的项目才能使用这种优化。
|
||||
|
||||
### Git & Github
|
||||
|
||||
这一节介绍了基本 Git 知识以及 Github 用法，笔者略过比较水的部分，直接列出两个可能你不知道的点：
|
||||
|
||||
**干预 Github 项目主要语言检测**
|
||||
|
||||
如果你提交的代码包含许多自动生成的文件，可能你实际使用的语言不会被 Github 解析为主要语言，这时候可以通过 `.gitattributes` 文件忽略指定文件夹的检测：
|
||||
|
||||
```text
|
||||
static/* linguist-vendored
|
||||
```
|
||||
|
||||
这样语言文件占比统计就会忽略 `static/` 文件夹。
|
||||
|
||||
**Git hooks 的技巧**
|
||||
|
||||
以下是几个比较具有启发的点，我们可以利用 Git hooks 做点什么：
|
||||
|
||||
- 阻止提交到 master。
|
||||
- 在 commit 之前执行 prettier/eslint/jest 检测。
|
||||
- 检测代码规范、合并冲突、检测是否有大文件。
|
||||
- commit 成功后给出提示或记录到日志。
|
||||
|
||||
但 Git hooks 仍然有局限性：
|
||||
|
||||
- 容易被绕过：--no-verifuy --no-merge --no-checkout ---force。
|
||||
- 本地 hooks 无法提交，导致项目开发规则可能不尽相同。
|
||||
- 无法替代 CI、服务端分支保护、Code Review。
|
||||
|
||||
可以畅想一下，在 WebIDE 环境可以通过自定义 git 命令禁止检测绕过，自然解决第二条环境不一致的问题。
|
||||
|
||||
### GraphQL + Typescript
|
||||
|
||||
GraphQL 是没有类型支持的，如果要手动创建一遍类型文件是非常痛苦的：
|
||||
|
||||
```typescript
|
||||
interface GetArticleData {
|
||||
getArticle: {
|
||||
id: number;
|
||||
title: string;
|
||||
};
|
||||
}
|
||||
|
||||
const query = graphql(gql`
|
||||
query getArticle {
|
||||
article {
|
||||
id
|
||||
title
|
||||
}
|
||||
}
|
||||
`);
|
||||
|
||||
apolloClient.query<GetArticleData>(query);
|
||||
```
|
||||
|
||||
同样的代码分散在两处维护一定会带来问题，我们可以利用比如 `typed-graphqlify` 这种库解决类型问题：
|
||||
|
||||
```typescript
|
||||
import { params, types, query } from "typed-graphqlify";
|
||||
|
||||
const getArticleQuery = {
|
||||
article: params({
|
||||
id: types.number,
|
||||
title: types.string
|
||||
})
|
||||
};
|
||||
|
||||
const gqlString = query("getUser", getUserQuery);
|
||||
```
|
||||
|
||||
只要一遍定义就可以自动生成 GQLString，并且拿到 Typescript 类型。
|
||||
|
||||
### React 文档国际化
|
||||
|
||||
即便是谷歌翻译也不是很靠谱，国际化文档还是要靠人肉，[Nat Alison](https://github.com/tesseralis) 利用 Github 充分发动各国人民的力量，共同打造了一个个 reactjs group 下的国际化仓库。
|
||||
|
||||
国际化仓库命名规则是 `reactjs/xx.reactjs.org`，比如简体中文的国际化仓库是：https://github.com/reactjs/zh-hans.reactjs.org
|
||||
|
||||
从仓库的 readme 可以看到维护规则是这样的：
|
||||
|
||||
- 请 fork 这个仓库。
|
||||
- 基于 fork 后的仓库中 master 分支拉取一个新的分支（名字自取）。
|
||||
- 翻译(校对)你所选择的文章，提交到新的分支。
|
||||
- 此时提交 Pull Request 到该仓库。
|
||||
- 会有专人 Review 该 Pull Request，当两人以上通过该 Pull Request 时，你的翻译将被合并到仓库中。
|
||||
- 删除你所创建的分支（如继续参与，参考同步流程）。
|
||||
|
||||
之后定期从 React 官方文档项目拉取最新代码即可保持文档的同步更新。
|
||||
|
||||
### 你需要 redux 吗？
|
||||
|
||||
关于数据流的话题目前没有什么新意，但这次 React Conf 关于数据流总结的算是比较真诚的，总结了以下几个点：
|
||||
|
||||
1. 全局数据流现在不是必须的，比如 Redux，但也不能说完全不能用，至少在全局状态较为复杂时有必要使用。
|
||||
2. 不要只使用一种数据流方案，根据状态的作用域确定方案比较好。
|
||||
3. 工程技术与科学不同，工程世界没有最好的方案，只有更好的方案。
|
||||
4. 就算有了完美方案也不要停止学习的步伐，总会有新知识产生。
|
||||
|
||||
### web 历史
|
||||
|
||||
很精彩的演讲，不过新鲜内容并不多，比较有感触一点是：以前的网页地址对应到的是服务器磁盘的某个具体文件，比如早期 php 应用，现在后端不再是文件化而是服务化了，这层抽象让服务端摆脱了对文件结构的依赖，可以构建更多复杂动态逻辑，也支持了前后端分离的技术方案。
|
||||
|
||||
## 3 总结
|
||||
|
||||
这届 React Conf 让我们看到前端更多的可能性，我们不仅要关注技术实现细节，更要关注行业标准以及团队愿景。
|
||||
|
||||
React 团队的愿景是让 React 包罗万象，提升全球开发者的开发体验、提升全球产品的用户体验，基于这个目标，React Conf 自然不能只包含 DOM Diff、Reconciler 等等技术细节，更需要展示 React 如何帮助全球开发者，如何让这些开发者帮助到用户，如何推动行业标准的演进，如何让 React 打破国界、语言的壁垒。
|
||||
|
||||
相比其他前端大会非常多的干货来说，React Conf 虽然显得主题比较杂，但这正是人文情怀的体现，我相信只有带着更高的使命愿景，真诚帮助他人的技术团队才可以走得更远。
|
||||
|
||||
> 讨论地址是：[精读《React Conf 2019 - Day1》 · Issue #214 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/214)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,458 @@
|
||||
## 1 引言
|
||||
|
||||
取数是前端业务的重要部分，也经历过几次演化：
|
||||
|
||||
- [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) 的兼容性已经足够好，足以替换包括 `$.post` 在内的各种取数封装。
|
||||
- 原生用得久了，发现拓展性更好、支持 ssr 的同构取数方案也挺好，比如 [isomorphic-fetch](https://github.com/matthew-andrews/isomorphic-fetch)、[axios](https://github.com/axios/axios)。
|
||||
- 对于数据驱动场景还是不够，数据流逐渐将取数封装起来，同时针对数据驱动状态变化管理进行了 `data` `isLoading` `error` 封装。
|
||||
- Hooks 的出现让组件更 Reactive，我们发现取数还是优雅回到了组件里，[swr](https://github.com/zeit/swr) 就是一个教科书般的例子。
|
||||
|
||||
[swr](https://github.com/zeit/swr) 在 2019.10.29 号提交，仅仅 12 天就攒了 4000+ star，平均一天收获 300+ star！本周精读就来剖析这个库的功能与源码，了解这个 React Hooks 的取数库的 Why How 与 What。
|
||||
|
||||
## 2 概述
|
||||
|
||||
首先介绍 swr 的功能。
|
||||
|
||||
为了和官方文档有所区别，笔者以探索式思路介绍这个它，但例子都取自官方文档。
|
||||
|
||||
### 2.1 为什么用 Hooks 取数
|
||||
|
||||
首先回答一个根本问题：为什么用 Hooks 替代 fetch 或数据流取数？
|
||||
|
||||
因为 **Hooks 可以触达 UI 生命周期，取数本质上是 UI 展示或交互的一个环节。** 用 Hooks 取数的形式如下：
|
||||
|
||||
```typescript
|
||||
import useSWR from "swr";
|
||||
|
||||
function Profile() {
|
||||
const { data, error } = useSWR("/api/user", fetcher);
|
||||
|
||||
if (error) return <div>failed to load</div>;
|
||||
if (!data) return <div>loading...</div>;
|
||||
return <div>hello {data.name}!</div>;
|
||||
}
|
||||
```
|
||||
|
||||
首先看到的是，以同步写法描述了异步逻辑，这是因为渲染被执行了两次。
|
||||
|
||||
`useSWR` 接收三个参数，第一个参数是取数 `key`，这个 `key` 会作为第二个参数 `fetcher` 的第一个参数传入，普通场景下为 URL，第三个参数是配置项。
|
||||
|
||||
Hooks 的威力还不仅如此，上面短短几行代码还自带如下特性：
|
||||
|
||||
1. 可自动刷新。
|
||||
2. 组件被销毁再渲染时优先启用本地缓存。
|
||||
3. 在列表页中浏览器回退可以自动记忆滚动条位置。
|
||||
4. tabs 切换时，被 focus 的 tab 会重新取数。
|
||||
|
||||
当然，自动刷新或重新取数也不一定是我们想要的，[swr](https://github.com/zeit/swr) 允许自定义配置。
|
||||
|
||||
### 2.2 配置
|
||||
|
||||
上面提到，`useSWR` 还有第三个参数作为配置项。
|
||||
|
||||
**独立配置**
|
||||
|
||||
通过第三个参数为每个 `useSWR` 独立配置：
|
||||
|
||||
```tsx
|
||||
useSWR("/api/user", fetcher, { revalidateOnFocus: false });
|
||||
```
|
||||
|
||||
配置项可以参考 [文档](https://github.com/zeit/swr#options)。
|
||||
|
||||
> 可以配置的有：suspense 模式、focus 重新取数、重新取数间隔/是否开启、失败是否重新取数、timeout、取数成功/失败/重试时的回调函数等等。
|
||||
|
||||
> 第二个参数如果是 object 类型，则效果为配置项，第二个 fetcher 只是为了方便才提供的，在 object 配置项里也可以配置 fetcher。
|
||||
|
||||
**全局配置**
|
||||
|
||||
`SWRConfig` 可以批量修改配置：
|
||||
|
||||
```tsx
|
||||
import useSWR, { SWRConfig } from "swr";
|
||||
|
||||
function Dashboard() {
|
||||
const { data: events } = useSWR("/api/events");
|
||||
// ...
|
||||
}
|
||||
|
||||
function App() {
|
||||
return (
|
||||
<SWRConfig value={{ refreshInterval: 3000 }}>
|
||||
<Dashboard />
|
||||
</SWRConfig>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
独立配置优先级高于全局配置，在精读部分会介绍实现方式。
|
||||
|
||||
最重量级的配置项是 `fetcher`，它决定了取数方式。
|
||||
|
||||
### 2.3 自定义取数方式
|
||||
|
||||
自定义取数逻辑其实分几种抽象粒度，比如自定义取数 url，或自定义整个取数函数，而 [swr](https://github.com/zeit/swr) 采取了相对中间粒度的自定义 `fetcher`：
|
||||
|
||||
```tsx
|
||||
import fetch from "unfetch";
|
||||
|
||||
const fetcher = url => fetch(url).then(r => r.json());
|
||||
|
||||
function App() {
|
||||
const { data } = useSWR("/api/data", fetcher);
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
所以 `fetcher` 本身就是一个拓展点，我们不仅能自定义取数函数，自定义业务处理逻辑，甚至可以自定义取数协议：
|
||||
|
||||
```tsx
|
||||
import { request } from "graphql-request";
|
||||
|
||||
const API = "https://api.graph.cool/simple/v1/movies";
|
||||
const fetcher = query => request(API, query);
|
||||
|
||||
function App() {
|
||||
const { data, error } = useSWR(
|
||||
`{
|
||||
Movie(title: "Inception") {
|
||||
releaseDate
|
||||
actors {
|
||||
name
|
||||
}
|
||||
}
|
||||
}`,
|
||||
fetcher
|
||||
);
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
这里回应了第一个参数称为取数 Key 的原因，在 graphql 下它则是一段语法描述。
|
||||
|
||||
到这里，我们可以自定义取数函数，但却无法控制何时取数，因为 Hooks 写法使取数时机与渲染时机结合在一起。[swr](https://github.com/zeit/swr) 的条件取数机制可以解决这个问题。
|
||||
|
||||
### 2.4 条件取数
|
||||
|
||||
所谓条件取数，即 `useSWR` 第一个参数为 null 时则会终止取数，我们可以用三元运算符或函数作为第一个参数，使这个条件动态化：
|
||||
|
||||
```tsx
|
||||
// conditionally fetch
|
||||
const { data } = useSWR(shouldFetch ? "/api/data" : null, fetcher);
|
||||
|
||||
// ...or return a falsy value
|
||||
const { data } = useSWR(() => (shouldFetch ? "/api/data" : null), fetcher);
|
||||
```
|
||||
|
||||
上例中，当 `shouldFetch` 为 false 时则不会取数。
|
||||
|
||||
第一个取数参数推荐为回调函数，这样 [swr](https://github.com/zeit/swr) 会 catch 住内部异常，比如：
|
||||
|
||||
```tsx
|
||||
// ... or throw an error when user.id is not defined
|
||||
const { data, error } = useSWR(() => "/api/data?uid=" + user.id, fetcher);
|
||||
```
|
||||
|
||||
如果 `user` 对象不存在，`user.id` 的调用会失败，此时错误会被 catch 住并抛到 `error` 对象。
|
||||
|
||||
实际上，`user.id` 还是一种依赖取数场景，当 `user.id` 发生变化时需要重新取数。
|
||||
|
||||
### 2.5 依赖取数
|
||||
|
||||
如果一个取数依赖另一个取数的结果，那么当第一个数据结束时才会触发新的取数，这在 [swr](https://github.com/zeit/swr) 中不需要特别关心，只需按照依赖顺序书写 `useSWR` 即可：
|
||||
|
||||
```tsx
|
||||
function MyProjects() {
|
||||
const { data: user } = useSWR("/api/user");
|
||||
const { data: projects } = useSWR(() => "/api/projects?uid=" + user.id);
|
||||
|
||||
if (!projects) return "loading...";
|
||||
return "You have " + projects.length + " projects";
|
||||
}
|
||||
```
|
||||
|
||||
[swr](https://github.com/zeit/swr) 会尽可能并行没有依赖的请求，并按依赖顺序一次发送有依赖关系的取数。
|
||||
|
||||
可以想象，如果手动管理取数，当依赖关系复杂时，为了确保取数的最大可并行，往往需要精心调整取数递归嵌套结构，而在 [swr](https://github.com/zeit/swr) 的环境下只需顺序书写即可，这是很大的效率提升。优化方式在下面源码解读章节详细说明。
|
||||
|
||||
依赖取数是自动重新触发取数的一种场景，其实 [swr](https://github.com/zeit/swr) 还支持手动触发重新取数。
|
||||
|
||||
### 2.6 手动触发取数
|
||||
|
||||
`trigger` 可以通过 Key 手动触发取数：
|
||||
|
||||
```tsx
|
||||
import useSWR, { trigger } from "swr";
|
||||
|
||||
function App() {
|
||||
return (
|
||||
<div>
|
||||
<Profile />
|
||||
<button
|
||||
onClick={() => {
|
||||
// set the cookie as expired
|
||||
document.cookie =
|
||||
"token=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;";
|
||||
|
||||
// tell all SWRs with this key to revalidate
|
||||
trigger("/api/user");
|
||||
}}
|
||||
>
|
||||
Logout
|
||||
</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
大部分场景不必如此，**因为请求的重新触发由数据和依赖决定，但遇到取数的必要性不由取数参数决定，而是时机时，就需要用手动取数能力了。**
|
||||
|
||||
### 2.7 乐观取数
|
||||
|
||||
特别在表单场景时，数据的改动是可预期的，此时数据驱动方案只能等待后端返回结果，其实可以优化为本地先修改数据，等后端结果返回后再刷新一次：
|
||||
|
||||
```tsx
|
||||
import useSWR, { mutate } from "swr";
|
||||
|
||||
function Profile() {
|
||||
const { data } = useSWR("/api/user", fetcher);
|
||||
|
||||
return (
|
||||
<div>
|
||||
<h1>My name is {data.name}.</h1>
|
||||
<button
|
||||
onClick={async () => {
|
||||
const newName = data.name.toUpperCase();
|
||||
// send a request to the API to update the data
|
||||
await requestUpdateUsername(newName);
|
||||
// update the local data immediately and revalidate (refetch)
|
||||
mutate("/api/user", { ...data, name: newName });
|
||||
}}
|
||||
>
|
||||
Uppercase my name!
|
||||
</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
通过 `mutate` 可以在本地临时修改某个 Key 下返回结果，特别在网络环境差的情况下加快响应速度。乐观取数，表示对取数结果是乐观的、可预期的，所以才能在结果返回之前就预测并修改了结果。
|
||||
|
||||
### 2.8 Suspense 模式
|
||||
|
||||
在 React Suspense 模式下，所有子模块都可以被懒加载，包括代码和请求都可以被等待，只要开启 `suspense` 属性即可：
|
||||
|
||||
```tsx
|
||||
import { Suspense } from "react";
|
||||
import useSWR from "swr";
|
||||
|
||||
function Profile() {
|
||||
const { data } = useSWR("/api/user", fetcher, { suspense: true });
|
||||
return <div>hello, {data.name}</div>;
|
||||
}
|
||||
|
||||
function App() {
|
||||
return (
|
||||
<Suspense fallback={<div>loading...</div>}>
|
||||
<Profile />
|
||||
</Suspense>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
### 2.9 错误处理
|
||||
|
||||
`onErrorRetry` 可以统一处理错误，包括在错误发生后重新取数等：
|
||||
|
||||
```tsx
|
||||
useSWR(key, fetcher, {
|
||||
onErrorRetry: (error, key, option, revalidate, { retryCount }) => {
|
||||
if (retryCount >= 10) return;
|
||||
if (error.status === 404) return;
|
||||
|
||||
// retry after 5 seconds
|
||||
setTimeout(() => revalidate({ retryCount: retryCount + 1 }), 5000);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## 3 精读
|
||||
|
||||
### 3.1 全局配置
|
||||
|
||||
在 Hooks 场景下，包装一层自定义 `Context` 即可实现全局配置。
|
||||
|
||||
首先 `SWRConfig` 本质是一个定制 `Context Provider`:
|
||||
|
||||
```tsx
|
||||
const SWRConfig = SWRConfigContext.Provider;
|
||||
```
|
||||
|
||||
在 `useSWR` 中将当前配置与全局配置 Merge 即可，通过 `useContext` 拿到全局配置：
|
||||
|
||||
```tsx
|
||||
config = Object.assign({}, defaultConfig, useContext(SWRConfigContext), config);
|
||||
```
|
||||
|
||||
### 3.2 useSWR 的一些细节
|
||||
|
||||
从源码可以看到更多细节用心，`useSWR` 真的比手动调用 `fetch` 好很多。
|
||||
|
||||
**兼容性**
|
||||
|
||||
`useSWR` 主体代码在 `useEffect` 中，但是为了将请求时机提前，放在了 UI 渲染前（`useLayoutEffect`），并兼容了服务端场景：
|
||||
|
||||
```tsx
|
||||
const useIsomorphicLayoutEffect = IS_SERVER ? useEffect : useLayoutEffect;
|
||||
```
|
||||
|
||||
**非阻塞**
|
||||
|
||||
请求时机在浏览器空闲时，因此请求函数被 `requestIdleCallback` 包裹：
|
||||
|
||||
```tsx
|
||||
window["requestIdleCallback"](softRevalidate);
|
||||
```
|
||||
|
||||
`softRevalidate` 是开启了去重的 `revalidate`:
|
||||
|
||||
```tsx
|
||||
const softRevalidate = () => revalidate({ dedupe: true });
|
||||
```
|
||||
|
||||
即默认 2s 内参数相同的重复取数会被取消。
|
||||
|
||||
**性能优化**
|
||||
|
||||
由于 [swr](https://github.com/zeit/swr) 的 `data`、`isValidating` 等数据状态是利用 `useState` 分开管理的：
|
||||
|
||||
```tsx
|
||||
let [data, setData] = useState(
|
||||
(shouldReadCache ? cacheGet(key) : undefined) || config.initialData
|
||||
);
|
||||
// ...
|
||||
let [isValidating, setIsValidating] = useState(false);
|
||||
```
|
||||
|
||||
而取数状态变化时往往 `data` 与 `isValidating` 要一起更新，为了仅触发一次更新，使用了 `unstable_batchedUpdates` 将更新合并为一次：
|
||||
|
||||
```tsx
|
||||
unstable_batchedUpdates(() => {
|
||||
setIsValidating(false);
|
||||
// ...
|
||||
setData(newData);
|
||||
});
|
||||
```
|
||||
|
||||
其实还有别的解法，比如使用 `useReducer` 管理数据也能达到相同性能效果。
|
||||
|
||||
### 3.3 初始缓存
|
||||
|
||||
当页面切换时，可以暂时以上一次数据替换取数结果，即初始化数据从缓存中拿：
|
||||
|
||||
```tsx
|
||||
const shouldReadCache = config.suspense || !useHydration();
|
||||
|
||||
// stale: get from cache
|
||||
let [data, setData] = useState(
|
||||
(shouldReadCache ? cacheGet(key) : undefined) || config.initialData
|
||||
);
|
||||
```
|
||||
|
||||
上面一段代码在 `useSWR` 的初始化期间，`useHydration` 表示是否为初次加载：
|
||||
|
||||
```tsx
|
||||
let isHydration = true;
|
||||
|
||||
export default function useHydration(): boolean {
|
||||
useEffect(() => {
|
||||
setTimeout(() => {
|
||||
isHydration = false;
|
||||
}, 1);
|
||||
}, []);
|
||||
|
||||
return isHydration;
|
||||
}
|
||||
```
|
||||
|
||||
### 3.4 支持 suspense
|
||||
|
||||
Suspense 分为两块功能：异步加载代码与异步加载数据，现在提到的是异步加载数据相关的能力。
|
||||
|
||||
Suspense 要求代码 suspended，即抛出一个可以被捕获的 Promise 异常，在这个 Promise 结束后再渲染组件。
|
||||
|
||||
核心代码就这一段，抛出取数的 Promise：
|
||||
|
||||
```tsx
|
||||
throw CONCURRENT_PROMISES[key];
|
||||
```
|
||||
|
||||
等取数完毕后再返回 `useSWR` API 定义的结构：
|
||||
|
||||
```tsx
|
||||
return {
|
||||
error: latestError,
|
||||
data: latestData,
|
||||
revalidate,
|
||||
isValidating
|
||||
};
|
||||
```
|
||||
|
||||
如果没有上面 `throw` 的一步，在取数完毕前组件就会被渲染出来，所以 `throw` 了请求的 Promise 使得这个请求函数支持了 Suspense。
|
||||
|
||||
### 3.5 依赖的请求
|
||||
|
||||
翻了一下代码，没有找到对循环依赖特别处理的逻辑，**后来看了官方文档才恍然大悟，原来是通过 `try/catch` + `onErrorRetry` 机制实现依赖取数的。**
|
||||
|
||||
看下面这段代码：
|
||||
|
||||
```tsx
|
||||
const { data: user } = useSWR("/api/user");
|
||||
const { data: projects } = useSWR(() => "/api/projects?uid=" + user.id);
|
||||
```
|
||||
|
||||
怎么做到智能按依赖顺序请求呢？我们看 `useSWR` 取数函数的主体逻辑：
|
||||
|
||||
```tsx
|
||||
try {
|
||||
// 设置 isValidation 为 true
|
||||
// 取数、onSuccess 回调
|
||||
// 设置 isValidation 为 false
|
||||
// 设置缓存
|
||||
// unstable_batchedUpdates
|
||||
} catch (err) {
|
||||
// 撤销取数、缓存等对象
|
||||
// 调用 onErrorRetry
|
||||
}
|
||||
```
|
||||
|
||||
可见取数逻辑被 `try` 住了，那么 `user.id` 在 `useSWR("/api/user")` 没有 Ready 的情况一定会抛出异常，则自动进入 `onErrorRetry` 逻辑，看看下次取数时 `user.id` 有没有 Ready。
|
||||
|
||||
那么什么时候才轮到下次取数呢？这个时机是：
|
||||
|
||||
```tsx
|
||||
const count = Math.min(opts.retryCount || 0, 8);
|
||||
const timeout =
|
||||
~~((Math.random() + 0.5) * (1 << count)) * config.errorRetryInterval;
|
||||
```
|
||||
|
||||
重试时间基本按 2 的指数速度增长。
|
||||
|
||||
所以 [swr](https://github.com/zeit/swr) 会优先按照并行方式取数，存在依赖的取数会重试，直到上游 Ready。这种简单的模式稍稍损失了一些性能（没有在上游 Ready 后及时重试下游），但不失为一种巧妙的解法，而且最大化并行也使得大部分场景性能反而比手写的好。
|
||||
|
||||
## 4 总结
|
||||
|
||||
笔者给仔细阅读本文的同学留下两道思考题：
|
||||
|
||||
- 关于 Hooks 取数还是在数据流中取数，你怎么看呢？
|
||||
- swr 解决依赖取数的方法还有更好的改进办法吗？
|
||||
|
||||
> 讨论地址是：[精读《Hooks 取数 - swr 源码》 · Issue #216 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/216)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
@@ -0,0 +1,630 @@
|
||||
## 1 引言
|
||||
|
||||
这是继 [精读《React Conf 2019 - Day1》](https://github.com/dt-fe/weekly/blob/v2/127.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Conf%202019%20-%20Day1%E3%80%8B.md) 之后的第二篇，补充了 React Conf 2019 第二天的内容。
|
||||
|
||||
## 2 概述 & 精读
|
||||
|
||||
第二天的内容更为精彩，笔者会重点介绍比较干货的部分。
|
||||
|
||||
### Fast refresh
|
||||
|
||||
[Fast refresh](https://facebook.github.io/react-native/docs/fast-refresh) 是更好的 react-hot-loader 替代方案，目前仅支持 react-native 平台，很快就会支持 react-dom 平台。
|
||||
|
||||
相比不支持 Function component、无法错误恢复、更新经常失灵的 hot reloading 来说，fast refresh 还拥有以下几个优点：
|
||||
|
||||
- 状态保持。
|
||||
- 支持 Function Component Hooks。
|
||||
- 更快的更新速度。
|
||||
|
||||
Fast refresh 更新速度更快，是基于 Function Component 生成了 “签名”，从而最大成都避免销毁重渲染，尽可能保持对组件的 rerender 刷新。下面介绍签名机制的工作原理。
|
||||
|
||||
Fast refresh 对每个 Function component 都生成了一份专属签名，用以描述这个组件核心状态，当这个核心状态改变时，就只能销毁重渲染了，但对于不触及核心的修改就能进行代价非常小的 rerender。
|
||||
|
||||
这个签名包含了 hooks 和参数名：
|
||||
|
||||
```js
|
||||
// signature: "useState{isLoggedIn}"
|
||||
|
||||
function ExampleComponent() {
|
||||
const [isLoggedIn, setIsLoggedIn] = useState(true);
|
||||
}
|
||||
```
|
||||
|
||||
比如当参数名变更时，这个组件的逻辑已发生改动，此时只能销毁并重渲染了。因此实际上通过对签名的对比来判断是否要销毁并重刷新组件：
|
||||
|
||||
```js
|
||||
// signature: "useState{isLoggedOut}"
|
||||
|
||||
function ExampleComponent() {
|
||||
const [isLoggedOut, setIsLoggedOut] = useState(true);
|
||||
}
|
||||
```
|
||||
|
||||
同理，当 hooks 从 `useState` 改成了 `useReducer`，签名也会发生变化从而导致彻底的重渲染。
|
||||
|
||||
但除此之外，**比如对样式的修改、Dom 结构的修改都不会触发签名的变化**，从而保证了 “对不触及逻辑的改动进行高效的轻量 renreder”。
|
||||
|
||||
然而 Fast refresh 也有如下局限性：
|
||||
|
||||
- 还不能友好支持 Class component。
|
||||
- 混合导出 React 和非 React 组件时无法精确的 hot reload。
|
||||
- 更高的内存要求。
|
||||
|
||||
可以看到，Fast Refresh 随着功能推广与内置，现在已经覆盖了 Facebook 95% 以上 hot reload 场景了：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1bjm1mYr1gK0jSZR0XXbP8XXa-1598-1018.png">
|
||||
|
||||
这部分内容不仅揭开了 hot reload 技术内幕，还对其功能进行了进一步优化，2019 年的 React 开发体系已经进入精细化阶段。
|
||||
|
||||
### 重写 React devtools
|
||||
|
||||
React devtools 的更新终于被正式介绍了，本来笔者以为新的 devtools 只是支持了 hooks，但听完分享后发现还有更多有用的改进，包括：
|
||||
|
||||
- 更高的性能。
|
||||
- 更多特性支持。
|
||||
- 更好用户体验。
|
||||
|
||||
**找到节点渲染链路**
|
||||
|
||||
并不是每个 React 节点都参与渲染，新版 React devtools 可以展示出 rendered by：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1OSWomV67gK0jSZPfXXahhFXa-2354-668.png">
|
||||
|
||||
**调试 Suspense**
|
||||
|
||||
在 Day1 中讲到的 Suspense 特性可以在 React devtools 调试了：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1W790m4D1gK0jSZFsXXbldVXa-1816-660.png">
|
||||
|
||||
通过点击时钟 icon，可以模拟 Suspense 处于 pendding 或 ready 状态。
|
||||
|
||||
**增强调试能力**
|
||||
|
||||
可以通过点击直接跳转到组件源码：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1IBK1m4n1gK0jSZKPXXXvUXXa-1806-772.png">
|
||||
|
||||
最新版已增强至点击按钮后直接通过 Source 打开源码位置，**这样可以快速通过 UI 寻找到代码**。同时还可以看到，通过点击 debugger 按钮将当前组件信息打到控制台调试。
|
||||
|
||||
除此之外还可以动态修改组件的 props 与 hook state，大大增强了调试能力。
|
||||
|
||||
**profiler**
|
||||
|
||||
分析工具也得到了增强，现在可以看到每个组件被渲染了几次以及重新渲染的原因：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1cla1m7P2gK0jSZPxXXacQpXa-1824-690.png">
|
||||
|
||||
比如上图组件被渲染了 4 次，主要有两个原因：Hooks 改变与 Props 改变。
|
||||
|
||||
除此之外，还优化了更多细节体验，比如高亮搜索、HOC 的展示优化、嵌套层级过多时不会占用过多的横向宽度等等。
|
||||
|
||||
### react codemod
|
||||
|
||||
codemod 是一个代码重构的方式，通过 AST 方式精准触达代码，我们可以认为 codemod 是一个更聪明的“查找/替换”。
|
||||
|
||||
codemod 主要有以下三种使用方式：
|
||||
|
||||
- 重命名。
|
||||
- 代码排序。
|
||||
- 一定程度的代码替换。
|
||||
|
||||
接下来就讲到 [react codemod](https://github.com/reactjs/react-codemod) 了，它是 react 场景的 codemod 解决方案，facebook 是这么使用 react codemod 的：
|
||||
|
||||
- 迁移 facebook 代码。
|
||||
- 涉及几万个组件。
|
||||
- 修复了 3500 个文件的 React.PropTypes。
|
||||
- 修复了 8500 个文件的生命周期 unsafe。
|
||||
- 修复了 20000 个文件的 createClass 转 JSX。
|
||||
|
||||
使用方式：
|
||||
|
||||
```bash
|
||||
npx react-codemod React-PropTypes-to-prop-types
|
||||
```
|
||||
|
||||
可以看到，通过 cli 对文件进行一次性重构处理。除此之外，再列举几种使用场景：
|
||||
|
||||
- create-element-to-jsx 将 `React.createElement` 转换为 JSX。
|
||||
- error-boundaries 将 `unstable_handleError` 改为 `componentDidCatch`。
|
||||
- findDOMNode 将 `React.createClass` 中 `this.getDOMNode()` 改为 `React.findDOMNode`。
|
||||
- sort-comp 将 Class Component 生命周期按照规范排序，[eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/sort-comp.md) 插件也有相同能力。
|
||||
|
||||
理论上来讲，所有 codemode 做的事情都可以替换为 eslint 的 autofix 来完成，比如 sort-comp 就同时被 codemode 和 eslint 支持。
|
||||
|
||||
### Suspense
|
||||
|
||||
要理解 Suspense，就要理解 Suspense 与普通 loading 有什么区别。
|
||||
|
||||
从代码角度来说，Suspense 可以类比为 `try/catch` 的体验。为了简化代码复杂度，我们可以用 `try/catch` 包裹代码，从而简化 try 区块代码复杂度，并将兜底代码放在 catch 区块：
|
||||
|
||||
```js
|
||||
try {
|
||||
// 只要考虑正确情况
|
||||
} catch {
|
||||
// 错误时 fallback
|
||||
}
|
||||
```
|
||||
|
||||
Suspense 也一样，它在渲染 React 组件时如果遇到了 Promise 抛出的 Error，就会进入 `fallback`，所以 `fallback` 含义是 Loading 中状态：
|
||||
|
||||
```jsx
|
||||
<Suspense fallback={<Spinner />}>
|
||||
<ProfilePage />
|
||||
</Suspense>
|
||||
```
|
||||
|
||||
与此同时，实际业务组件中的取数也不需要担心取数是否正在进行中，只要直接处理拿到数据的情况就好了：
|
||||
|
||||
```jsx
|
||||
function ProfileDetails() {
|
||||
// 直接使用 user，不用担心失败。
|
||||
const user = resource.user.read();
|
||||
return <h1>{user.name}</h1>;
|
||||
}
|
||||
```
|
||||
|
||||
进一步的，如果要处理组件渲染的异常，再使用 `ErrorBoundary` 包裹即可，此时的 `fallback` 含义是组件加载异常的错误状态：
|
||||
|
||||
```jsx
|
||||
function Home(props) {
|
||||
return (
|
||||
<ErrorBoundary fallback={<ErrorMessage />}>
|
||||
<Suspense fallback={<Placeholder />}>
|
||||
<Composer />
|
||||
</Suspense>
|
||||
</ErrorBoundary>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Suspense 模式的取数好处是 “fetch on render”，即渲染与取数同时进行，而普通模式的取数是 “fetch after render”，即渲染完成后再通过 `useEffect` 取数，此时取数时机已晚。
|
||||
|
||||
**队列加载**
|
||||
|
||||
假设 `Composer` 与 `NewsFeed` 组件内部都通过 `useQuery` 取数，那么并行取数时加载机制如下：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1AonZm7L0gK0jSZFtXXXQCXXa-1770-778.png">
|
||||
|
||||
这可能有两个问题：组件内部加载顺序不统一与组件间加载顺序不统一。
|
||||
|
||||
如果组件内部有图片，可能图片与组件渲染实际不一致，此时可以利用 Suspense 统一 hold 所有子组件的特性，将图片加载改为 Suspense 模式：
|
||||
|
||||
```jsx
|
||||
<div>
|
||||
<YourImage src={uri} alt={...} />
|
||||
<MoreComposer />
|
||||
</div>
|
||||
```
|
||||
|
||||
同一个 Suspense 可以等待所有子元素都 Ready 后才会一把渲染出 UI，因此可以看到网页被一次性刷新而不是分部刷新。
|
||||
|
||||
第二个问题是组件间加载顺序不统一，可能导致先渲染了文章内容，再渲染出文章头部，此时如果区块高度不固定，文章头部可能会撑开，导致文章内容下移，用户的阅读体验会遭到打断。可以通过 `suspense ordering` 解决这个问题：
|
||||
|
||||
```jsx
|
||||
function Home(props) {
|
||||
return (
|
||||
<SuspenseList revealOrder="forwards">
|
||||
<Suspense fallback={<ComposerFallback />}>
|
||||
<Composer />
|
||||
</Suspense>
|
||||
<Suspense fallback={<FeedFallback />}>
|
||||
<NewsFeed />
|
||||
</Suspense>
|
||||
</SuspenseList>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
比如 `forwards` 表示从上到下，那么一定会先渲染头部再渲染文章内容，这样文章内容就不会都抖动了。
|
||||
|
||||
### Render as you fetch
|
||||
|
||||
相比 “fetch on render”，更高级别的优化是 “Render as you fetch”，即取数在渲染时机之前。
|
||||
|
||||
比如页面路由的跳转、Hover 到一个区块，此时如果取数由这个动作触发，就可以再次将取数时机提前，Facebook 为此创造了一个新的 Hook：`usePreloadedQuery`。
|
||||
|
||||
用法是，在某个事件中取数，比如点击页面跳转按钮时，通过 `preloadQuery` 预取数，得到的结果并不是取数结果，而是一个标识，在渲染组件中，把这个标识传给 `usePreloadedQuery` 可以拿到真实取数结果：
|
||||
|
||||
```js
|
||||
// 组件 A 的 onClick
|
||||
const reference = preloadQuery(query, variables);
|
||||
// 组件 B 的 render
|
||||
const data = usePreloadedQuery(query, reference);
|
||||
```
|
||||
|
||||
可以看到，取数真正触发的时机在渲染函数执行之前，所以在 `usePreloadedQuery` 调用时取数肯定已经在路上，甚至已经完成。相比之下，普通的 `useQuery` 函数存在下面几个问题：
|
||||
|
||||
- 由于取数过程存在状态变化，可能导致组件在 “取数无意义” 状态下重新渲染多次。
|
||||
- 可能取数还未完成就触发重渲染。
|
||||
- 没有取消的机制，没有清除结果的机制。
|
||||
- 没有办法唯一标识组件。
|
||||
|
||||
preloadQuery 的好处就是将取数时机与 UI 分离，这样可以更细粒度的控制逻辑：
|
||||
|
||||
- 调用 preloadQuery 时：
|
||||
- 在组件销毁时取消取数。
|
||||
- 有新取数触发时取消取数。
|
||||
- 销毁一些轮询机制。
|
||||
- 渲染组件调用 usePreloadedQuery 时：
|
||||
- 不会再触发取数，不会触发意外的 re-render。
|
||||
- 不需要清空，因为取数不在这里发起。
|
||||
- 不需要清理轮询。
|
||||
|
||||
可见 preloadQuery 相比 useQuery 的确有了一些体验提升，然而这个优化比较追求极致，对大部分国内项目来说可能还走不到 facebook 这么极致的性能优化，所以投入产出比显得不是那么高，而且这个开发方式对开发者不是太友好，因为它让请求的时机割裂到两个模块中。
|
||||
|
||||
但毕竟用户体验是大于开发者体验的，React 尽量通过提高开发者体验来间接提高用户体验，使双方都满意，但像 preloadQuery 就无法两者兼顾了，为了用户体验可以适当的降低一些开发者体验。
|
||||
|
||||
### 如何维护代码
|
||||
|
||||
这个分享讲述了如何提升代码维护效率，毕竟一个月后可能连自己写的代码都看不懂了。[hydrosquall](http://github.com/hydrosquall) 通过类比地图的方式解释了程序员是如何维护代码的。
|
||||
|
||||
首先看我们是如何认路的。认路分为三个层次：
|
||||
|
||||
- 随意走走。
|
||||
- 通过一些地标判断方向。
|
||||
- 有方向的寻路。
|
||||
- 通过跟随同伴或者了解更多本地信息找到目的地。
|
||||
- 地图。
|
||||
- 通过 GPS 定位。
|
||||
- 通过模拟地图方式指出路线。
|
||||
|
||||
可以看到这三种方式是逐层递进的，那么类比到代码就有意思了：
|
||||
|
||||
- 随意走走（滚动查看源代码 + ctrl/f 查找代码 + grep 搜索）。
|
||||
- 入口（找到入口节点，查看数据结构）。
|
||||
- 标记（查看代码注释、查看 README）。
|
||||
- 发信号弹（断点、console.log 等调试行为）
|
||||
- 找到方向。
|
||||
- git blame 查看 owner，或直接根据文档找到 codeowners。
|
||||
- 地图。
|
||||
- 幸运的话你可以找到一份架构流程图。
|
||||
|
||||
可以看到，地图有几种抽象层次，比如忽略了细节的纽约地铁线路图：
|
||||
|
||||
<img width=400 src="https://img.alicdn.com/tfs/TB14k7pmYr1gK0jSZR0XXbP8XXa-1014-702.png">
|
||||
|
||||
或者是包含丰富地面信息的地铁线路图：
|
||||
|
||||
<img width=400 src="https://img.alicdn.com/tfs/TB1Sbwpm.T1gK0jSZFrXXcNCXXa-692-750.png">
|
||||
|
||||
抽象到什么层次取决于用户使用的场景，那么代码抽象也是如此。[hydrosquall](http://github.com/hydrosquall) 做了一个工具自动分析出代码调用关系：[js-callgraph](https://github.com/persper/js-callgraph)
|
||||
|
||||
|
||||
|
||||
这就像路牌一样，可以更高效的看出代码结构，也包括了数据流结构，由于篇幅限制，感兴趣的同学可以看 [原视频](https://youtu.be/JDDxR1a15Yo?t=6579) 了解更多。
|
||||
|
||||
### 写作与写代码
|
||||
|
||||
本章讲了写作（小说）与写代码的关联，总结出如下几个重点：
|
||||
|
||||
- 写小说和写代码都是创造行为。
|
||||
- 写代码需要抽象思维，写小说也要有抽象思维构造人物和情节。
|
||||
- Show, don't tell，写作天然就是申明式的，和数据驱动很相似。
|
||||
|
||||
更多可以去看 [原视频](https://youtu.be/JDDxR1a15Yo?t=9135)。
|
||||
|
||||
### 移动端动画最佳实践
|
||||
|
||||
首先要使用一个真实的手机设备调试，否则可能出现 PC Chrome 一切正常，而手机上实际效果性能很差的情况！
|
||||
|
||||
**手势下拉退出**
|
||||
|
||||
利用 [react-spring](https://github.com/react-spring/react-spring) 和 [react-use-gesture](react-use-gesture) 做一个下滑消失的 Demo：
|
||||
|
||||
```jsx
|
||||
import { animated, useSpring } from "react-spring";
|
||||
import { useDrag } from "react-use-gesture";
|
||||
|
||||
const [{ y }, set] = useSpring(() => {
|
||||
y: 0;
|
||||
});
|
||||
```
|
||||
|
||||
首先定义一个 `y` 纵向位置，通过 `useDrag` 将拖拽操作与 UI 绑定，通过回调将其与 `y` 数据绑定：
|
||||
|
||||
```js
|
||||
const bind = useDrag(({ last, movement: [, movementY], memo = y.value }) => {
|
||||
if (last) {
|
||||
// 拖拽结束时，如果偏移量超过 50 则效果和结束一样，直接将 y 设置为 100
|
||||
const notificationClosed = movementY > 50;
|
||||
|
||||
return set({
|
||||
y: notificationClosed ? 100 : 0,
|
||||
onReset: notificationClosed && removeNotification
|
||||
});
|
||||
}
|
||||
|
||||
// y 的位置区间在 0～100
|
||||
set([{ y: clamp(0, 100, memo + movementY) }]);
|
||||
|
||||
return memo;
|
||||
});
|
||||
```
|
||||
|
||||
将 `useDrag` 与 `y` 绑定后，就可以用在 UI 组件上了：
|
||||
|
||||
```jsx
|
||||
<StyledNotification
|
||||
as={animated.div}
|
||||
onTouchStart={bind().onTouchStart}
|
||||
style={{
|
||||
opacity: y.interpolate([0, 100], [1, 0]),
|
||||
transform: y.interpolate(y => `translateY(${y}px)`)
|
||||
}}
|
||||
/>
|
||||
```
|
||||
|
||||
将 `opacity` 与 `transform` 与位置 `y` 绑定就可以做出下拉消失的效果。
|
||||
|
||||
**滑动的洞见**
|
||||
|
||||
接着讲到了滑动的三个洞见：
|
||||
|
||||
1. 要立刻响应，任何延迟都会造成用户额外精神负担。
|
||||
2. 滚动速度衰减可以提升用户体验:
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1HocDm1H2gK0jSZJnXXaT1FXa-1348-878.gif">
|
||||
|
||||
接着我们需要预测用户的意图，比如在一个类似微信消息列表页左右滑动时：
|
||||
|
||||
- 是否想取消手势交互？
|
||||
- 是否想展示出更多交互按钮？
|
||||
- 是否想删除所有内容？
|
||||
|
||||
这需要更多设计思考。
|
||||
|
||||
1. 橡皮筋滚动，即列表页可以一直向下拉，上面部分像橡皮筋一样可以被拉出空白页的效果。
|
||||
|
||||
在设计手势动画时要考虑三个要点：
|
||||
|
||||
- 使用移动增量作为手势动画的基准点。
|
||||
- 动画和手势应该随时可以被中断，通过 springs 即可实现。
|
||||
- 完成手势后的动画速度应该与手势速度相当，这样视觉体验更自然。
|
||||
|
||||
最后提到了动画兼容性与性能，比如尽量只使用 `transform` 与 `opacity` 可以保证移动端的流畅度，不同移动设备的默认手势效果不同，最好通过 `touch-action` 禁用默认行为以达到更好的兼容性与效果。
|
||||
|
||||
### 唱片与 React
|
||||
|
||||
J.Dash 拥有十年软件开发经验，同时也卖过很多唱片，他介绍了唱片行业与软件开发的共同点。
|
||||
|
||||
唱片行业需要音乐编排能力，这与编码能力类似，都存在良好的设计模式，并且需要团队合作，开发过程中会遇到一些痛苦的经历，但最终完成音乐和项目时都会获得满足的喜悦。
|
||||
|
||||
### 函数式编程
|
||||
|
||||
> Declaratives UIs are the future, and the future is Comonadic. - Phil Freeman
|
||||
|
||||
申明式 UI 是未来，未来则是 Comonadic。
|
||||
|
||||
所谓申明式 UI 可以用下面的公式表达：
|
||||
|
||||
```js
|
||||
type render = (state: State) => View;
|
||||
```
|
||||
|
||||
然后用一段公式介绍了 Comonadic：
|
||||
|
||||
```js
|
||||
class Functor w => Comonad w where
|
||||
extract :: w a -> a
|
||||
duplicate :: w a -> w (w a)
|
||||
extend :: (w a -> a) -> w a -> w b
|
||||
```
|
||||
|
||||
用 JS 版本做一个解释：
|
||||
|
||||
```js
|
||||
const Store = ({ state, render }) => ({
|
||||
extend: f => Store({ state, render: state => f(Store({ state, render })) }),
|
||||
extract: () => render(state)
|
||||
});
|
||||
```
|
||||
|
||||
`extract` 调用后会进行申明式渲染 UI，即 `render(state)`。
|
||||
|
||||
`extend` 表示拓展，接收一个拓展函数作为参数，返回一个新的 Store 对象。这个拓展函数可以拿到 `state`、`render` 并返回新的 `state` 作为 `extract` 时 `render` 的输入。使用例子是这样的：
|
||||
|
||||
```jsx
|
||||
const App = Store({
|
||||
state: { msg: "World" },
|
||||
render: ({ msg }) => <p>Hello {msg}</p>
|
||||
});
|
||||
|
||||
App.extend(({ state }) =>
|
||||
state.msg === "World" ? { msg: "ReactConf" } : state
|
||||
).extract(); // <p> Hello ReactConf </p>
|
||||
```
|
||||
|
||||
然而尴尬的是，笔者看了很久也没看懂 `Store` 函数，最后运行了一下发现这个 Demo 抛出了异常 😂。
|
||||
|
||||
下面是笔者稍微修改后的例子，至少能跑起来：
|
||||
|
||||
```js
|
||||
const Store = ({ state, render }) => ({
|
||||
extend: f => Store({ state, render: state => render(f({ state, render })) }),
|
||||
extract: () => render(state)
|
||||
});
|
||||
|
||||
const app = Store({
|
||||
state: { msg: "Hello World" },
|
||||
render: ({ msg }) => console.log("render " + msg)
|
||||
});
|
||||
|
||||
app
|
||||
.extend(({ state }) => {
|
||||
return { msg: state.msg + " extend1" };
|
||||
})
|
||||
.extend(({ state }) => {
|
||||
return { msg: state.msg + " extend2" };
|
||||
})
|
||||
.extract(); // render Hello World extend2 extend1
|
||||
```
|
||||
|
||||
然而作者的意思仍是未解之谜，希望对函数式了解的同学可以在评论区指点一下。
|
||||
|
||||
### wick editor
|
||||
|
||||
[wick editor](https://www.wickeditor.com/) 是一个开源的动画、游戏制作软件。
|
||||
|
||||
wick editor 是一个动画制作工具，但拓展了一些 js 编程能力，因此可以很好的将动画与游戏结合在一起：
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/tfs/TB1hLJpnbr1gK0jSZR0XXbP8XXa-1766-1002.png">
|
||||
|
||||
演讲介绍了 wick editor 的演化过程：
|
||||
|
||||
从很简陋的 MVP 版本开始（1 周）
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/tfs/TB11sdsneL2gK0jSZFmXXc7iXXa-1192-764.png">
|
||||
|
||||
到 Pre-Alpha（4 月）
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/tfs/TB1TMJnnXY7gK0jSZKzXXaikpXa-1306-858.png">
|
||||
|
||||
Alpha（5 月）
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/tfs/TB1608pnoD1gK0jSZFGXXbd3FXa-1794-1186.png">
|
||||
|
||||
Beta（1.5 年）
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/tfs/TB1CKJpnoD1gK0jSZFGXXbd3FXa-1274-854.png">
|
||||
|
||||
重点是 1.0 版本采用 React 重写了！继 Beta 之后又经历了 1 年：
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/tfs/TB1ZZhrneH2gK0jSZFEXXcqMpXa-906-596.png">
|
||||
|
||||
这个团队最棒的地方是，将游戏与教育结合，针对不同场景做了很多用户调研并根据反馈持续改进。
|
||||
|
||||
### React Select
|
||||
|
||||
[react-select](https://github.com/JedWatson/react-select) 的作者 [Jed Watson](https://github.com/JedWatson) 被请来啦。作为一个看上去很简单组件（select）的开发者，却拥有如此大的关注量（1.8w star），那作者有着怎样的心路历程呢？
|
||||
|
||||
react-select 看似简单的名字背后其实有挺多的功能，比如作者列举了一些功能层面的内容：
|
||||
|
||||
- autocomplete - 输入时搜索。
|
||||
- 单、多选。
|
||||
- focus 管理。
|
||||
- 下拉框层级与位置，比如可以放在根 DOM 节点，也可以作为当前节点的子元素。
|
||||
- 异步下拉框内容。
|
||||
- 键盘、触控。
|
||||
- Createble，即在搜索时如果没有内容可以动态创建。
|
||||
- 等等。
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/tfs/TB1RYS1mubviK0jSZFNXXaApXXa-1166-226.png">
|
||||
|
||||
在设计层面：
|
||||
|
||||
- 申明式。
|
||||
- 可以被定制。
|
||||
- 性能要求。
|
||||
- 等等。
|
||||
|
||||
随着 Star 逐渐上涨，越来越多的需求被提出，核心库代码量越来越大，甚至许多需求之间都是相互冲突的，而且作者每天都会被上百个 Issue 与 PR 吵醒。做一个业务 Select 可能只要 5 分钟，但做一个开源 Select 却要 5 年，原因是一个简单的 Select 如何满足所有不同业务场景？这绝对是个巨大的挑战。
|
||||
|
||||
比如用户即需要受控也要非受控的组件，如何满足好这个需求同时又让代码更可维护呢？
|
||||
|
||||
假设我们拥有一个受控的组件 `SelectComponent`，那么它的主要 props 是 `value` 与 `onChange`，如果要拓展成一个既支持 `defaultValue`（非受控）又支持 `value`（受控）的组件，我们可以创建一个 `manageState` 组件对 `SelectComponent` 进行封装：
|
||||
|
||||
```jsx
|
||||
const manageState = SelectComponent => ({
|
||||
value: valueProps,
|
||||
onChange: onChangeProp,
|
||||
defaultValue,
|
||||
...props
|
||||
}) => {
|
||||
const [valueState, setValue] = useState(defaultValue);
|
||||
|
||||
const value = valueProps !== undefined ? valueProps : valueState;
|
||||
|
||||
const onChange = (newValue, actionMeta) => {
|
||||
if (typeof onChangeProp === "function") {
|
||||
onChangeProp(newValue, actionMeta);
|
||||
}
|
||||
setValue(newValue);
|
||||
};
|
||||
|
||||
return <SelectComponent {...props} value={value} onChange={onChange}>
|
||||
};
|
||||
```
|
||||
|
||||
这样就可以组合为一个受控/非受控的综合 Select 组件：
|
||||
|
||||
```js
|
||||
import BaseSelect from "./Select";
|
||||
import manageState from "./manageState";
|
||||
|
||||
export default manageState(Select);
|
||||
```
|
||||
|
||||
同理对异步的封装也可以放在 `makeAsync` 函数中：
|
||||
|
||||
```jsx
|
||||
const makeAsync = SelectComponent => ({
|
||||
getOptions,
|
||||
defaultOptions,
|
||||
...props
|
||||
}) => {
|
||||
const [options, setOptions] = useState(defaultOptions);
|
||||
const [isLoading, setIsLoading] = useState(false);
|
||||
|
||||
const onInputChange = async newValue => {
|
||||
setIsLoading(true);
|
||||
const newOptions = await getOptions(newValue);
|
||||
setIsLoading(false);
|
||||
setOptions(newOptions);
|
||||
};
|
||||
|
||||
return (
|
||||
<SelectComponent
|
||||
{...props}
|
||||
options={options}
|
||||
isLoading={isLoading}
|
||||
onInputChange={onInputChange}
|
||||
/>
|
||||
);
|
||||
};
|
||||
```
|
||||
|
||||
可以看到，`SelectComponent` 是一个完全受控的数据驱动的 UI，无论是 `manageState` 还是 `makeAsync` 都是对数据处理的拓展，所以这三者之间才可以融洽的组合：
|
||||
|
||||
```js
|
||||
import BaseSelect from "./Select";
|
||||
import manageState from "./manageState";
|
||||
import makeAsync from "./async";
|
||||
|
||||
export default manageState(Select);
|
||||
|
||||
export const AsyncSelect = manageState(makeAsync(Select));
|
||||
```
|
||||
|
||||
后面还有一些风格化、开源协作的思考，这里就不展开了，对这部分感兴趣的同学可以查看原视频了解更多。
|
||||
|
||||
### React + 政府财政透明项目
|
||||
|
||||
usaspending.gov 这个网站使用 React 建设，可以查看美国政府支持财政的明细，通过流畅的体验让更多用户可以了解国家财政支出，进一步推动财政支出的透明化。由于并不涉及前端技术的介绍，主要是产品介绍，因此精读就不详细展开了。
|
||||
|
||||
顺便说一句，智能分析数据就用 [QuickBI](https://www.alibabacloud.com/zh/product/quickbi)，QuickBI 是我们团队研发的一款智能 BI 服务平台，如果你将美国政府的财政支持作为数据集输入，你会分析得更透彻。
|
||||
|
||||
### React + 星舰模拟器
|
||||
|
||||
最后介绍的是使用 React 制作的星舰模拟器，看上去像一个游戏：
|
||||
|
||||
<img width=500 src="https://img.alicdn.com/tfs/TB1HrxAneL2gK0jSZPhXXahvXXa-1946-1104.png">
|
||||
|
||||
有星系图、船体、驾驶员信息、武器装备、燃料、通信等等内容。甚至可以模拟太空驾驶，进行任务，可以实时多人协同。对太空迷们的吸引力很大，感兴趣的同学建议直接观看 [视频](https://youtu.be/JDDxR1a15Yo?t=28638)。
|
||||
|
||||
## 3 总结
|
||||
|
||||
第二天的内容非常全面，涉及了 React API、开发者周边、codemod 工具、代码维护、写作/音乐与代码、动画、函数式编程、看似简单的 React 组件、使用 React 制作的各种脑洞大开的项目，等等。
|
||||
|
||||
React Conf 要展示的是一个完整的 React 世界，第一天提到了 React 是一个桥梁，正因为这个桥梁，连接了各行各业不同的人群以及不同的项目，大家都有一个共同的语言：React。
|
||||
|
||||
"We not only react code, but react the world"。
|
||||
|
||||
> 讨论地址是：[精读《React Conf 2019 - Day2》 · Issue #217 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/217)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
|
||||
|
||||
> 关注 **前端精读微信公众号**
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
|
||||
Reference in New Issue
Block a user