Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 ascoders
|
b9fb7c80f2 | ||
|
ascoders
|
03519c41f6 | ||
|
ascoders
|
8ff1e9e21a | ||
|
ascoders
|
93882be318 | ||
|
黄子毅
|
d0dee4bbd7 | ||
|
Linear-Enter
|
3cc44000eb | ||
|
Linear-Enter
|
46cdabeb86 | ||
|
ascoders
|
71258f1b83 | ||
|
ascoders
|
1d95103bfb | ||
|
ascoders
|
b9d9292040 | ||
|
黄子毅
|
7ce55795a2 | ||
|
Linear-Enter
|
2a420c455e | ||
|
ascoders
|
069cf8f947 | ||
|
ascoders
|
af86669e18 | ||
|
ascoders
|
50c4409e29 |
@@ -154,7 +154,7 @@ Table 主要配置分为行、列、标记与筛选。通过这四个配置区
|
||||
|
||||
我们会发现，原本存在于列的 Category 被自动挪到了行，原本存在于行的 Sales 被挪到了 “标记” 区域。在正式介绍 “标记” 区域前，先理解一下为何会发生这种转变：
|
||||
|
||||
**表格类组件是双维度组件，折线图是单维度组件。**也就是表格的行与列都是维度，而折线图横轴作为维度后，纵轴就要作为度量。上面的例子中，折线图维度有两个字段，虽然通过分面方式渲染出来了，但当切换为支持双维度的表格后， **可以将多余的一个维度挪到表格组件另一个维度区域中**。
|
||||
**表格类组件是双维度组件，折线图是单维度组件。** 也就是表格的行与列都是维度，而折线图横轴作为维度后，纵轴就要作为度量。上面的例子中，折线图维度有两个字段，虽然通过分面方式渲染出来了，但当切换为支持双维度的表格后， **可以将多余的一个维度挪到表格组件另一个维度区域中**。
|
||||
|
||||
而表格行与列都是维度的情况下，单元格的值就需要用 “标记” 中文本来表示，因此原折线图的度量字段自动转移到了 “标记” 区域。
|
||||
|
||||
@@ -313,7 +313,7 @@ Tableau 内置的图表分为 N 大类 - **表格、地图、柱折面饼、散
|
||||
|
||||
<img width=529 src="https://cdn.nlark.com/yuque/0/2019/png/201572/1566699040802-40a23a43-7a23-43d1-9d06-27a6413803e8.png#align=left&display=inline&height=314&name=image.png&originHeight=856&originWidth=1440&size=106220&status=done&width=529">
|
||||
|
||||
**上图也可以理解为展示出 Order Date 与 Order ID 的明细数据，按照 Order Date 分组且列合并。**下钻就是一步步接近明细数据的过程，但目的不是为了看明细表，而是看某些维度下按其他维度拆分的详细信息。
|
||||
**上图也可以理解为展示出 Order Date 与 Order ID 的明细数据，按照 Order Date 分组且列合并。** 下钻就是一步步接近明细数据的过程，但目的不是为了看明细表，而是看某些维度下按其他维度拆分的详细信息。
|
||||
|
||||
图表下钻和表格思路是一致的：
|
||||
|
||||
@@ -323,9 +323,9 @@ Tableau 内置的图表分为 N 大类 - **表格、地图、柱折面饼、散
|
||||
|
||||
<img width=667 src="https://cdn.nlark.com/yuque/0/2019/png/201572/1566700041429-03bcb68a-dd00-4cab-a256-f37234bb2300.png#align=left&display=inline&height=423&name=image.png&originHeight=1350&originWidth=2128&size=155697&status=done&width=667">
|
||||
|
||||
**可以认为，当行或列上最后一个字段为度量时，就会切换为图表展示，因为图表适合展示连续状态。**如果排除上图蓝色区域，剩下的区域就是个交叉表，交叉表只是行与列同时存在维度字段的场景，仅有行或列时就变成了普通表格；而图形的下钻和表格下钻机理相同，只是把 “单元格” 的文本换成了柱子或线。
|
||||
**可以认为，当行或列上最后一个字段为度量时，就会切换为图表展示，因为图表适合展示连续状态。** 如果排除上图蓝色区域，剩下的区域就是个交叉表，交叉表只是行与列同时存在维度字段的场景，仅有行或列时就变成了普通表格；而图形的下钻和表格下钻机理相同，只是把 “单元格” 的文本换成了柱子或线。
|
||||
|
||||
**所以对任何图表的下钻，都是对轴的下钻，**相同的是单元格属性永远不会改变，表格的单元格是文本，图形单元格是图形，一个简单折线图可以理解为对整体行与列单元格进行 “连续打通”：
|
||||
**所以对任何图表的下钻，都是对轴的下钻，** 相同的是单元格属性永远不会改变，表格的单元格是文本，图形单元格是图形，一个简单折线图可以理解为对整体行与列单元格进行 “连续打通”：
|
||||
|
||||
<img width=406 src="https://cdn.nlark.com/yuque/0/2019/png/201572/1566700448492-a7b96c99-b600-41b0-9159-e88412f4402b.png#align=left&display=inline&height=329&name=image.png&originHeight=1342&originWidth=1654&size=105794&status=done&width=406">
|
||||
|
||||
|
||||
@@ -334,7 +334,7 @@ let [data, setData] = useState(
|
||||
let [isValidating, setIsValidating] = useState(false);
|
||||
```
|
||||
|
||||
而取数状态变化时往往 `data` 与 `isValidating` 要一起更新，为了仅触发一次更新，使用了 `unstable_batchedUpdates` 将更新合并为一次：
|
||||
而取数状态变化时往往 `data` 与 `isValidating` 要一起更新，为了仅触发一次更新，使用了 <del>`unstable_batchedUpdates` 将更新合并为一次：</del>
|
||||
|
||||
```tsx
|
||||
unstable_batchedUpdates(() => {
|
||||
@@ -344,7 +344,13 @@ unstable_batchedUpdates(() => {
|
||||
});
|
||||
```
|
||||
|
||||
|
||||
其实还有别的解法，比如使用 `useReducer` 管理数据也能达到相同性能效果。
|
||||
目前源码已经从`unstable_batchedUpdates`切换为 `useReducer`管理
|
||||
```tsx
|
||||
dispatch(newState);
|
||||
```
|
||||
|
||||
|
||||
### 3.3 初始缓存
|
||||
|
||||
@@ -402,7 +408,7 @@ return {
|
||||
|
||||
### 3.5 依赖的请求
|
||||
|
||||
翻了一下代码，没有找到对循环依赖特别处理的逻辑，**后来看了官方文档才恍然大悟，原来是通过 `try/catch` + `onErrorRetry` 机制实现依赖取数的。**
|
||||
翻了一下代码，没有找到对循环依赖特别处理的逻辑，**后来看了官方文档才恍然大悟，原来是通过 `try/catch` 并巧妙结合 React 的 UI=f(data) 机制实现依赖取数的。**
|
||||
|
||||
看下面这段代码：
|
||||
|
||||
@@ -414,21 +420,34 @@ const { data: projects } = useSWR(() => "/api/projects?uid=" + user.id);
|
||||
怎么做到智能按依赖顺序请求呢？我们看 `useSWR` 取数函数的主体逻辑：
|
||||
|
||||
```tsx
|
||||
try {
|
||||
// 设置 isValidation 为 true
|
||||
// 取数、onSuccess 回调
|
||||
// 设置 isValidation 为 false
|
||||
// 设置缓存
|
||||
// unstable_batchedUpdates
|
||||
} catch (err) {
|
||||
// 撤销取数、缓存等对象
|
||||
// 调用 onErrorRetry
|
||||
}
|
||||
const revalidate = useCallback(
|
||||
async() => {
|
||||
try {
|
||||
// 设置 isValidation 为 true
|
||||
// 取数、onSuccess 回调
|
||||
// 设置 isValidation 为 false
|
||||
// 设置缓存
|
||||
// unstable_batchedUpdates
|
||||
} catch (err) {
|
||||
// 撤销取数、缓存等对象
|
||||
// 调用 onError回调
|
||||
}
|
||||
},
|
||||
[key]
|
||||
)
|
||||
|
||||
useIsomorphicLayoutEffect(
|
||||
()=>{
|
||||
....
|
||||
},
|
||||
[key,revalidate,...]
|
||||
)
|
||||
|
||||
```
|
||||
|
||||
可见取数逻辑被 `try` 住了，那么 `user.id` 在 `useSWR("/api/user")` 没有 Ready 的情况一定会抛出异常，则自动进入 `onErrorRetry` 逻辑，看看下次取数时 `user.id` 有没有 Ready。
|
||||
每次渲染的时候，SWR 会试着执行 `key` 函数（例如 () => "/api/projects?uid=" + user.id)，如果这个函数抛出异常，那么就意味着它的依赖还没有就绪（user === undefined），SWR 将暂停这个数据的请求。在任一数据完成加载时，由于 `setState` 触发重渲染，上述 Hooks 会被重选执行一遍（再次检查数据依赖是否就绪）然后对就绪的数据发起新的一轮请求。
|
||||
|
||||
那么什么时候才轮到下次取数呢？这个时机是：
|
||||
另外对于一些正常请求碰到 error（shouldRetryOnError 默认为 true）的情况下，下次取数的时机是：
|
||||
|
||||
```tsx
|
||||
const count = Math.min(opts.retryCount || 0, 8);
|
||||
|
||||
@@ -0,0 +1,579 @@
|
||||
## 1 引言
|
||||
|
||||
[unstated](https://github.com/jamiebuilds/unstated) 是基于 Class Component 的数据流管理库，[unstated-next](https://github.com/jamiebuilds/unstated-next) 是针对 Function Component 的升级版，且特别优化了对 Hooks 的支持。
|
||||
|
||||
与类 redux 库相比，这个库设计的别出心裁，而且这两个库源码行数都特别少，与 180 行的 unstated 相比，unstated-next 只有不到 40 行，但想象空间却更大，且用法符合直觉，所以本周精读就会从用法与源码两个角度分析这两个库。
|
||||
|
||||
## 2 概述
|
||||
|
||||
**首先问，什么是数据流？React 本身就提供了数据流，那就是 `setState` 与 `useState`，数据流框架存在的意义是解决跨组件数据共享与业务模型封装。**
|
||||
|
||||
还有一种说法是，React 早期声称自己是 UI 框架，不关心数据，因此需要生态提供数据流插件弥补这个能力。但其实 React 提供的 `createContext` 与 `useContext` 已经能解决这个问题，只是使用起来稍显麻烦，而 unstated 系列就是为了解决这个问题。
|
||||
|
||||
### unstated
|
||||
|
||||
unstated 解决的是 Class Component 场景下组件数据共享的问题。
|
||||
|
||||
相比直接抛出用法，笔者还原一下作者的思考过程：利用原生 `createContext` 实现数据流需要两个 UI 组件，且实现方式冗长：
|
||||
|
||||
```jsx
|
||||
const Amount = React.createContext(1);
|
||||
|
||||
class Counter extends React.Component {
|
||||
state = { count: 0 };
|
||||
increment = amount => {
|
||||
this.setState({ count: this.state.count + amount });
|
||||
};
|
||||
decrement = amount => {
|
||||
this.setState({ count: this.state.count - amount });
|
||||
};
|
||||
render() {
|
||||
return (
|
||||
<Amount.Consumer>
|
||||
{amount => (
|
||||
<div>
|
||||
<span>{this.state.count}</span>
|
||||
<button onClick={() => this.decrement(amount)}>-</button>
|
||||
<button onClick={() => this.increment(amount)}>+</button>
|
||||
</div>
|
||||
)}
|
||||
</Amount.Consumer>
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
class AmountAdjuster extends React.Component {
|
||||
state = { amount: 0 };
|
||||
handleChange = event => {
|
||||
this.setState({
|
||||
amount: parseInt(event.currentTarget.value, 10)
|
||||
});
|
||||
};
|
||||
render() {
|
||||
return (
|
||||
<Amount.Provider value={this.state.amount}>
|
||||
<div>
|
||||
{this.props.children}
|
||||
<input
|
||||
type="number"
|
||||
value={this.state.amount}
|
||||
onChange={this.handleChange}
|
||||
/>
|
||||
</div>
|
||||
</Amount.Provider>
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
render(
|
||||
<AmountAdjuster>
|
||||
<Counter />
|
||||
</AmountAdjuster>
|
||||
);
|
||||
```
|
||||
|
||||
而我们要做的，**是将 `setState` 从具体的某个 UI 组件上剥离，形成一个数据对象实体，可以被注入到任何组件。**
|
||||
|
||||
这就是 `unstated` 的使用方式：
|
||||
|
||||
```jsx
|
||||
import React from "react";
|
||||
import { render } from "react-dom";
|
||||
import { Provider, Subscribe, Container } from "unstated";
|
||||
|
||||
class CounterContainer extends Container {
|
||||
state = {
|
||||
count: 0
|
||||
};
|
||||
|
||||
increment() {
|
||||
this.setState({ count: this.state.count + 1 });
|
||||
}
|
||||
|
||||
decrement() {
|
||||
this.setState({ count: this.state.count - 1 });
|
||||
}
|
||||
}
|
||||
|
||||
function Counter() {
|
||||
return (
|
||||
<Subscribe to={[CounterContainer]}>
|
||||
{counter => (
|
||||
<div>
|
||||
<button onClick={() => counter.decrement()}>-</button>
|
||||
<span>{counter.state.count}</span>
|
||||
<button onClick={() => counter.increment()}>+</button>
|
||||
</div>
|
||||
)}
|
||||
</Subscribe>
|
||||
);
|
||||
}
|
||||
|
||||
render(
|
||||
<Provider>
|
||||
<Counter />
|
||||
</Provider>,
|
||||
document.getElementById("root")
|
||||
);
|
||||
```
|
||||
|
||||
首先要为 `Provider` 正名：`Provider` 是解决单例 Store 的最佳方案，当项目与组件都是用了数据流，需要分离作用域时，`Provider` 便派上了用场。如果项目仅需单 Store 数据流，那么与根节点放一个 `Provider` 等价。
|
||||
|
||||
其次 `CounterContainer` 成为一个真正数据处理类，只负责存储与操作数据，通过 `<Subscribe to={[CounterContainer]}>` RenderProps 方法将 `counter` 注入到 Render 函数中。
|
||||
|
||||
**unstated 方案本质上利用了 `setState`，但将 `setState` 与 UI 剥离，并可以很方便的注入到任何组件中。**
|
||||
|
||||
类似的是，其升级版 `unstated-next` 本质上利用了 `useState`，利用了自定义 Hooks 可以与 UI 分离的特性，加上 `useContext` 的便捷性，利用不到 40 行代码实现了比 `unstated` 更强大的功能。
|
||||
|
||||
### unstated-next
|
||||
|
||||
`unstated-next` 用 40 行代码号称 React 数据管理库的终结版，让我们看看它是怎么做到的！
|
||||
|
||||
还是从思考过程说起，笔者发现其 README 也提供了对应思考过程，就以其 README 里的代码作为案例。
|
||||
|
||||
首先，使用 Function Component 的你会这样使用数据流：
|
||||
|
||||
```jsx
|
||||
function CounterDisplay() {
|
||||
let [count, setCount] = useState(0);
|
||||
let decrement = () => setCount(count - 1);
|
||||
let increment = () => setCount(count + 1);
|
||||
return (
|
||||
<div>
|
||||
<button onClick={decrement}>-</button>
|
||||
<p>You clicked {count} times</p>
|
||||
<button onClick={increment}>+</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
如果想将数据与 UI 分离，利用 Custom Hooks 就可以完成，这不需要借助任何框架：
|
||||
|
||||
```jsx
|
||||
function useCounter() {
|
||||
let [count, setCount] = useState(0);
|
||||
let decrement = () => setCount(count - 1);
|
||||
let increment = () => setCount(count + 1);
|
||||
return { count, decrement, increment };
|
||||
}
|
||||
|
||||
function CounterDisplay() {
|
||||
let counter = useCounter();
|
||||
return (
|
||||
<div>
|
||||
<button onClick={counter.decrement}>-</button>
|
||||
<p>You clicked {counter.count} times</p>
|
||||
<button onClick={counter.increment}>+</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
如果想将这个数据分享给其他组件，利用 `useContext` 就可以完成，这不需要借助任何框架：
|
||||
|
||||
```jsx
|
||||
function useCounter() {
|
||||
let [count, setCount] = useState(0);
|
||||
let decrement = () => setCount(count - 1);
|
||||
let increment = () => setCount(count + 1);
|
||||
return { count, decrement, increment };
|
||||
}
|
||||
|
||||
let Counter = createContext(null);
|
||||
|
||||
function CounterDisplay() {
|
||||
let counter = useContext(Counter);
|
||||
return (
|
||||
<div>
|
||||
<button onClick={counter.decrement}>-</button>
|
||||
<p>You clicked {counter.count} times</p>
|
||||
<button onClick={counter.increment}>+</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function App() {
|
||||
let counter = useCounter();
|
||||
return (
|
||||
<Counter.Provider value={counter}>
|
||||
<CounterDisplay />
|
||||
<CounterDisplay />
|
||||
</Counter.Provider>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
但这样还是显示使用了 `useContext` 的 API，并且对 `Provider` 的封装没有形成固定模式，这就是 `usestated-next` 要解决的问题。
|
||||
|
||||
所以这就是 `unstated-next` 的使用方式：
|
||||
|
||||
```jsx
|
||||
import { createContainer } from "unstated-next";
|
||||
|
||||
function useCounter() {
|
||||
let [count, setCount] = useState(0);
|
||||
let decrement = () => setCount(count - 1);
|
||||
let increment = () => setCount(count + 1);
|
||||
return { count, decrement, increment };
|
||||
}
|
||||
|
||||
let Counter = createContainer(useCounter);
|
||||
|
||||
function CounterDisplay() {
|
||||
let counter = Counter.useContainer();
|
||||
return (
|
||||
<div>
|
||||
<button onClick={counter.decrement}>-</button>
|
||||
<p>You clicked {counter.count} times</p>
|
||||
<button onClick={counter.increment}>+</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function App() {
|
||||
return (
|
||||
<Counter.Provider>
|
||||
<CounterDisplay />
|
||||
<CounterDisplay />
|
||||
</Counter.Provider>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，`createContainer` 可以将任何 Hooks 包装成一个数据对象，这个对象有 `Provider` 与 `useContainer` 两个 API，其中 `Provider` 用于对某个作用域注入数据，而 `useContainer` 可以取到这个数据对象在当前作用域的实例。
|
||||
|
||||
对 Hooks 的参数也进行了规范化，我们可以通过 `initialState` 设定初始化数据，且不同作用域可以嵌套并赋予不同的初始化值：
|
||||
|
||||
```jsx
|
||||
function useCounter(initialState = 0) {
|
||||
let [count, setCount] = useState(initialState);
|
||||
let decrement = () => setCount(count - 1);
|
||||
let increment = () => setCount(count + 1);
|
||||
return { count, decrement, increment };
|
||||
}
|
||||
|
||||
const Counter = createContainer(useCounter);
|
||||
|
||||
function CounterDisplay() {
|
||||
let counter = Counter.useContainer();
|
||||
return (
|
||||
<div>
|
||||
<button onClick={counter.decrement}>-</button>
|
||||
<span>{counter.count}</span>
|
||||
<button onClick={counter.increment}>+</button>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function App() {
|
||||
return (
|
||||
<Counter.Provider>
|
||||
<CounterDisplay />
|
||||
<Counter.Provider initialState={2}>
|
||||
<div>
|
||||
<div>
|
||||
<CounterDisplay />
|
||||
</div>
|
||||
</div>
|
||||
</Counter.Provider>
|
||||
</Counter.Provider>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
**可以看到，React Hooks 已经非常适合做状态管理，而生态应该做的事情是尽可能利用其能力进行模式化封装。**
|
||||
|
||||
> 有人可能会问，取数和副作用怎么办？`redux-saga` 和其他中间件都没有，这个数据流是不是阉割版？
|
||||
|
||||
首先我们看 Redux 为什么需要处理副作用的中间件。这是因为 `reducer` 是一个同步纯函数，其返回值就是操作结果中间不能有异步，且不能有副作用，所以我们需要一种异步调用 `dispatch` 的方法，或者一个副作用函数来存放这些 “脏” 逻辑。
|
||||
|
||||
而在 Hooks 中，我们可以随时调用 `useState` 提供的 `setter` 函数修改值，这早已天然解决了 `reducer` 无法异步的问题，同时也实现了 `redux-chunk` 的功能。
|
||||
|
||||
而异步功能也被 `useEffect` 这个 React 官方 Hook 替代。**我们看到这个方案可以利用 React 官方提供的能力完全覆盖 Redux 中间件的能力，对 Redux 库实现了降维打击，所以下一代数据流方案随着 Hooks 的实现是真的存在的**。
|
||||
|
||||
最后，相比 Redux 自身以及其生态库的理解成本（笔者不才，初学 Redux 以及其周边 middleware 时理解了好久），Hooks 的理解学习成本明显更小。
|
||||
|
||||
**很多时候，人们排斥一个新技术，并不是因为新技术不好，而是这可能让自己多年精通的老手艺带来的 “竞争优势” 完全消失。可能一个织布老专家手工织布效率是入门学员的 5 倍，但换上织布机器后，这个差异很快会被抹平，老织布专家面临被淘汰的危机，所以维护这份老手艺就是维护他自己的利益。希望每个团队中的老织布工人都能主动引入织布机。**
|
||||
|
||||
> 再看取数中间件，我们一般需要解决 **取数业务逻辑封装** 与 **取数状态封装**，通过 redux 中间件可以封装在内，通过一个 `dispatch` 解决。
|
||||
|
||||
其实 Hooks 思维下，利用 [swr](<[swr](https://github.com/dt-fe/weekly/blob/v2/128.%E7%B2%BE%E8%AF%BB%E3%80%8AHooks%20%E5%8F%96%E6%95%B0%20-%20swr%20%E6%BA%90%E7%A0%81%E3%80%8B.md)>) `useSWR` 一样能解决：
|
||||
|
||||
```jsx
|
||||
function Profile() {
|
||||
const { data, error } = useSWR("/api/user");
|
||||
}
|
||||
```
|
||||
|
||||
取数的业务逻辑封装在 `fetcher` 中，这个在 `SWRConfigContext.Provider` 时就已注入，还可以控制作用域！完全利用 React 提供的 Context 能力，可以感受到实现底层原理的一致性和简洁性，越简单越优美的数学公式越可能是真理。
|
||||
|
||||
而取数状态已经封装在 `useSWR` 中，配合 Suspense 能力，连 Loading 状态都不用关心了。
|
||||
|
||||
## 3 精读
|
||||
|
||||
### unstated
|
||||
|
||||
我们再梳理一下 `unstated` 这个库做了哪些事情。
|
||||
|
||||
1. 利用 `Provider` 申明作用范围。
|
||||
2. 提供 `Container` 作为可以被继承的类，继承它的 Class 作为 Store。
|
||||
3. 提供 `Subscribe` 作为 RenderProps 用法注入 Store，注入的 Store 实例由参数 `to` 接收到的 Class 实例决定。
|
||||
|
||||
对于第一点，`Provider` 在 Class Component 环境下要初始化 `StateContext`，这样才能在 `Subscribe` 中使用：
|
||||
|
||||
```jsx
|
||||
const StateContext = createReactContext(null);
|
||||
|
||||
export function Provider(props) {
|
||||
return (
|
||||
<StateContext.Consumer>
|
||||
{parentMap => {
|
||||
let childMap = new Map(parentMap);
|
||||
|
||||
if (props.inject) {
|
||||
props.inject.forEach(instance => {
|
||||
childMap.set(instance.constructor, instance);
|
||||
});
|
||||
}
|
||||
|
||||
return (
|
||||
<StateContext.Provider value={childMap}>
|
||||
{props.children}
|
||||
</StateContext.Provider>
|
||||
);
|
||||
}}
|
||||
</StateContext.Consumer>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
对于第二点，对于 `Container`，需要提供给 Store `setState` API，按照 React 的 `setState` 结构实现了一遍。
|
||||
|
||||
值得注意的是，还存储了一个 `_listeners` 对象，并且可通过 `subscribe` 与 `unsubscribe` 增删。
|
||||
|
||||
`_listeners` 存储的其实是当前绑定的组件 `onUpdate` 生命周期，然后在 `setState` 时主动触发对应组件的渲染。`onUpdate` 生命周期由 `Subscribe` 函数提供，最终调用的是 `this.setState`，这个在 `Subscribe` 部分再说明。
|
||||
|
||||
以下是 `Container` 的代码实现：
|
||||
|
||||
```jsx
|
||||
export class Container<State: {}> {
|
||||
state: State;
|
||||
_listeners: Array<Listener> = [];
|
||||
|
||||
constructor() {
|
||||
CONTAINER_DEBUG_CALLBACKS.forEach(cb => cb(this));
|
||||
}
|
||||
|
||||
setState(
|
||||
updater: $Shape<State> | ((prevState: $Shape<State>) => $Shape<State>),
|
||||
callback?: () => void
|
||||
): Promise<void> {
|
||||
return Promise.resolve().then(() => {
|
||||
let nextState;
|
||||
|
||||
if (typeof updater === "function") {
|
||||
nextState = updater(this.state);
|
||||
} else {
|
||||
nextState = updater;
|
||||
}
|
||||
|
||||
if (nextState == null) {
|
||||
if (callback) callback();
|
||||
return;
|
||||
}
|
||||
|
||||
this.state = Object.assign({}, this.state, nextState);
|
||||
|
||||
let promises = this._listeners.map(listener => listener());
|
||||
|
||||
return Promise.all(promises).then(() => {
|
||||
if (callback) {
|
||||
return callback();
|
||||
}
|
||||
});
|
||||
});
|
||||
}
|
||||
|
||||
subscribe(fn: Listener) {
|
||||
this._listeners.push(fn);
|
||||
}
|
||||
|
||||
unsubscribe(fn: Listener) {
|
||||
this._listeners = this._listeners.filter(f => f !== fn);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
对于第三点，`Subscribe` 的 `render` 函数将 `this.props.children` 作为一个函数执行，并把对应的 Store 实例作为参数传递，这通过 `_createInstances` 函数实现。
|
||||
|
||||
`_createInstances` 利用 `instanceof` 通过 Class 类找到对应的实例，并通过 `subscribe` 将自己组件的 `onUpdate` 函数传递给对应 Store 的 `_listeners`，在解除绑定时调用 `unsubscribe` 解绑，防止不必要的 renrender。
|
||||
|
||||
以下是 `Subscribe` 源码：
|
||||
|
||||
```jsx
|
||||
export class Subscribe<Containers: ContainersType> extends React.Component<
|
||||
SubscribeProps<Containers>,
|
||||
SubscribeState
|
||||
> {
|
||||
state = {};
|
||||
instances: Array<ContainerType> = [];
|
||||
unmounted = false;
|
||||
|
||||
componentWillUnmount() {
|
||||
this.unmounted = true;
|
||||
this._unsubscribe();
|
||||
}
|
||||
|
||||
_unsubscribe() {
|
||||
this.instances.forEach(container => {
|
||||
container.unsubscribe(this.onUpdate);
|
||||
});
|
||||
}
|
||||
|
||||
onUpdate: Listener = () => {
|
||||
return new Promise(resolve => {
|
||||
if (!this.unmounted) {
|
||||
this.setState(DUMMY_STATE, resolve);
|
||||
} else {
|
||||
resolve();
|
||||
}
|
||||
});
|
||||
};
|
||||
|
||||
_createInstances(
|
||||
map: ContainerMapType | null,
|
||||
containers: ContainersType
|
||||
): Array<ContainerType> {
|
||||
this._unsubscribe();
|
||||
|
||||
if (map === null) {
|
||||
throw new Error(
|
||||
"You must wrap your <Subscribe> components with a <Provider>"
|
||||
);
|
||||
}
|
||||
|
||||
let safeMap = map;
|
||||
let instances = containers.map(ContainerItem => {
|
||||
let instance;
|
||||
|
||||
if (
|
||||
typeof ContainerItem === "object" &&
|
||||
ContainerItem instanceof Container
|
||||
) {
|
||||
instance = ContainerItem;
|
||||
} else {
|
||||
instance = safeMap.get(ContainerItem);
|
||||
|
||||
if (!instance) {
|
||||
instance = new ContainerItem();
|
||||
safeMap.set(ContainerItem, instance);
|
||||
}
|
||||
}
|
||||
|
||||
instance.unsubscribe(this.onUpdate);
|
||||
instance.subscribe(this.onUpdate);
|
||||
|
||||
return instance;
|
||||
});
|
||||
|
||||
this.instances = instances;
|
||||
return instances;
|
||||
}
|
||||
|
||||
render() {
|
||||
return (
|
||||
<StateContext.Consumer>
|
||||
{map =>
|
||||
this.props.children.apply(
|
||||
null,
|
||||
this._createInstances(map, this.props.to)
|
||||
)
|
||||
}
|
||||
</StateContext.Consumer>
|
||||
);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
总结下来，`unstated` 将 State 外置是通过自定义 Listener 实现的，在 Store `setState` 时触发收集好的 `Subscribe` 组件的 rerender。
|
||||
|
||||
### unstated-next
|
||||
|
||||
`unstated-next` 这个库只做了一件事情：
|
||||
|
||||
1. 提供 `createContainer` 将自定义 Hooks 封装为一个数据对象，提供 `Provider` 注入与 `useContainer` 获取 Store 这两个方法。
|
||||
|
||||
正如之前解析所说，`unstated-next` 可谓将 Hooks 用到了极致，认为 Hooks 已经完全具备数据流管理的全部能力，我们只要包装一层规范即可：
|
||||
|
||||
```jsx
|
||||
export function createContainer(useHook) {
|
||||
let Context = React.createContext(null);
|
||||
|
||||
function Provider(props) {
|
||||
let value = useHook(props.initialState);
|
||||
return <Context.Provider value={value}>{props.children}</Context.Provider>;
|
||||
}
|
||||
|
||||
function useContainer() {
|
||||
let value = React.useContext(Context);
|
||||
if (value === null) {
|
||||
throw new Error("Component must be wrapped with <Container.Provider>");
|
||||
}
|
||||
return value;
|
||||
}
|
||||
|
||||
return { Provider, useContainer };
|
||||
}
|
||||
```
|
||||
|
||||
可见，`Provider` 就是对 `value` 进行了约束，**固化了 Hooks 返回的 value 直接作为 `value` 传递给 `Context.Provider` 这个规范。**
|
||||
|
||||
而 `useContainer` 就是对 `React.useContext(Context)` 的封装。
|
||||
|
||||
真的没有其他逻辑了。
|
||||
|
||||
唯一需要思考的是，在自定义 Hooks 中，我们用 `useState` 管理数据还是 `useReducer` 管理数据的问题，这个是个仁者见仁的问题。不过我们可以对自定义 Hooks 进行嵌套封装，支持一些更复杂的数据场景，比如：
|
||||
|
||||
```jsx
|
||||
function useCounter(initialState = 0) {
|
||||
const [count, setCount] = useState(initialState);
|
||||
const decrement = () => setCount(count - 1);
|
||||
const increment = () => setCount(count + 1);
|
||||
return { count, decrement, increment };
|
||||
}
|
||||
|
||||
function useUser(initialState = {}) {
|
||||
const [name, setName] = useState(initialState.name);
|
||||
const [age, setAge] = useState(initialState.age);
|
||||
const registerUser = userInfo => {
|
||||
setName(userInfo.name);
|
||||
setAge(userInfo.age);
|
||||
};
|
||||
return { user: { name, age }, registerUser };
|
||||
}
|
||||
|
||||
function useApp(initialState) {
|
||||
const { count, decrement, increment } = useCounter(initialState.count);
|
||||
const { user, registerUser } = useUser(initialState.user);
|
||||
return { count, decrement, increment, user, registerUser };
|
||||
}
|
||||
|
||||
const App = createContainer(useApp);
|
||||
```
|
||||
|
||||
## 4 总结
|
||||
|
||||
借用 `unstated-next` 的标语：“never think about React state management libraries ever again” - 用了 `unstated-next` 再也不要考虑其他 React 状态管理库了。
|
||||
|
||||
而有意思的是，`unstated-next` 本身也只是对 Hooks 的一种模式化封装，Hooks 已经能很好解决状态管理的问题，我们真的不需要 “再造” React 数据流工具了。
|
||||
|
||||
> 讨论地址是：[精读《unstated 与 unstated-next 源码》 · Issue #218 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/218)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,218 @@
|
||||
## 1 引言
|
||||
|
||||
《从 0 到 1》是一本创业经典，创业非常有魅力，需要多种维度的商业知识，包括基础经济学、公司经济学、商业学、公司金融学、甚至历史学等等。
|
||||
|
||||
为什么要懂历史学？因为《从 0 到 1》这本书的作者是 彼得·蒂尔，他是 Paypal 的创始人和投资家，想读懂他的书就必须读懂他自己的创业经历，而 Paypal 的成长经历需要以考究历史的思维学习，了解什么是 Paypal 黑帮，他与其他公司的关系，为什么 Paypal 是继英特尔时隔 20 年之后的互联网黄埔军校。
|
||||
|
||||
为什么要懂商业学？本书第一句话就是 “在商业上机会只有一次”，这是商业基本准则之一。商业不是物理学，没有必然因果关系，没有商业必胜法。同时，商业也是训练多维度思考的战场，对一个商业结果的解读多种多样，我们需要避免对结果的简单归因、过度解读、甚至是本末倒置。《从 0 到 1》这本书抓住了创业成功的精髓。
|
||||
|
||||
《从 0 到 1》这本书，就是在商业这种复杂环境下，尝试总结一套通用的成功经验。然而前面我也说了，商业没有必胜法，那什么才是驱动成功与发展的根本引擎？**就是创新**。
|
||||
|
||||
## 2 概述 & 精读
|
||||
|
||||
### 未来的挑战
|
||||
|
||||
什么人能胜任未来的挑战？彼得蒂尔认为，有创新能力的人可以，所以他面试时喜欢问：**“有什么你与其他人有不同看法，但你觉得却很重要的事”**。能真正回答好这个问题的人才算具备了基本创新能力。
|
||||
|
||||
人类技术演进分为 **水平进步与垂直进步**，水平进步是从 1 到 N 的规模化应用，而垂直进步是从 0 到 1 的创造，虽然水平进步可以给发展中国家带来巨大发展速度，但真正推动历史变革的还在于垂直进步。
|
||||
|
||||
对于创业团队，独立思考与速度很重要，因此团队规模要尽量小。彼得蒂尔对 Paypal 的管理理念重点有二：**招人越像越好、极端聚焦**，Paypal 在早期时隔工程师都是 UIUC 毕业的，5 个非技术人员都是彼得蒂尔在斯坦福校友网络认识的，背景非常趋同，因此沟通成本非常低，决策效率很高。彼得蒂尔要求员工的年终总结必须明确写出 “对公司最有价值的一个贡献”，只能写一个。
|
||||
|
||||
根据 Paypal 发展经历来看，难怪《从 0 到 1》这本书会强调小团队高灵活的重要程度，因为 Paypal 就是这么起家的。
|
||||
|
||||
### 像 1999 年那样狂欢
|
||||
|
||||
1993 年网景公司的成立拉开互联网时代的序幕，Paypal 就是这个时代成立的。
|
||||
|
||||
互联网狂欢兴起：
|
||||
|
||||
<img width=400 src="https://user-images.githubusercontent.com/7970947/69900559-e75c1e80-13af-11ea-8f60-c3c80ef2ab98.png">
|
||||
|
||||
互联网泡沫破裂：
|
||||
|
||||
<img width=350 src="https://user-images.githubusercontent.com/7970947/69900566-03f85680-13b0-11ea-86f5-8faf80ae546d.png">
|
||||
|
||||
自 1999 年之后，市场学会了保守，主要有四条：
|
||||
|
||||
1. 循序渐进的发展。
|
||||
2. 保持精简和灵活。
|
||||
3. 不要贸然开辟新市场。
|
||||
4. 专注产品而不是营销。
|
||||
|
||||
显然，1999 年互联网泡沫破裂后的美国企业家害怕了，逐渐走向了保守。**然而彼得蒂尔认为，1999 年互联网泡沫破裂的虽然惨烈，但正因如此才带来了美国未来几十年的增长。** 保守无法带来成功，相反，这四条的反面反而更正确：
|
||||
|
||||
1. 大胆尝试胜过平庸保守。
|
||||
2. 坏计划也好过没有计划。
|
||||
3. 竞争性市场对收益有负面影响。
|
||||
4. 营销和产品同样重要。
|
||||
|
||||
**狂妄自大的尝试必定导致大部分人悲惨的失败，但我们别无选择，创业必须创新，必须实现从 0 到 1。** 所以彼得蒂尔反直觉的观点就是，我们不能因为吸取 1999 年的教训就变得保守，反而美国需要 1999 年那股狂热驱动新的创新。
|
||||
|
||||
### 所有成功的企业都是不同的
|
||||
|
||||
彼得蒂尔完美解释了垄断的价值。
|
||||
|
||||
市场分为充分竞争与完全垄断，看上去充分竞争的市场更有活力，更健康，但实则不然。**充分竞争将利润完全吞噬，只有完全垄断才能获得持久价值，最终对市场有利。**
|
||||
|
||||
对创业者来说也一样，如果你相信充分竞争，你只会创建一家同质化的公司，扎到红海里拼命挣扎，这不会给你带来持久的利益，也不会给市场带来真正的发展。
|
||||
|
||||
垄断者为了逃避垄断保护法，会竭尽全力证明自己没有取得垄断地位（甚至随时会被市场吃掉），同理，**竞争者为了自我麻痹或争取到投资，也会竭尽全力证明自己还有机会，市场并未形成垄断。** 然而无论怎么说，真正为市场创造独一无二价值的还是垄断者，虽然他们看起来很可恶。
|
||||
|
||||
不仅在商业如此，互联网公司内部技术竞争也一样：**低水平的重复竞争挑战者会竭尽全力证明自己所在的领域不存在垄断，然后投入人力做一个注定会失败的项目，不仅无法为公司产生新的价值，还带来了资源内耗。相反，那个垄断者才是为公司源源不断带来价值的引擎，虽然竞争者们都厌恶它。这也是为什么阿里鼓励高水平竞争，禁止低水平重复轮子。**
|
||||
|
||||
### 竞争意识
|
||||
|
||||
大家觉得竞争理所应当，但其实竞争更多带来的是伤害。
|
||||
|
||||
在奇葩说里听到薛兆丰这么一句话：“求职者你们的竞争对手不是企业，而是其他求职者”。说的很有道理，真正的伤害是在竞争中产生的，而存在供需关系的公司与求职者之间哪存在什么竞争？直白一点说，如果整个市场只有一个应聘者，哪怕小学没毕业，阿里腾讯也会抢着要。
|
||||
|
||||
**竞争使我们过度看中过去的机会，而忽略创造新的可能性。** 就像 Paypal 与 X 合并一样，彼得蒂尔发现这两家公司的竞争关系是恶性的，只有合并后形成垄断才能创造新的价值。而 X 公司的创始人就是埃隆·马斯克，虽然最后因为极力推广 X 品牌被合并后的 Paypal 请出局后，依然在 Paypal 被 20 多亿美元收购后，获得了一亿多美元回报，才创建了特斯拉和太空探索公司，真正为社会创造新的价值。
|
||||
|
||||
### 后发优势
|
||||
|
||||
既然垄断如此重要，那么如何打造垄断？
|
||||
|
||||
**首先一个企业的价值是它未来创造利润的总和**。也许你会奇怪，为什么企业现在的资产不算做企业价值呢？企业价值一般指的是企业市值，企业市值描述的企业价值其实是它的 **当前投资价值**，一个不能在未来创造利润的企业，就算现在坐拥几千亿美元的资产，对你来说也是没有投资价值的。
|
||||
|
||||
建立企业垄断，可以建立企业的护城河，比如专利技术或者网络效应；或者先进入小市场，逐步扩大范围，就像亚马逊从图书在线交易切入，随后扩张到全品类。与你的对手产生放大收益，你不能仅仅取代你的对手，最好能为它赋能。这些都是企业的后发优势。
|
||||
|
||||
### 成功不是中彩票
|
||||
|
||||
虽然大部分成功创业者都会将一半功劳归功于运气，但你最好不要真的相信，否则为什么有那么多连续失败的创业者呢？如果创业需要运气，那为什么彼得蒂尔要写《从 0 到 1》这本书，为什么我还要精读它呢？
|
||||
|
||||
**成功者的运气是靠努力换来的**。
|
||||
|
||||
国家就是一个巨大的创业，彼得蒂尔对当下各国对未来看法划出了四象限图：
|
||||
|
||||
<img width=400 src="https://user-images.githubusercontent.com/7970947/69900946-35275580-13b5-11ea-880b-63403fa154f5.png">
|
||||
|
||||
- 明确乐观的未来：1950～1970 的美国，当时美国创新能力和工程应用都在上升期，未来是明确且乐观的。
|
||||
- 不明确乐观的未来：1982 至今的美国，由于技术发展遇到了瓶颈，比如生物制药和医疗都有巨大不确定性，人们只知道未来是美好的，但不知道何时可以到来。
|
||||
- 明确悲观的未来：**现在的中国，由于缺乏核心创新能力，现在中国迅猛发展其实在吃发达国家创新的红利，只是将这些技术规模化应用，所以发展方向是明确的，但一旦红利吃完，不确定自己是否能找到新的突破点，因此对未来是悲观的。**
|
||||
- 不明确悲观的未来：现在的欧洲，技术红利和规模化都吃完了，不知道未来该怎么走，也不知道走向哪里。
|
||||
|
||||
不论国家还是公司，在这个时代想要拥有最好的未来，就是不明确乐观的未来，虽然这个乐观是不明确的，也就是需要运气，但只要在正确的方向努力，总是可能会成功。如果你真的相信比尔盖兹成功来源于运气，那请理解这是一个明确的运气，而不是不明确的运气，并不是所有方向的创业都可能走向成功。
|
||||
|
||||
### 向钱看
|
||||
|
||||
当爱因斯坦宣称复利是“世界第八大奇迹”，因为钱可以生钱，本质原因是指数级增长。指数级增长之所以如此可怕，还因为并没有证据表明爱英斯坦说过这句话，但因为他的影响力有指数级影响力，所有有影响力的话可能都会 “归功给他”。
|
||||
|
||||
风险投资领域也是如此，一家风投最成功的项目带来的收益可能超过其他所有项目的总和，所以风投才会不断给有发展潜力的企业加注，这都是因为指数级效应。
|
||||
|
||||
所以如果你创业的公司不能成为幂次法则指数增长的类型，最好尽快换一个项目，因为做一个平庸的项目是没有意义的，世界的天枰都会为头部项目加码。
|
||||
|
||||
### 秘密
|
||||
|
||||
企业只有创新才能获得成功，那一定是发现了新的 “商业秘密”。
|
||||
|
||||
但现在社会发展遇到了瓶颈，大家都不愿意探索新的秘密，主要有四个原因：
|
||||
|
||||
1. 认为已经没有新的秘密。就像探索世界一样，当地球完全被开发，已经没有探索的必要。
|
||||
2. 规避风险。害怕没有找到秘密而耽误自己的人生。
|
||||
3. 自满。安于现状，认为不需要探寻新的秘密。
|
||||
4. 扁平化。由于互联网对社会的连接，我们更容易觉得竞争是全球化的，如果有新的秘密，一定会更优秀的人发现，而显然我不是最优秀的人，所以我没有必要去发觉秘密，那些最优秀的人会帮我做到。
|
||||
|
||||
想要扭转这个悲观思想，**你需要意识到现代分工是极度专业化的，不同领域间往往很难竞争**，一个物理学家可能难于解决情感问题，要相信还有许多未被关注的细分领域可能存在蓝海。
|
||||
|
||||
### 基础决定命运
|
||||
|
||||
就像宪法决定了国家基础一样，企业最初决定的重要思想对未来发展起到决定因素，比如行业方向与招聘要求。
|
||||
|
||||
因此初创公司一定要确保创始人团队之间是否有默契，所有权、经营权和控制权是否分配合理，不要有兼职员工，最好以股权激励员工。
|
||||
|
||||
在技术领域做架构设计也是如此，架构基础决定了未来发展命运，我们必须尽可能保证早期架构设计的合理性，并坚持这些原则，就像坚持宪法一样。
|
||||
|
||||
### 黑手党式的机制
|
||||
|
||||
为什么 Paypal 早期员工被称为 Paypal 黑帮？其实彼得蒂尔创建的 Paypal 由于触及到金融领域，相关利益方非常复杂，对于没有政府背景的他来说几乎是不可能做成的。
|
||||
|
||||
Paypal 招来的早期员工必须极度认同其企业文化，认同 “创造虚拟货币代替美元” 这个疯狂的想法。
|
||||
|
||||
**Paypal 黑帮对公司的使命有着近乎于 “邪教” 般的信仰，唯一区别是，他们做的事情本身并不坏。**
|
||||
|
||||
### 顾客不会自动上门
|
||||
|
||||
销售和技术同样重要。
|
||||
|
||||
在工程技术界，技术打造的产品功能界限清晰，不是生效就是失效，而销售界，需要通过精心设计活动来打动用户的芳心，但却不能改变产品的实质性内容。技术内容是务实的，销售内容是务虚的，但我们不能说务实一定比务虚重要。
|
||||
|
||||
销售的技巧也随着业务场景的不同而不同。
|
||||
|
||||
- 复杂营销。当面对大企业客户时，甚至要克服政治惰性说服政府太空飞船采用你们公司的技术，而一旦完成协议的签署，哪怕只有几单，也足够维持公司后续发展了。
|
||||
- 人员营销。和复杂营销相反，需要从具体场景逐渐深入，比如 Box 公司的云存储服务，首先卖给了斯坦福睡眠诊所，之后逐步扩展到整个斯坦福大学，但如果 Box 一开始就和斯坦福的校长洽谈整个学校的云服务方案，可能一开始就会失败。
|
||||
- 病毒式营销。Paypal 的增长过程就是病毒式营销的范例，通过邀请机制传播给好友，并给最多 20 美元的奖励，也就是获客成本 20 元支撑了 Paypal 病毒式营销的成立。
|
||||
|
||||
然而 Paypal 也不是漫无目的的砸钱，首先它砸钱有自己的原因，因为 Paypal 是一个拥有网络效应的项目，因此拥有越多的用户就能带来越多的未来价值，这是 Paypal 可以选择烧钱营销的最大原因。
|
||||
|
||||
其次 Paypal 也选择了两个聪明的营销方式，第一是通过邮箱营销，由于当时世界上拥有邮箱的用户很少，都是一些对新技术持有开放态度的用户，因此邮件营销的人群就比较正确。后来 Paypal 发现，eBay 有部分商家甚至主动在商户页面贴出注册 Paypal 的链接，不仅是为了赚取佣金，更因为 Paypal 网络支付的最大场景就是电商交易平台，因此后续 Paypal 重点转向 eBay 推广。
|
||||
|
||||
### 人类和机器
|
||||
|
||||
**机器未来并不是为了取代人类，而是辅助人类更高效工作。** 在 [精读《刷新》](https://github.com/dt-fe/weekly/blob/v2/116.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%88%B7%E6%96%B0%E3%80%8B.md#%E5%85%B6%E5%AE%83) 中，微软 CEO 萨提亚·纳德拉也提到了人与机器的关系 - “机器替代人类工作的过程，也是人类逐渐拾回作为人的尊严的过程。人本就应该将时间用于思考与创造，而不是重复性劳动。”
|
||||
|
||||
有意思的是，彼得蒂尔在创立 Paypal 过程中由于遇到不法分子盗刷信用卡的问题，因此专门研究网络安全并研发出验证码、数据分析等一直沿用至今的重要网络安全技术，甚至在 Paypal 被 eBay 收购后，彼得蒂尔还专门成立了 Clarium Capital 公司为政府提供安全服务，其核心技术就是在 Paypal 期间为了对抗支付安全问题时打下基础的。
|
||||
|
||||
所以彼得蒂尔在思考机器和人类关系时，会重点关注机器帮助人类提升价值的领域。其中有一句话触达了问题本质：**“机器不会有利己的诉求，因此价值最终会转移至人类”。** 只要机器永远不要求自我价值的实现，人类和机器就能和平共处下去。
|
||||
|
||||
### 绿色能源与特斯拉
|
||||
|
||||
由于彼得蒂尔与埃隆·马斯克曾经互为敌友关系，因此就关注到了特斯拉与绿色能源的问题。
|
||||
|
||||
彼得蒂尔认为，绿色能源技术要思考好如下 7 个问题：
|
||||
|
||||
1. 工程问题，如果一个新技术不能带来本质的突破，那么其未来增长价值就不明显，公司的未来也不够清晰，狂热的投资注定引发泡沫。新能源技术目前带来的提升不是数倍的，因此前景不明确，无法说服大家一定去用这个产品。
|
||||
2. 时机问题，目前新能源领域技术并没有质的突破，现在进入注定面临技术储备不足的问题。
|
||||
3. 垄断问题，新能源技术是否能够垄断？新能源公司可能在故意隐瞒自己在市场中的渺小程度，其实相对于全球能源市场，新能源只是很小的子版块，整个行业总市值可能都不大。
|
||||
4. 人员问题。新能源是个技术问题，但现在融资需要 CEO 们西装革履的到处募集资金，这是严重的人员问题。
|
||||
5. 销售问题。人们对新能源领域、新能源汽车的接受程度有多大？是否足够便捷？
|
||||
6. 持久问题。随着中国在新能源市场的加入，导致美国新能源企业增长疲软，所以指责中国的声音很多。这是个危险的信号，如果成为垄断者需要以指责的方式进行，注定会失败。另外化石燃料随着液压破碎法的成熟，导致 2008 年天然气价格下降了 70% 多，新能源已不再是解决能源问题的唯一破局方式。
|
||||
7. 秘密问题。节省能源是一个政治正确的问题，大家都在呼吁要环保，那么这就证明环保项目一定有市场？不一定。
|
||||
|
||||
特斯拉的成功是因为解决了这 7 个问题，并且从实际的小领域切入，并且和政府以及其他企业达成了技术合作。这说明，在能源 2.0 市场中，企业面临的主要挑战是如何找到一个正确的小型市场。
|
||||
|
||||
### 创始人的悖论
|
||||
|
||||
这个章节，彼得蒂尔分析了各种名人或创业者的特质，内容非常丰富，由于篇幅限制就不展开了，而且由于笔者在这方面缺乏相应的阅历，很难原汁原味的还原出他对每个名人的评价，因此细节还是推荐阅读原文。
|
||||
|
||||
以下只能做简单的总结，只能理解到其中部分思想：
|
||||
|
||||
1. 伟人都拥有矛盾的两面性，企业需要极端的创始人，平庸的人往往很难成为好的创始人。
|
||||
2. 伟人的两面性与其成功路径存在相互塑造的过程，很难说是因为存在矛盾才导致了其成功，还是在成功的过程中塑造了其矛盾的性格。
|
||||
3. 伟人往往都会亲手终结自己的良好形象，除非英年早逝。
|
||||
|
||||
当然，这并不是说为了成功，我们必须成为这样的人，这个章节只是对创始人悖论这个现象的一种解读，可能这是一种自然现象，我们不需要模仿，只需要理解。
|
||||
|
||||
### 对未来的预期
|
||||
|
||||
哲学家尼克·博斯特罗姆描述了四种预测未来的理论：
|
||||
|
||||
1. 兴衰交替。由于历史总是呈现繁荣与衰败的交替，因此未来也很可能逃不出这个循环。
|
||||
2. 未来稳定发展。按照当今世界发展节奏，最后所有国家都进入发达国家行列，人民生活水平整体提高。
|
||||
3. 毁灭性衰落。由于地缘政治原因，未来不可避免会发生毁灭性冲突，人类文明可能呈断崖式下跌。
|
||||
4. 奇点。非常难以预测的加速发展，以至于发展到现在人类难以理解的高度。因为这个概念本身突出的就是 “发展到难以理解的高度”，因此试图去理解它的思考都反而会偏题，因此把它当作一种无法预测的未来吧。
|
||||
|
||||
笔者发现，现代大师人物写的书，最后都有对未来的预测，而且大家对未来的预测不同与书籍观点间的差异，往往都是很趋同的，这到底是英雄所见略同还是人类顶级大脑能到达的高度已经达到天花板？这是一个开放问题。
|
||||
|
||||
最后，保持独立思考是我们能重构世界的最佳方式。
|
||||
|
||||
## 4 总结
|
||||
|
||||
那到底什么是创新？巴菲特说过，商业最重要的是护城河，护城河不是什么产品质量、高素质员工、巨大的市场份额。真正的护城河是：**企业无形资产比如品牌、高客户转换成本、成本优势、网络效应**。Paypal 创新的找到了符合网络效应的业务场景：“网络货币”。
|
||||
|
||||
为什么 “网络货币” 拥有网络效应呢？所谓网络效应是指，每新增一个用户，就会对产品价值带来指数级提升。支付网络每增加一个人，不但你可以参与交易，还让交易网络变得更大，让更多交易成为可能，甚至成为全球通用货币，获得比国家货币更强的流通性，而这个质变只需要更多的用户加入即可，这就是它的网络效应。
|
||||
|
||||
《从 0 到 1》是一本创新思维的启蒙书，但想要深入理解这本书提供的概念，基本的经济学、商业知识是必不可少的，至少要理解到创新指的是为企业构筑护城河，而网络效应是 Paypal 的一个重要护城河。
|
||||
|
||||
类似拥有网络效应的还有 Uber 和 Airbnb，但他们创新思维不同，导致网络效应的大小也不同。Airbnb 的网络效应是全球的，因为场景天然是 “旅游时自有房屋出租”，每成交一对商家与客户，都可能是跨地区的，而且客户也有自己的房子，可能下次自己就会成为商家。而 Uber 业务场景天然是同城的叫车服务，因此无法形成全球的网络效应壁垒，这也是为什么 Uber 无法竞争过中国的滴滴，但 Airbnb 的全球市场地位无人能撼动。
|
||||
|
||||
商业领域远远不止于此，研究商业就像研究历史，每个公司都能给我们带来巨大启发。而商业最迷人的地方就在它的非必然性，就算你反复研究历史，熟读《从 0 到 1》这本书，他也无法给你带来必胜的商业操作路径。但这本书真正能带来的是正确而成功的信念，只要确定你的方向是正确的 “创新”，至少你可以正视失败，坦然开启下一段创业旅程，而说不定哪一次就成功了呢。
|
||||
|
||||
> 讨论地址是：[精读《从 0 到 1》 · Issue #219 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/219)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,262 @@
|
||||
## 1 引言
|
||||
|
||||
搭配了合适的设计模式的代码，才可拥有良好的可维护性，[The Benefits of Orthogonal React Components](https://dmitripavlutin.com/orthogonal-react-components/) 这篇文章就重点介绍了正交性原理。
|
||||
|
||||
所谓正交，即模块之间不会相互影响。想象一个音响的音量与换台按钮间如果不是正交关系，控制音量同时可能影响换台，这样的设备很难维护：
|
||||
|
||||
<img width=400 src="https://img.alicdn.com/tfs/TB1dczIpQL0gK0jSZFtXXXQCXXa-1000-993.png">
|
||||
|
||||
前端代码也一样，UI 与数据处理逻辑分离就是一种符合正交原则的设计，这样有利于长期代码质量维护。
|
||||
|
||||
## 2 概述
|
||||
|
||||
一个拥有良好正交性的 React App 会按照如下模块分离设计：
|
||||
|
||||
1. UI 元素(展示型组件)。
|
||||
2. 取数逻辑(fetch library, REST or GraphQL)。
|
||||
3. 全局状态管理(redux)。
|
||||
4. 持久化（local storage, cookies）。
|
||||
|
||||
文中通过两个例子说明。
|
||||
|
||||
### 让组件与取数逻辑正交
|
||||
|
||||
比如一个展示雇员列表组件 `<EmployeesPage>`:
|
||||
|
||||
```jsx
|
||||
import React, { useState } from "react";
|
||||
import axios from "axios";
|
||||
import EmployeesList from "./EmployeesList";
|
||||
|
||||
function EmployeesPage() {
|
||||
const [isFetching, setFetching] = useState(false);
|
||||
const [employees, setEmployees] = useState([]);
|
||||
|
||||
useEffect(function fetch() {
|
||||
(async function() {
|
||||
setFetching(true);
|
||||
const response = await axios.get("/employees");
|
||||
setEmployees(response.data);
|
||||
setFetching(false);
|
||||
})();
|
||||
}, []);
|
||||
|
||||
if (isFetching) {
|
||||
return <div>Fetching employees....</div>;
|
||||
}
|
||||
return <EmployeesList employees={employees} />;
|
||||
}
|
||||
```
|
||||
|
||||
这样设计看上去没问题，但其实违背了正交原则，因为 `EmployeesPage` 既负责渲染 UI 又关心取数逻辑。正交的写法如下：
|
||||
|
||||
```jsx
|
||||
import React, { Suspense } from "react";
|
||||
import EmployeesList from "./EmployeesList";
|
||||
|
||||
function EmployeesPage({ resource }) {
|
||||
return (
|
||||
<Suspense fallback={<h1>Fetching employees....</h1>}>
|
||||
<EmployeesFetch resource={resource} />
|
||||
</Suspense>
|
||||
);
|
||||
}
|
||||
|
||||
function EmployeesFetch({ resource }) {
|
||||
const employees = resource.employees.read();
|
||||
return <EmployeesList employees={employees} />;
|
||||
}
|
||||
```
|
||||
|
||||
**`Suspense` 将 loading 状态剥离到父级组件，因此子组件只需要关心如何用数据，不需关心如何取数据（以及 loading 态）。**
|
||||
|
||||
### 让组件与滚动监听正交
|
||||
|
||||
比如一个滚动到一定距离就出现 "jump to top" 的组件 `<ScrollToTop>`，可能会这么实现：
|
||||
|
||||
```jsx
|
||||
import React, { useState, useEffect } from "react";
|
||||
|
||||
const DISTANCE = 500;
|
||||
|
||||
function ScrollToTop() {
|
||||
const [crossed, setCrossed] = useState(false);
|
||||
|
||||
useEffect(function() {
|
||||
const handler = () => setCrossed(window.scrollY > DISTANCE);
|
||||
handler();
|
||||
window.addEventListener("scroll", handler);
|
||||
return () => window.removeEventListener("scroll", handler);
|
||||
}, []);
|
||||
|
||||
function onClick() {
|
||||
window.scrollTo({
|
||||
top: 0,
|
||||
behavior: "smooth"
|
||||
});
|
||||
}
|
||||
|
||||
if (!crossed) {
|
||||
return null;
|
||||
}
|
||||
return <button onClick={onClick}>Jump to top</button>;
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，在这个组件中，按钮与滚动状态判断逻辑混合在了一起。如果我们将 “滚动到一定距离就渲染 UI” 抽象成通用组件 `IfScrollCrossed` 呢？
|
||||
|
||||
```jsx
|
||||
import { useState, useEffect } from "react";
|
||||
|
||||
function useScrollDistance(distance) {
|
||||
const [crossed, setCrossed] = useState(false);
|
||||
|
||||
useEffect(
|
||||
function() {
|
||||
const handler = () => setCrossed(window.scrollY > distance);
|
||||
handler();
|
||||
window.addEventListener("scroll", handler);
|
||||
return () => window.removeEventListener("scroll", handler);
|
||||
},
|
||||
[distance]
|
||||
);
|
||||
|
||||
return crossed;
|
||||
}
|
||||
|
||||
function IfScrollCrossed({ children, distance }) {
|
||||
const isBottom = useScrollDistance(distance);
|
||||
return isBottom ? children : null;
|
||||
}
|
||||
```
|
||||
|
||||
有了 `IfScrollCrossed`，我们就能专注写 “点击按钮跳转到顶部” 这个 UI 组件了：
|
||||
|
||||
```jsx
|
||||
function onClick() {
|
||||
window.scrollTo({
|
||||
top: 0,
|
||||
behavior: "smooth"
|
||||
});
|
||||
}
|
||||
|
||||
function JumpToTop() {
|
||||
return <button onClick={onClick}>Jump to top</button>;
|
||||
}
|
||||
```
|
||||
|
||||
最后将他们拼装在一起：
|
||||
|
||||
```jsx
|
||||
import React from "react";
|
||||
|
||||
// ...
|
||||
|
||||
const DISTANCE = 500;
|
||||
|
||||
function MyComponent() {
|
||||
// ...
|
||||
return (
|
||||
<IfScrollCrossed distance={DISTANCE}>
|
||||
<JumpToTop />
|
||||
</IfScrollCrossed>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
这么做，我们的 `<JumpToTop>` 与 `<IfScrollCrossed>` 组件就是正交关系，而且逻辑更清晰。不仅如此，这样的抽象使 `<IfScrollCrossed>` 可以被其他场景复用：
|
||||
|
||||
```jsx
|
||||
import React from "react";
|
||||
|
||||
// ...
|
||||
|
||||
const DISTANCE_NEWSLETTER = 300;
|
||||
|
||||
function OtherComponent() {
|
||||
// ...
|
||||
return (
|
||||
<IfScrollCrossed distance={DISTANCE_NEWSLETTER}>
|
||||
<SubscribeToNewsletterForm />
|
||||
</IfScrollCrossed>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
### Main 组件
|
||||
|
||||
上面例子中，`<MyComponent>` 就是一个 Main 组件，Main 组件封装一些脏逻辑，即它要负责不同模块的组装，而这些模块之间不需要知道彼此的存在。
|
||||
|
||||
一个应用会存在多个 Main 组件，它们负责拼装各种作用域下的脏逻辑。
|
||||
|
||||
### 正交设计的好处
|
||||
|
||||
- **容易维护：** 正交组件逻辑相互隔离，不用担心连带影响，因此可以放心大胆的维护单个组件。
|
||||
- **易读：** 由于逻辑分离导致了抽象，因此每个模块做的事情都相对单一，很容易猜测一个组件做的事情。
|
||||
- **可测试：** 由于逻辑分离，可以采取逐个击破的思路进行单测。
|
||||
|
||||
### 权衡
|
||||
|
||||
如果不采用正交设计，因为模块之间的关联导致应用最终变得难以维护。但如果将正交设计应用到极致，可能会多处许多不必要的抽象，这些抽象的复用仅此一次，造成过度设计。
|
||||
|
||||
## 3 精读
|
||||
|
||||
正交设计一定程度可以理解为合理抽象，完全不抽象与过度抽象都是不可取的，因此列举了四块需要抽象的要点：UI 元素、取数逻辑、全局状态管理、持久化。
|
||||
|
||||
全局状态管理注入到组件，就是一种正交的抽象模式，即组件不用关心数据从哪来，而直接使用数据，而数据管理完全交由数据流层管理。
|
||||
|
||||
取数逻辑往往是可能被忽略的一环，无论是像原文中直接关心到 `fetch` 方法的 UI 组件，还是利用取数工具库关心了 `loading` 状态：
|
||||
|
||||
```jsx
|
||||
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>;
|
||||
}
|
||||
```
|
||||
|
||||
虽然将取数生命周期封装到自定义 hook `useSWR` 中，但 `error` 信息对 UI 组件来说就是一个脏数据：**这让这个 UI 组件不仅要渲染数据，还要担心取数是否会失败，或者是否在 loading 中。**
|
||||
|
||||
好在 Suspense 模式解决了这个问题：
|
||||
|
||||
```jsx
|
||||
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>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
这样 `<Profile>` 只要专注于做数据渲染，而不用担心 `useSWR('/api/user', fetcher, { suspense: true })` 这个取数过程发生了什么、是否取数失败、是否在 `loading` 中。因为取数状态由 `Suspense` 管理，而取数是否意外失败由 `ErrorBoundary` 管理。
|
||||
|
||||
合理的抽象使组件逻辑变得更简单，从而组件嵌套使用使不用担心额外影响。尤其在大型项目中，不要担心正交抽象会使本来就很多的模块数量再次膨胀，因为相比于维护 100 个相互影响，内部逻辑复杂的模块，维护 200 个职责清晰，相互隔离的模块也许会更轻松。
|
||||
|
||||
## 4 总结
|
||||
|
||||
从正交设计角度来看，`Hooks` 解决了状态管理与 UI 分离的问题，`Suspense` 解决了取数状态与 UI 分离的问题，`ErrorBoundary` 解决了异常与 UI 分离的问题。
|
||||
|
||||
在你看来，React 还有哪些逻辑需要与 UI 分离？分别使用哪些方法呢？欢迎留言。
|
||||
|
||||
> 讨论地址是：[精读《正交的 React 组件》 · Issue #221 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/221)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,207 @@
|
||||
## 1 引言
|
||||
|
||||
[尤雨溪](https://github.com/yyx990803) 在 2019 JSConf 的分享 [Seeking the Balance in Framework Design](https://www.youtube.com/watch?v=ANtSWq-zI0s) 十分精彩，道出了如何进行合理的前端框架设计与框架选型。
|
||||
|
||||
正如所说，框架对比不能只停留在 Star 数量、Npm 下载量、Stackoverflow 问题量这些简单的数据对比，而要深入到技术细节进行比较。比较框架有多种不同维度，这次分享就从服务范围、渲染机制、状态机制这三个维度进行对比。
|
||||
|
||||
## 2 概述
|
||||
|
||||
这次分享的精彩之处在于不偏不倚的站在客观立场分析了框架各维度好的一面与坏的一面，从中我们不仅能学习到一些框架知识，还能培养思辨能力。
|
||||
|
||||
### 服务范围
|
||||
|
||||
服务范围是个比较难翻译的单词，在原 PPT 中用了 “Scope” 这个单词表示，可以理解为 “作用域、框架的承诺功能范围、服务配套齐全程度”。比如提供的是一个工具库还是整体框架，插件管理是集中式还是依赖生态。
|
||||
|
||||
React 是典型的小服务范围框架，核心包只实现了基本功能，而其他生态基本靠社区拓展；Angular 是典型大服务范围框架，官方对所有业务场景都做了最佳实践能力覆盖；Vue 处在中间区域，通过功能分层，既拥有小服务范围的能力，又可以搭配官方插件实现更多场景化能力。
|
||||
|
||||
#### 小服务范围优势
|
||||
|
||||
**概念少，易上手**
|
||||
|
||||
小的服务范围代表了小的学习成本，因为暴露的基本能力较少，概念也会比较少，对新人上手比较友好。
|
||||
|
||||
**生态繁荣，百花齐放**
|
||||
|
||||
由于很多功能没有被官方实现，社区就有机会填补这些空白，因此会冒出许多第三方库，而且一旦做得好，就有机会成为 “事实标准”，因此开发者会更加积极参与到社区开发，自己做的框架 “上升空间” 也非常大。
|
||||
|
||||
同时，社区的力量会导致多元化，因此整体生态完整度与创新性都会非常亮眼，而且具有持续迭代的能力。
|
||||
|
||||
**核心维护成本低**
|
||||
|
||||
官方维护的核心代码较少，因此维护成本大大降低，而且官方可以将精力放在更多核心能力增强上，比如 Suspense 等，而不是将精力消耗在生态插件上。
|
||||
|
||||
#### 小服务范围的劣势
|
||||
|
||||
**复杂场景要引入新概念**
|
||||
|
||||
复杂场景无法支持时，就要引入新的概念解决，这导致后续技术选型可能产生分歧，并带来持续的新概念理解成本。
|
||||
|
||||
**非官方的开发模式逐渐产生**
|
||||
|
||||
随着时间的流逝，会逐渐涌出一些新的设计模式，成为当下几乎是必不可少的方案，但却不会出现在官方文档中，造成选型时的疑惑。Redux 就是一个例子。
|
||||
|
||||
**生态变化快，碎片化且持续流失**
|
||||
|
||||
非官方的生态也意味着不稳定，而且缺乏统一的管理，碎片化的模块之间可能经常出现不兼容的问题。
|
||||
|
||||
而且任何模块都可能被时代无情的淘汰，就像 Flux 到 Redux 再到 Hooks，带来额外的迁移成本和认知成本。谁也不希望自己的项目架构 “变得过时”，或者随时面临被新架构取代的风险，但第三方社区几乎一定代表未来会出现一种模式取代现有模式，只是时间早晚而已。
|
||||
|
||||
#### 大服务范围的优势
|
||||
|
||||
**大部分业务场景都被内置解决**
|
||||
|
||||
减少不必要的技术方案调研与纷争，大服务范围的框架内置的方案就能解决几乎 100% 业务问题，团队再也不会为通用架构问题烦恼了。
|
||||
|
||||
**生态稳定、连贯**
|
||||
|
||||
稳定是指，官方维护作为背书，几乎不会存在一些生态包突然不维护、与已有版本不兼容、被植入恶意程序等等意外情况。
|
||||
|
||||
连贯是指，官方会统一考虑一个改动在所有生态插件造成的影响，并以一个最合理的思路做整体改造，生态包无论是接口还是兼容性都不需要担心，设计思路也会一脉相承。
|
||||
|
||||
#### 大服务范围的劣势
|
||||
|
||||
**前期上手成本高**
|
||||
|
||||
全家桶的概念导致上手难度偏高，因为必须理解所有内置概念后才能开始项目。
|
||||
|
||||
**如果内置模块无法满足业务，会觉得有些死板**
|
||||
|
||||
一旦发生内置功能无法满足业务的场景，就很难拓展了，因为 all in one 的思路本质上就是排斥自定义拓展的，这点从 [angular-cli](https://github.com/angular/angular-cli) 就能看出来。
|
||||
|
||||
之所以觉得死板，是因为这种情况没办法用优雅的方式解决，只能在现有约束的框架内通过某些 “Hack” 方式解决，自然会有种死板的感觉。
|
||||
|
||||
#### 中等服务范围的优势
|
||||
|
||||
**分层设计，允许新特性渐进加入**
|
||||
|
||||
Vue 通过分层设计做到了折中，即官方还是会维护生态，只不过生态不是必须的，可以按需使用。这样做的好处是兼顾了一些优势。
|
||||
|
||||
**低学习门槛**
|
||||
|
||||
与小服务范围框架一样，对于核心包来说学习成本都比较低。
|
||||
|
||||
**依然有最佳实践解决所有业务问题**
|
||||
|
||||
和大服务范围框架一样，拥有全套官方最佳实践，但不内置，不强求一定要使用，因此你可以按需使用。
|
||||
|
||||
#### 中等服务范围的劣势
|
||||
|
||||
**维护成本高**
|
||||
|
||||
和大服务范围框架一样，虽然生态不强求，但毕竟官方还是要持续维护的，因此维护成本高的问题依然存在。
|
||||
|
||||
**生态多样性不高**
|
||||
|
||||
虽然生态是按需的，但毕竟中等服务范围的框架官方会实现一套标准生态插件，这会极大影响社区生态的发展空间，导致 “非官方插件没人愿意做”，因此生态多样性会差一些。
|
||||
|
||||
### 渲染机制
|
||||
|
||||
渲染机制区别主要在 JSX vs Template 之间，不同的表达方式之间还是存在一些很本质的区别，然而正如一开始所说，无法一言蔽之，必须从多个角度拆解的看。
|
||||
|
||||
#### JSX 的优势
|
||||
|
||||
**纯 JS 表达 UI**
|
||||
|
||||
单这一点就非常重要了，满足了 All In Js 的幻想。毕竟 Html、Css 相比 Js 来说，模块化能力和灵活性都很弱，将其都收敛到 Js 不仅表达方式更统一，更重要的是都获得了与 Js 一样的模块化、灵活性、Typescript 支持等能力。
|
||||
|
||||
**视图即数据**
|
||||
|
||||
将视图看作一种数据，让针对视图的逻辑测试成为可能。
|
||||
|
||||
同时也将视图概念泛化了，因为数据是平台无关的，一份描述视图的 DSL 可以运行在任何平台。
|
||||
|
||||
#### JSX 的劣势
|
||||
|
||||
**开销大**
|
||||
|
||||
页面节点越多，Diff 开销就越大。
|
||||
|
||||
**动态渲染很难性能优化**
|
||||
|
||||
由于所有 DOM 节点都是动态生成，因此无法根据初始状态结构进行安全的优化。相比之下，Template 模式可以确定哪部分属于变量，哪部分是固定的，对固定部分的 Diff 检测都可以跳过。
|
||||
|
||||
**动态调度虽然改善了性能，但依赖更重的运行时**
|
||||
|
||||
React ConcurrentMode 是一个调度优化器，但实现的逻辑也比较复杂，加重了运行时负担。
|
||||
|
||||
#### Template 的优势
|
||||
|
||||
**原生性能**
|
||||
|
||||
由于 Template 对节点进行直接渲染，因此与原生性能一致。
|
||||
|
||||
**Runtime 更小**
|
||||
|
||||
由于不需要额外优化，运行时代码会小很多。
|
||||
|
||||
#### Template 的劣势
|
||||
|
||||
**被 Template 语法约束，且无法拓展**
|
||||
|
||||
对于 Template 不支持的，只能选择接受，因为除了框架自己，没有人能拓展 Template 的特性。当遇到一些非常动态场景，但 Template 不支持的情况，只能选择接受，并用比较 Hack 的方式绕过解决，除此之外别无他法。
|
||||
|
||||
**模版冗长**
|
||||
|
||||
JSX 可以利用循环语句或者变量赋值进行模版区块的复用，但 Template 模式每次新模版都要一行一行的打出来，这种冗长的开发体验不太友好。
|
||||
|
||||
**运行时解析开销或者依赖编译期逻辑**
|
||||
|
||||
要么通过编译器预先生成 AST，要么运行时动态将 Template 解析成 AST，无论哪种方案都有额外的开销，一种是工程依赖的开销，一种是运行时动态解析的性能开销。
|
||||
|
||||
#### VDom + Template 的特色
|
||||
|
||||
Vue 在 Template 基础上支持了虚拟 DOM，因此兼具两者特色。
|
||||
|
||||
性能上，在编译时就进行 AST 解析，减少了运行时解析开销。
|
||||
|
||||
功能上，支持模版与 JSX 两种语法。
|
||||
|
||||
### 状态机制
|
||||
|
||||
状态机制 [尤雨溪](https://github.com/yyx990803) 在 JSConf 提到要单独拆出来讲，因为内容较多，时间可能不够，本次精读也限于篇幅原因略过：
|
||||
|
||||
- Mutable vs Immutable。
|
||||
- 依赖追踪 vs 脏检测。
|
||||
- 响应式 vs 模拟响应式。
|
||||
|
||||
显然，状态机制方案更是仁者见仁智者见智的事情，同样得从多个维度进行独立分析，并根据实际业务场景具体选择。
|
||||
|
||||
最后，意识到没有一个绝对均衡的框架设计方案，因为在工程领域，没有最好只有更好。
|
||||
|
||||
## 3 精读
|
||||
|
||||
我们再延伸谈一谈为什么框架设计要寻找平衡点。
|
||||
|
||||
**框架设计没有银弹**
|
||||
|
||||
与数学公式不同，框架设计甚至整个工程技术设计都没有所谓的真理，所谓条条大路通罗马，实现同一个技术目标的众多方案之间也许就是平行关系，可以根据不同维度列出一二三的对比，但无法得出一个总的结论，孰优孰劣。
|
||||
|
||||
**使用场景不同**
|
||||
|
||||
不同使用场景决定了对框架诉求的不同。
|
||||
|
||||
比如开发非常定制、炫酷的可视化大屏，那么前端开发框架基本也用不上，因为关注点不会聚焦在项目路由、UI 描述、甚至是数据流，而是聚焦在性能、图形渲染等问题。解决这些领域的框架可能是 虚幻 4、Unity 等游戏引擎，但普通的前端开发框架绝不会涉足这种领域，框架一定要确定自己功能范围。
|
||||
|
||||
即便仅局限在 Web 领域，也需要考虑是否要支持非 Web 场景，那么将 HTML 抽象成一个通用 DSL 就可能是一种选择，但非 Web 领域毕竟不是主打业务领域，在这种业务场景周边生态维护可能就比较少，这也是需要取舍的地方。
|
||||
|
||||
**使用的人不同**
|
||||
|
||||
不同团队对框架的要求也不同。
|
||||
|
||||
刚起步的小团队可能更需要保姆式的框架，因为这样最节省人力成本。对于规模较大的团队，希望对框架拥有较大定制能力时，小服务范围的框架可能更受青睐。当然框架作者可以像 Vue 一样做出渐进式官方能力增强方案，以此满足不同需求的用户，但毕竟也不能将生态完全交给社区，还是要做取舍。
|
||||
|
||||
所以当遇到更新更酷的框架时，需要冷静思考的不只是这个框架带来的收益与花费的迁移成本哪个更高，以及团队能否接受这套框架的开发习惯，更需要思考的是这个框架自身做了哪些权衡，如果这些权衡与 React、Vue、Angular 类似，那么仅仅变化了语法或者语言的改动其实意义不大，此时需要慎重考虑。
|
||||
|
||||
## 4 总结
|
||||
|
||||
这次没有提到的状态机制对比，你能分别列举出优缺点吗？欢迎留言。
|
||||
|
||||
> 讨论地址是：[精读《寻找框架设计的平衡点》 · Issue #223 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/223)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,111 @@
|
||||
## 1 引言
|
||||
|
||||
当下互联网行业里面最流行的就是 ABC:
|
||||
|
||||
> A: AI 人工智能 B: BIG DATA C: CLOUD
|
||||
|
||||
而阿里经济体中的 ABC，其中的 BIG DATA，即是我们 DT https://dt.alibaba.com/ ，我们用大数据赋能商业，创造价值。
|
||||
|
||||
而我们说数据中台，其实阿里提出的中台只有两个：业务中台与数据中台。业务中台的目的是让业务能够快速落地，数据中台的目的是完成数据的采集、建设、管理、使用这四个环节，让数据从生产到使用过程变得丝般顺滑，不仅不让数据资产成为累赘，还会最大限度发挥出数据潜藏的价值。
|
||||
|
||||
笔者所在的就是数据中台的大前端团队，既为阿里经济体提供数据服务，又着力为上云企业打造属于自己的数据中台，处在前端技术、商业模式、产品设计的最前沿，且听我慢慢道来。
|
||||
|
||||
## 2 精读
|
||||
|
||||
### 全链路数据能力
|
||||
|
||||
从能力上看，数据中台处理数据的方方面面，从数据产生开始就进行追踪，不仅打通了数据采集、存储、处理、查询、消费的全链路，还用以下几种方式赋能业务：研发数据管理平台并监控数据质量，研发生意参谋等数据分析产品直接服务大、中、小商家，提供统一数据服务标准化数据使用流程，将数据分析的算法能力服务化，将支撑内部的数据服务上云搭建客户自己的数据中台，研发 BI 平台完成数据决策的最后一环。
|
||||
|
||||
### 全链路数据技术
|
||||
|
||||
从技术架构上看，从底层的数据采集技术开始，逐步向上建设了数据计算与管理能力、数据服务、数据平台、数据应用与数据安全。
|
||||
|
||||
从使用者角度来看，现在的公司对数据的诉求可以概括为以下几点：
|
||||
|
||||
1. 数据从哪来，如何完全数字化：对应全链路数据采集服务。
|
||||
2. 如何得到想要的数据：数据计算、建模与管理服务。
|
||||
3. 如何使用数据：统一数据服务平台。
|
||||
4. 如何利用数据做商业决策：BI 平台。
|
||||
5. 如何保障数据安全：数据安全服务。
|
||||
|
||||
对阿里而言，还会额外考虑下面几点：
|
||||
|
||||
1. 如何让数据服务横向支撑所有业务线：数据服务平台化，数据智能化服务平台与 BI 平台。
|
||||
2. 如何让数据服务普惠到每一个企业：数据服务全面上云。
|
||||
3. 如何让数据服务更有价值：打通阿里经济体的数据体系，让数据相互产生化学反应。
|
||||
|
||||
当然，挑战性也非常大，首先是数据壁垒的挑战，要说服其他团队将数据交给你管理绝非易事。其次是价值挑战，如何证明数据中台存在的价值，并做到肉眼可见的业务增值。最后是技术挑战，对前端来说，几十款数据产品的搭建、几十万张数据报表的搭建，需要一个足够好用的数据产品搭建平台来支持；数据分析产品的下一代探索式分析也对 BI 引擎提出了新的要求；数据可视化远比普通可视化复杂，不仅要考虑大数据下的性能与可读性，还要理解商业，做出能体现数据分析价值的图表。
|
||||
|
||||
不论是数据搭建还是数据可视化，都是前端垂直领域的另一条好赛道，不仅有沉甸甸的业务价值，还有全新数据领域的的前端技术挑战，而且随着数据中台影响力的持续扩大，我们的前端技术也会带来业界越来越大的影响力。
|
||||
|
||||
### 如何建设和管理数据
|
||||
|
||||
想要数据用的好，首先要管的好，在大数据时代，企业必须建立一套自己的标准数仓系统对数据的采集、运维调度做全链路管理，让大数据变成好数据，让好数据可以发挥价值。
|
||||
|
||||
|
||||
|
||||
> Dataphin 数仓建设平台。
|
||||
|
||||
数仓的建设需要从物理空间与逻辑空间，也就是底层的表开始整理，通过对数据的采集、清洗、结构化，产出一套规范的数据定义。
|
||||
|
||||
所谓规范的数据定义即口径、算法、命名均一致的数据规范，降低数据二义性，提升数据查找效率与准确性。之后对数据建模，建模即是对数据的进一步抽象，可能是抽象为一个 Cube 模型，这样在顶层认知上，所有数据都是不同维度的 Cube，方便统一理解。
|
||||
|
||||
最后通过对数据进行在线的、离线的调度计算，产出数据资产。
|
||||
|
||||
### 如何看数据
|
||||
|
||||
或导出一个 Excel 文件仔细品味，或如双十一媒体大屏般夺目，或如股票操盘手般紧盯着屏幕，或随时随地的手机浏览。在哪看，怎么看，看什么，决定着同一份数据可带来不同的效果，产生不同的价值。
|
||||
|
||||
稳：双十一大屏，零点起得来，24 点收得住，每个彩蛋的出现，每个数字的跳动，如丝般顺滑，这不是播放 VCR，每一帧画面都是真实的数据展现。容：即是生意参谋用户的浏览器兼容，又是多端用户的兼容，也是 BI 分析结果的数据大容量。有容乃大，方显前端功底。
|
||||
|
||||
**“如何看数据” 这恰是做为数据前端人的使命和责任。** 不同的人，不同的端，不同的需求，这恰是给数据前端的挑战。而让用户透过数据创造价值，也正是数据前端人的价值。
|
||||
|
||||
### 如何分析数据
|
||||
|
||||
大数据浪潮之下，必然会诞生各式各样的数据产品，产品化的方式可以降低数据应用的门槛。我们希望人人都能成为数据分析师，于是 BI （商业智能）产品应运而生，作为大数据行业中的一个重要领域，BI 产品用大数据的方式解决了企业的业务分析需求，支撑企业进行数字化转型，从经验驱动决策转变为数据驱动决策，进而给企业带来超额收益。
|
||||
|
||||
|
||||
|
||||
> QuickBI 数据分析工具。
|
||||
|
||||
**人人都是数据分析师的情况在不断增强。**
|
||||
|
||||
根据 Gartner 对 2020 年 BI 产品发展趋势预测：
|
||||
|
||||
1. 到 2020 年，为用户提供对内部和外部数据策划目录的访问权限的组织将从分析投资中获得两倍的业务价值。
|
||||
2. 到 2020 年，业务部门的数据和分析专家数量的增速将是 IT 部门专家的 3 倍，这会迫使企业重新考虑其组织模式和技能。
|
||||
3. 到 2021 年，自然语言处理和会话分析这两个功能，会在新用户、特别是一线工作人员中，将分析和商业智能产品的使用率从 35% 提升到 50% 以上。
|
||||
|
||||
**快速增涨的市场规模。**
|
||||
|
||||
根据中国电子信息产业发展研究院发布的《中国大数据产业发展水平评估报告》，预计 2019 年我国大数据核心产业规模突破 5700 亿元，未来 2-3 年的市场规模的增长率仍将保持 35% 左右。未来切入这部分应用环节，BI 商业智能的潜在市场规模将在数百亿的市场空间。
|
||||
|
||||
**大数据与前端。**
|
||||
|
||||
前端的职业发展除了提升自己的技能技术储备之外，选择合适行业方向和研究领域也尤为重要。如果用路和车的关系来比喻的话，把前端技能比作车的话，各个行业都是路，有的路是乡间小路，有的路是城乡公路，而大数据行业当之无愧是行业中的上高速公路，路况更好，路面更宽，如果你拥有一辆好车，为什么不来高速公路上飞驰呢？
|
||||
|
||||
大数据下的前端面临哪些挑战？以 BI 为例，BI 领域的四大方向：数据集、渲染引擎、数据模型与可视化都有许多可以做深的技术点，每一块都需要深入沉淀几年技术经验才能做好，需要大量优秀人才通力协作才有可能做好。你也可以阅读 [精读《前端与 BI》](https://github.com/dt-fe/weekly/blob/v2/121.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E4%B8%8E%20BI%E3%80%8B.md) 了解更多 BI 相关知识。
|
||||
|
||||
### 我们是数据中台大前端
|
||||
|
||||
> “ 前端不是因为我们用 JavaScript，而是因为我们站在业务最前端，解决业务端的问题，所以我们是前端 ”。
|
||||
|
||||
BI 分析产品、做数据可视化、做产品搭建 .. 我们早已经跳出了“前端”的传统概念范畴。我们做大数据表格优化、 Web Excel、 SQL 编辑器、智能可视化。在数据中台，我们有着天然的复杂业务场景和海量数据优势，迫使你向自己提出更大的挑战来解决业务上的问题。如果你热爱挑战、热爱技术，请加入我们吧。
|
||||
|
||||
**在这里，你可以愉快的使用 React、TypesScript 写业务代码，尝试最新、最炫酷的 React Hooks 新特性，我们团队一直走在前端技术路线的最前沿，渴求技术创新。** 你也不需要担心伙伴的代码风格问题，因为我们有着严格的代码规；你不必担心每个人的代码都是一座孤岛，因为我们会对每一行代码做严格的 review；你不必担心你的成长空间，我们有定期的技术分享、团队内小竞赛，还有足够复杂的业务场景支撑；你也不必担心你会因工作日渐消瘦，下午茶和海量小零食等你来！
|
||||
|
||||
## 4 总结
|
||||
|
||||
**大数据前端人才缺口在 100 人以上，由于业务增长非常非常迅猛，春节前条件放宽、特批急召！**
|
||||
|
||||
如果你对我们感兴趣，请立刻把简历发送到邮箱 **ziyi.hzy@alibaba-inc.com** 吧！绝无仅有的好机会，响应速度绝对超乎你的想象！
|
||||
|
||||
> 讨论地址是：[精读《我在阿里数据中台大前端》 · Issue #224 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/224)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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