Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 ascoders
|
304dc5fc36 | ||
|
ascoders
|
819b6d7452 | ||
|
ascoders
|
b066c8a5d7 | ||
|
ascoders
|
80fb60c6fb | ||
|
ascoders
|
6a2031899d | ||
|
ascoders
|
aedcc2fd56 | ||
|
ascoders
|
757eb403ac | ||
|
ascoders
|
87c2745395 | ||
|
ascoders
|
0d3d8ef54c |
@@ -6,8 +6,12 @@
|
||||
|
||||
```jsx
|
||||
class Parent extends React.PureComponent {
|
||||
state = {
|
||||
text: "text",
|
||||
};
|
||||
|
||||
render() {
|
||||
return <Child style={{ color: "red" }} />;
|
||||
return <Child setText={(text) => this.setState({ text })} />;
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -15,18 +19,16 @@ class Parent extends React.PureComponent {
|
||||
子组件是这么写的：
|
||||
|
||||
```jsx
|
||||
const Child = ({ style }) => {
|
||||
const [localStyle, setLocalStyle] = useState();
|
||||
|
||||
const Child = ({ setText }) => {
|
||||
useEffect(() => {
|
||||
setLocalStyle(style);
|
||||
}, [style]);
|
||||
setText("ok");
|
||||
}, [setText]);
|
||||
|
||||
return null;
|
||||
};
|
||||
```
|
||||
|
||||
那么恭喜你，写出了一个最简单的死循环。这个场景里，我们本意是利用 `useEffect` 将 `props.style` 同步到本地状态 `localStyle` 中，但执行 `setLocalStyle` 会导致当前组件重渲染，由于父级 `style={{ color: "red" }}` 的写法，每次重渲染拿到的 `props.style` 引用都会变化，因此再次触发了 `useEffect` 回调执行，进而再次执行到 `setLocalStyle` 触发死循环。
|
||||
那么恭喜你，写出了一个最简单的死循环。这个场景里，我们本意是利用 `useEffect` 调用 `props.setText` 更新父组件的 `text`，但执行 `props.setText` 会导致父组件重渲染，由于父级 `setText={(text) => this.setState({ text })}` 的写法，每次重渲染拿到的 `props.setText` 引用都会变化，因此再次触发了 `useEffect` 回调执行，进而触发死循环。
|
||||
|
||||
仅仅打印出值是看不出变化的，引用的改变很隐蔽，为了判断是否变化还得存储上一次的值做比较，非常麻烦，use-what-changed 就是为了解决这个麻烦的。
|
||||
|
||||
|
||||
@@ -0,0 +1,272 @@
|
||||
## 1 引言
|
||||
|
||||
[IntersectionObserver](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API) 可以轻松判断元素是否可见，在之前的 [精读《用 React 做按需渲染》](https://github.com/dt-fe/weekly/blob/v2/154.%20%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%94%A8%20React%20%E5%81%9A%E6%8C%89%E9%9C%80%E6%B8%B2%E6%9F%93%E3%80%8B.md) 中介绍了原生 API 的方法，这次刚好看到其 React 封装版本 [react-intersection-observer](https://github.com/thebuilder/react-intersection-observer)，让我们看一看 React 封装思路。
|
||||
|
||||
## 2 简介
|
||||
|
||||
[react-intersection-observer](https://github.com/thebuilder/react-intersection-observer) 提供了 Hook `useInView` 判断元素是否在可视区域内，API 如下：
|
||||
|
||||
```jsx
|
||||
import React from "react";
|
||||
import { useInView } from "react-intersection-observer";
|
||||
|
||||
const Component = () => {
|
||||
const [ref, inView] = useInView();
|
||||
|
||||
return (
|
||||
<div ref={ref}>
|
||||
<h2>{`Header inside viewport ${inView}.`}</h2>
|
||||
</div>
|
||||
);
|
||||
};
|
||||
```
|
||||
|
||||
由于判断元素是否可见是基于 dom 的，所以必须将 `ref` 回调函数传递给 **代表元素轮廓的 DOM 元素**，上面的例子中，我们将 `ref` 传递给了最外层 DIV。
|
||||
|
||||
`useInView` 还支持下列参数：
|
||||
|
||||
- `root`：检测是否可见基于的视窗元素，默认是整个浏览器 viewport。
|
||||
- `rootMargin`：root 边距，可以在检测时提前或者推迟固定像素判断。
|
||||
- `threshold`：是否可见的阈值，范围 0 ～ 1，0 表示任意可见即为可见，1 表示完全可见即为可见。
|
||||
- `triggerOnce`：是否仅触发一次。
|
||||
|
||||
## 3 精读
|
||||
|
||||
首先从入口函数 `useInView` 开始解读，这是一个 Hook，利用 `ref` 存储上一次 DOM 实例，`state` 则存储 `inView` 元素是否可见的 boolean 值：
|
||||
|
||||
```jsx
|
||||
export function useInView(
|
||||
options: IntersectionOptions = {},
|
||||
): InViewHookResponse {
|
||||
const ref = React.useRef<Element>()
|
||||
const [state, setState] = React.useState<State>(initialState)
|
||||
|
||||
// 中间部分..
|
||||
|
||||
return [setRef, state.inView, state.entry]
|
||||
}
|
||||
```
|
||||
|
||||
当组件 ref 被赋值时会调用 `setRef`，回调 `node` 是新的 DOM 节点，因此先 `unobserve(ref.current)` 取消旧节点的监听，再 `observe(node)` 对新节点进行监听，最后 `ref.current = node` 更新旧节点：
|
||||
|
||||
```jsx
|
||||
// 中间部分 1
|
||||
const setRef = React.useCallback(
|
||||
(node) => {
|
||||
if (ref.current) {
|
||||
unobserve(ref.current);
|
||||
}
|
||||
|
||||
if (node) {
|
||||
observe(
|
||||
node,
|
||||
(inView, intersection) => {
|
||||
setState({ inView, entry: intersection });
|
||||
|
||||
if (inView && options.triggerOnce) {
|
||||
// If it should only trigger once, unobserve the element after it's inView
|
||||
unobserve(node);
|
||||
}
|
||||
},
|
||||
options
|
||||
);
|
||||
}
|
||||
|
||||
// Store a reference to the node, so we can unobserve it later
|
||||
ref.current = node;
|
||||
},
|
||||
[options.threshold, options.root, options.rootMargin, options.triggerOnce]
|
||||
);
|
||||
```
|
||||
|
||||
另一段是，当 `ref` 不存在时会清空 `inView` 状态，毕竟当不存在监听对象时，inView 值只有重设为默认 false 才合理：
|
||||
|
||||
```jsx
|
||||
// 中间部分 2
|
||||
useEffect(() => {
|
||||
if (!ref.current && state !== initialState && !options.triggerOnce) {
|
||||
// If we don't have a ref, then reset the state (unless the hook is set to only `triggerOnce`)
|
||||
// This ensures we correctly reflect the current state - If you aren't observing anything, then nothing is inView
|
||||
setState(initialState);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
这就是入口文件的逻辑，我们可以看到还有两个重要的函数 `observe` 与 `unobserve`，这两个函数的实现在 [intersection.ts](https://github.com/thebuilder/react-intersection-observer/blob/master/src/intersection.ts) 文件中，这个文件有三个核心函数：`observe`、`unobserve`、`onChange`。
|
||||
|
||||
- `observe`：监听 element 是否在可视区域。
|
||||
- `unobserve`：取消监听。
|
||||
- `onChange`：处理 `observe` 变化的回调。
|
||||
|
||||
先看 `observe`，对于同一个 root 下的监听会做合并操作，因此需要生成 `observerId` 作为唯一标识，这个标识由 `getRootId`、`rootMargin`、`threshold` 共同决定。
|
||||
|
||||
对于同一个 root 的监听下，拿到 `new IntersectionObserver()` 创建的 `observerInstance` 实例，调用 `observerInstance.observe` 进行监听。这里存储了两个 Map - `OBSERVER_MAP` 与 `INSTANCE_MAP`，前者是保证同一 root 下 `IntersectionObserver` 实例唯一，后者存储了组件 `inView` 以及回调等信息，在 `onChange` 函数使用：
|
||||
|
||||
```jsx
|
||||
export function observe(
|
||||
element: Element,
|
||||
callback: ObserverInstanceCallback,
|
||||
options: IntersectionObserverInit = {}
|
||||
) {
|
||||
// IntersectionObserver needs a threshold to trigger, so set it to 0 if it's not defined.
|
||||
// Modify the options object, since it's used in the onChange handler.
|
||||
if (!options.threshold) options.threshold = 0;
|
||||
const { root, rootMargin, threshold } = options;
|
||||
// Validate that the element is not being used in another <Observer />
|
||||
invariant(
|
||||
!INSTANCE_MAP.has(element),
|
||||
"react-intersection-observer: Trying to observe %s, but it's already being observed by another instance.\nMake sure the `ref` is only used by a single <Observer /> instance.\n\n%s"
|
||||
);
|
||||
/* istanbul ignore if */
|
||||
if (!element) return;
|
||||
// Create a unique ID for this observer instance, based on the root, root margin and threshold.
|
||||
// An observer with the same options can be reused, so lets use this fact
|
||||
let observerId: string =
|
||||
getRootId(root) +
|
||||
(rootMargin
|
||||
? `${threshold.toString()}_${rootMargin}`
|
||||
: threshold.toString());
|
||||
|
||||
let observerInstance = OBSERVER_MAP.get(observerId);
|
||||
if (!observerInstance) {
|
||||
observerInstance = new IntersectionObserver(onChange, options);
|
||||
/* istanbul ignore else */
|
||||
if (observerId) OBSERVER_MAP.set(observerId, observerInstance);
|
||||
}
|
||||
|
||||
const instance: ObserverInstance = {
|
||||
callback,
|
||||
element,
|
||||
inView: false,
|
||||
observerId,
|
||||
observer: observerInstance,
|
||||
// Make sure we have the thresholds value. It's undefined on a browser like Chrome 51.
|
||||
thresholds:
|
||||
observerInstance.thresholds ||
|
||||
(Array.isArray(threshold) ? threshold : [threshold]),
|
||||
};
|
||||
|
||||
INSTANCE_MAP.set(element, instance);
|
||||
observerInstance.observe(element);
|
||||
|
||||
return instance;
|
||||
}
|
||||
```
|
||||
|
||||
对于 `onChange` 函数，因为采用了多元素监听，所以需要遍历 `changes` 数组，并判断 `intersectionRatio` 超过阈值判定为 `inView` 状态，通过 `INSTANCE_MAP` 拿到对应实例，修改其 `inView` 状态并执行 `callback`。
|
||||
|
||||
这个 `callback` 就对应了 `useInView` Hook 中 `observe` 的第二个参数回调：
|
||||
|
||||
```jsx
|
||||
function onChange(changes: IntersectionObserverEntry[]) {
|
||||
changes.forEach((intersection) => {
|
||||
const { isIntersecting, intersectionRatio, target } = intersection;
|
||||
const instance = INSTANCE_MAP.get(target);
|
||||
|
||||
// Firefox can report a negative intersectionRatio when scrolling.
|
||||
/* istanbul ignore else */
|
||||
if (instance && intersectionRatio >= 0) {
|
||||
// If threshold is an array, check if any of them intersects. This just triggers the onChange event multiple times.
|
||||
let inView = instance.thresholds.some((threshold) => {
|
||||
return instance.inView
|
||||
? intersectionRatio > threshold
|
||||
: intersectionRatio >= threshold;
|
||||
});
|
||||
|
||||
if (isIntersecting !== undefined) {
|
||||
// If isIntersecting is defined, ensure that the element is actually intersecting.
|
||||
// Otherwise it reports a threshold of 0
|
||||
inView = inView && isIntersecting;
|
||||
}
|
||||
|
||||
instance.inView = inView;
|
||||
instance.callback(inView, intersection);
|
||||
}
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
最后是 `unobserve` 取消监听的实现，在 `useInView` `setRef` 灌入新 Node 节点时，会调用 `unobserve` 对旧节点取消监听。
|
||||
|
||||
首先利用 `INSTANCE_MAP` 找到实例，调用 `observer.unobserve(element)` 销毁监听。最后销毁不必要的 `INSTANCE_MAP` 与 `ROOT_IDS` 存储。
|
||||
|
||||
```jsx
|
||||
export function unobserve(element: Element | null) {
|
||||
if (!element) return;
|
||||
const instance = INSTANCE_MAP.get(element);
|
||||
|
||||
if (instance) {
|
||||
const { observerId, observer } = instance;
|
||||
const { root } = observer;
|
||||
|
||||
observer.unobserve(element);
|
||||
|
||||
// Check if we are still observing any elements with the same threshold.
|
||||
let itemsLeft = false;
|
||||
// Check if we still have observers configured with the same root.
|
||||
let rootObserved = false;
|
||||
/* istanbul ignore else */
|
||||
if (observerId) {
|
||||
INSTANCE_MAP.forEach((item, key) => {
|
||||
if (key !== element) {
|
||||
if (item.observerId === observerId) {
|
||||
itemsLeft = true;
|
||||
rootObserved = true;
|
||||
}
|
||||
if (item.observer.root === root) {
|
||||
rootObserved = true;
|
||||
}
|
||||
}
|
||||
});
|
||||
}
|
||||
if (!rootObserved && root) ROOT_IDS.delete(root);
|
||||
if (observer && !itemsLeft) {
|
||||
// No more elements to observe for threshold, disconnect observer
|
||||
observer.disconnect();
|
||||
}
|
||||
|
||||
// Remove reference to element
|
||||
INSTANCE_MAP.delete(element);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
从其实现角度来看，为了保证正确识别到子元素存在，一定要保证 `ref` 能持续传递给组件最外层 DOM，如果出现传递断裂，就会判定当前组件不在视图内，比如：
|
||||
|
||||
```jsx
|
||||
const Component = () => {
|
||||
const [ref, inView] = useInView();
|
||||
|
||||
return <Child ref={ref} />;
|
||||
};
|
||||
|
||||
const Child = ({ loading, ref }) => {
|
||||
if (loading) {
|
||||
// 这一步会判定为 inView：false
|
||||
return <Spin />;
|
||||
}
|
||||
|
||||
return <div ref={ref}>Child</div>;
|
||||
};
|
||||
```
|
||||
|
||||
如果你的代码基于 `inView` 做了阻止渲染的判定，那么这个组件进入 loading 后就无法改变状态了。为了避免这种情况，要么不要让 `ref` 的传递断掉，要么当没有拿到 `ref` 对象时判定 `inView` 为 true。
|
||||
|
||||
## 4 总结
|
||||
|
||||
分析了这么多 React- 类的库，其核心思想有两个：
|
||||
|
||||
1. 将原生 API 转换为框架特有 API，比如 React 系列的 Hooks 与 ref。
|
||||
2. 处理生命周期导致的边界情况，比如 dom 被更新时先 `unobserve` 再重新 `observe`。
|
||||
|
||||
看过 [react-intersection-observer](https://github.com/thebuilder/react-intersection-observer) 的源码后，你觉得还有可优化的地方吗？欢迎讨论。
|
||||
|
||||
> 讨论地址是：[react-intersection-observer 源码》· Issue #257 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/257)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,233 @@
|
||||
## 1 引言
|
||||
|
||||
Object 类型的比较是非常重要的基础知识，通过 [How to Compare Objects in JavaScript](https://dmitripavlutin.com/how-to-compare-objects-in-javascript/) 这篇文章，我们可以学到四种对比方法：引用对比、手动对比、浅对比、深对比。
|
||||
|
||||
## 2 简介
|
||||
|
||||
### 引用对比
|
||||
|
||||
下面三种对比方式用于 Object，皆在引用相同是才返回 `true`：
|
||||
|
||||
- `===`
|
||||
- `==`
|
||||
- `Object.is()`
|
||||
|
||||
```js
|
||||
const hero1 = {
|
||||
name: "Batman",
|
||||
};
|
||||
const hero2 = {
|
||||
name: "Batman",
|
||||
};
|
||||
|
||||
hero1 === hero1; // => true
|
||||
hero1 === hero2; // => false
|
||||
|
||||
hero1 == hero1; // => true
|
||||
hero1 == hero2; // => false
|
||||
|
||||
Object.is(hero1, hero1); // => true
|
||||
Object.is(hero1, hero2); // => false
|
||||
```
|
||||
|
||||
### 手动对比
|
||||
|
||||
写一个自定义函数，按照对象内容做自定义对比也是一种方案：
|
||||
|
||||
```js
|
||||
function isHeroEqual(object1, object2) {
|
||||
return object1.name === object2.name;
|
||||
}
|
||||
|
||||
const hero1 = {
|
||||
name: "Batman",
|
||||
};
|
||||
const hero2 = {
|
||||
name: "Batman",
|
||||
};
|
||||
const hero3 = {
|
||||
name: "Joker",
|
||||
};
|
||||
|
||||
isHeroEqual(hero1, hero2); // => true
|
||||
isHeroEqual(hero1, hero3); // => false
|
||||
```
|
||||
|
||||
如果要对比的对象 key 不多，或者在特殊业务场景需要时，这种手动对比方法其实还是蛮实用的。
|
||||
|
||||
但这种方案不够自动化，所以才有了浅对比。
|
||||
|
||||
### 浅对比
|
||||
|
||||
浅对比函数写法有很多，不过其效果都是标准的，下面给出了一种写法：
|
||||
|
||||
```js
|
||||
function shallowEqual(object1, object2) {
|
||||
const keys1 = Object.keys(object1);
|
||||
const keys2 = Object.keys(object2);
|
||||
|
||||
if (keys1.length !== keys2.length) {
|
||||
return false;
|
||||
}
|
||||
|
||||
for (let key of keys1) {
|
||||
if (object1[key] !== object2[key]) {
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，浅对比就是将对象每个属性进行引用对比，算是一种性能上的平衡，尤其在 redux 下有特殊的意义。
|
||||
|
||||
下面给出了使用例子：
|
||||
|
||||
```js
|
||||
const hero1 = {
|
||||
name: "Batman",
|
||||
realName: "Bruce Wayne",
|
||||
};
|
||||
const hero2 = {
|
||||
name: "Batman",
|
||||
realName: "Bruce Wayne",
|
||||
};
|
||||
const hero3 = {
|
||||
name: "Joker",
|
||||
};
|
||||
|
||||
shallowEqual(hero1, hero2); // => true
|
||||
shallowEqual(hero1, hero3); // => false
|
||||
```
|
||||
|
||||
如果对象层级再多一层，浅对比就无效了，此时需要使用深对比。
|
||||
|
||||
### 深对比
|
||||
|
||||
深对比就是递归对比对象所有简单对象值，遇到复杂对象就逐个 key 进行对比，以此类推。
|
||||
|
||||
下面是一种实现方式：
|
||||
|
||||
```js
|
||||
function deepEqual(object1, object2) {
|
||||
const keys1 = Object.keys(object1);
|
||||
const keys2 = Object.keys(object2);
|
||||
|
||||
if (keys1.length !== keys2.length) {
|
||||
return false;
|
||||
}
|
||||
|
||||
for (const key of keys1) {
|
||||
const val1 = object1[key];
|
||||
const val2 = object2[key];
|
||||
const areObjects = isObject(val1) && isObject(val2);
|
||||
if (
|
||||
(areObjects && !deepEqual(val1, val2)) ||
|
||||
(!areObjects && val1 !== val2)
|
||||
) {
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
function isObject(object) {
|
||||
return object != null && typeof object === "object";
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，只要遇到 Object 类型的 key，就会递归调用一次 `deepEqual` 进行比较，否则对于简单类型直接使用 `!==` 引用对比。
|
||||
|
||||
值得注意的是，数组类型也满足 `typeof object === "object"` 的条件，且 `Object.keys` 可以作用于数组，且 `object[key]` 也可作用于数组，因此数组和对象都可以采用相同方式处理。
|
||||
|
||||
有了深对比，再也不用担心复杂对象的比较了：
|
||||
|
||||
```js
|
||||
const hero1 = {
|
||||
name: "Batman",
|
||||
address: {
|
||||
city: "Gotham",
|
||||
},
|
||||
};
|
||||
const hero2 = {
|
||||
name: "Batman",
|
||||
address: {
|
||||
city: "Gotham",
|
||||
},
|
||||
};
|
||||
|
||||
deepEqual(hero1, hero2); // => true
|
||||
```
|
||||
|
||||
但深对比会造成性能损耗，不要小看递归的作用，在对象树复杂时，深对比甚至会导致严重的性能问题。
|
||||
|
||||
## 3 精读
|
||||
|
||||
### 常见的引用对比
|
||||
|
||||
引用对比是最常用的，一般在做 props 比较时，只允许使用引用对比：
|
||||
|
||||
```js
|
||||
this.props.style !== nextProps.style;
|
||||
```
|
||||
|
||||
如果看到有深对比的地方，一般就要有所警觉，这里是真的需要深对比吗？是不是其他地方写法有问题导致的。
|
||||
|
||||
比如在某处看到这样的代码：
|
||||
|
||||
```js
|
||||
deepEqual(this.props.style, nextProps.style);
|
||||
```
|
||||
|
||||
可能是父组件一处随意拼写导致的：
|
||||
|
||||
```jsx
|
||||
const Parent = () => {
|
||||
return <Child style={{ color: "red" }} />;
|
||||
};
|
||||
```
|
||||
|
||||
一个只解决局部问题的同学可能会采用 `deepEqual`，OK 这样也能解决问题，但一个有全局感的同学会这样解决问题：
|
||||
|
||||
```js
|
||||
this.props.style === nextProps.style;
|
||||
```
|
||||
|
||||
```jsx
|
||||
const Parent = () => {
|
||||
const style = useMemo(() => ({ color: "red" }), []);
|
||||
return <Child style={style} />;
|
||||
};
|
||||
```
|
||||
|
||||
从性能上来看，`Parent` 定义的 `style` 只会执行一次且下次渲染几乎没有对比损耗（依赖为空数组），子组件引用对比性能最佳，这样的组合一定优于 `deepEqual` 的例子。
|
||||
|
||||
### 常见的浅对比
|
||||
|
||||
浅对比也在判断组件是否重渲染时很常用：
|
||||
|
||||
```jsx
|
||||
shouldComponentUpdate(nextProps) {
|
||||
return !shallowEqual(this.props, nextProps)
|
||||
}
|
||||
```
|
||||
|
||||
原因是 `this.props` 这个对象引用的变化在逻辑上是无需关心的，因为应用只会使用到 `this.props[key]` 这一层级，再考虑到 React 组件生态下，Immutable 的上下文保证了任何对象子属性变化一定导致对象整体引用变化，可以放心的进行浅对比。
|
||||
|
||||
最少见的就是手动对比和深对比，如果你看到一段代码中使用了深对比，大概率这段代码可以被优化为浅对比。
|
||||
|
||||
## 4 总结
|
||||
|
||||
虽然今天总结了 4 种比较 Object 对象的方式，但在实际项目中，应该尽可能使用引用对比，其次是浅对比和手动对比，最坏的情况是使用深对比。
|
||||
|
||||
> 讨论地址是：[精读《如何比较 Object 对象》· Issue #258 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/258)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,481 @@
|
||||
## 1 引言
|
||||
|
||||
随着 [Typescript 4 Beta](https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/) 的发布，又带来了许多新功能，其中 Variadic Tuple Types 解决了大量重载模版代码的顽疾，使得这次更新非常有意义。
|
||||
|
||||
## 2 简介
|
||||
|
||||
### 可变元组类型
|
||||
|
||||
考虑 `concat` 场景，接收两个数组或者元组类型，组成一个新数组：
|
||||
|
||||
```typescript
|
||||
function concat(arr1, arr2) {
|
||||
return [...arr1, ...arr2];
|
||||
}
|
||||
```
|
||||
|
||||
如果要定义 `concat` 的类型，以往我们会通过枚举的方式，先枚举第一个参数数组中的每一项：
|
||||
|
||||
```typescript
|
||||
function concat<>(arr1: [], arr2: []): [A];
|
||||
function concat<A>(arr1: [A], arr2: []): [A];
|
||||
function concat<A, B>(arr1: [A, B], arr2: []): [A, B];
|
||||
function concat<A, B, C>(arr1: [A, B, C], arr2: []): [A, B, C];
|
||||
function concat<A, B, C, D>(arr1: [A, B, C, D], arr2: []): [A, B, C, D];
|
||||
function concat<A, B, C, D, E>(arr1: [A, B, C, D, E], arr2: []): [A, B, C, D, E];
|
||||
function concat<A, B, C, D, E, F>(arr1: [A, B, C, D, E, F], arr2: []): [A, B, C, D, E, F];)
|
||||
```
|
||||
|
||||
再枚举第二个参数中每一项，如果要完成所有枚举，仅考虑数组长度为 6 的情况，就要定义 36 次重载，代码几乎不可维护：
|
||||
|
||||
```typescript
|
||||
function concat<A2>(arr1: [], arr2: [A2]): [A2];
|
||||
function concat<A1, A2>(arr1: [A1], arr2: [A2]): [A1, A2];
|
||||
function concat<A1, B1, A2>(arr1: [A1, B1], arr2: [A2]): [A1, B1, A2];
|
||||
function concat<A1, B1, C1, A2>(
|
||||
arr1: [A1, B1, C1],
|
||||
arr2: [A2]
|
||||
): [A1, B1, C1, A2];
|
||||
function concat<A1, B1, C1, D1, A2>(
|
||||
arr1: [A1, B1, C1, D1],
|
||||
arr2: [A2]
|
||||
): [A1, B1, C1, D1, A2];
|
||||
function concat<A1, B1, C1, D1, E1, A2>(
|
||||
arr1: [A1, B1, C1, D1, E1],
|
||||
arr2: [A2]
|
||||
): [A1, B1, C1, D1, E1, A2];
|
||||
function concat<A1, B1, C1, D1, E1, F1, A2>(
|
||||
arr1: [A1, B1, C1, D1, E1, F1],
|
||||
arr2: [A2]
|
||||
): [A1, B1, C1, D1, E1, F1, A2];
|
||||
```
|
||||
|
||||
如果我们采用批量定义的方式，问题也不会得到解决，因为参数类型的顺序得不到保证：
|
||||
|
||||
```typescript
|
||||
function concat<T, U>(arr1: T[], arr2, U[]): Array<T | U>;
|
||||
```
|
||||
|
||||
在 Typescript 4，可以在定义中对数组进行解构，通过几行代码优雅的解决可能要重载几百次的场景：
|
||||
|
||||
```typescript
|
||||
type Arr = readonly any[];
|
||||
|
||||
function concat<T extends Arr, U extends Arr>(arr1: T, arr2: U): [...T, ...U] {
|
||||
return [...arr1, ...arr2];
|
||||
}
|
||||
```
|
||||
|
||||
上面例子中，`Arr` 类型告诉 TS `T` 与 `U` 是数组类型，再通过 `[...T, ...U]` 按照逻辑顺序依次拼接类型。
|
||||
|
||||
再比如 `tail`，返回除第一项外剩下元素：
|
||||
|
||||
```typescript
|
||||
function tail(arg) {
|
||||
const [_, ...result] = arg;
|
||||
return result;
|
||||
}
|
||||
```
|
||||
|
||||
同样告诉 TS `T` 是数组类型，且 `arr: readonly [any, ...T]` 申明了 `T` 类型表示除第一项其余项的类型，TS 可自动将 `T` 类型关联到对象 `rest`：
|
||||
|
||||
```typescript
|
||||
function tail<T extends any[]>(arr: readonly [any, ...T]) {
|
||||
const [_ignored, ...rest] = arr;
|
||||
return rest;
|
||||
}
|
||||
|
||||
const myTuple = [1, 2, 3, 4] as const;
|
||||
const myArray = ["hello", "world"];
|
||||
|
||||
// type [2, 3, 4]
|
||||
const r1 = tail(myTuple);
|
||||
|
||||
// type [2, 3, ...string[]]
|
||||
const r2 = tail([...myTuple, ...myArray] as const);
|
||||
```
|
||||
|
||||
另外之前版本的 TS 只能将类型解构放在最后一个位置：
|
||||
|
||||
```typescript
|
||||
type Strings = [string, string];
|
||||
type Numbers = [number, number];
|
||||
|
||||
// [string, string, number, number]
|
||||
type StrStrNumNum = [...Strings, ...Numbers];
|
||||
```
|
||||
|
||||
如果你尝试将 `[...Strings, ...Numbers]` 这种写法，将会得到一个错误提示：
|
||||
|
||||
```text
|
||||
A rest element must be last in a tuple type.
|
||||
```
|
||||
|
||||
但在 Typescript 4 版本支持了这种语法：
|
||||
|
||||
```typescript
|
||||
type Strings = [string, string];
|
||||
type Numbers = number[];
|
||||
|
||||
// [string, string, ...Array<number | boolean>]
|
||||
type Unbounded = [...Strings, ...Numbers, boolean];
|
||||
```
|
||||
|
||||
对于再复杂一些的场景，例如高阶函数 `partialCall`，支持一定程度的柯里化：
|
||||
|
||||
```typescript
|
||||
function partialCall(f, ...headArgs) {
|
||||
return (...tailArgs) => f(...headArgs, ...tailArgs);
|
||||
}
|
||||
```
|
||||
|
||||
我们可以通过上面的特性对其进行类型定义，将函数 `f` 第一个参数类型定义为有顺序的 `[...T, ...U]`：
|
||||
|
||||
```typescript
|
||||
type Arr = readonly unknown[];
|
||||
|
||||
function partialCall<T extends Arr, U extends Arr, R>(
|
||||
f: (...args: [...T, ...U]) => R,
|
||||
...headArgs: T
|
||||
) {
|
||||
return (...b: U) => f(...headArgs, ...b);
|
||||
}
|
||||
```
|
||||
|
||||
测试效果如下：
|
||||
|
||||
```typescript
|
||||
const foo = (x: string, y: number, z: boolean) => {};
|
||||
|
||||
// This doesn't work because we're feeding in the wrong type for 'x'.
|
||||
const f1 = partialCall(foo, 100);
|
||||
// ~~~
|
||||
// error! Argument of type 'number' is not assignable to parameter of type 'string'.
|
||||
|
||||
// This doesn't work because we're passing in too many arguments.
|
||||
const f2 = partialCall(foo, "hello", 100, true, "oops");
|
||||
// ~~~~~~
|
||||
// error! Expected 4 arguments, but got 5.
|
||||
|
||||
// This works! It has the type '(y: number, z: boolean) => void'
|
||||
const f3 = partialCall(foo, "hello");
|
||||
|
||||
// What can we do with f3 now?
|
||||
|
||||
f3(123, true); // works!
|
||||
|
||||
f3();
|
||||
// error! Expected 2 arguments, but got 0.
|
||||
|
||||
f3(123, "hello");
|
||||
// ~~~~~~~
|
||||
// error! Argument of type '"hello"' is not assignable to parameter of type 'boolean'
|
||||
```
|
||||
|
||||
值得注意的是，`const f3 = partialCall(foo, "hello");` 这段代码由于还没有执行到 `foo`，因此只匹配了第一个 `x:string` 类型，虽然后面 `y: number, z: boolean` 也是必选，但因为 `foo` 函数还未执行，此时只是参数收集阶段，因此不会报错，等到 `f3(123, true)` 执行时就会校验必选参数了，因此 `f3()` 时才会提示参数数量不正确。
|
||||
|
||||
### 元组标记
|
||||
|
||||
下面两个函数定义在功能上是一样的：
|
||||
|
||||
```typescript
|
||||
function foo(...args: [string, number]): void {
|
||||
// ...
|
||||
}
|
||||
|
||||
function foo(arg0: string, arg1: number): void {
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
但还是有微妙的区别，下面的函数对每个参数都有名称标记，但上面通过解构定义的类型则没有，针对这种情况，Typescript 4 支持了元组标记：
|
||||
|
||||
```typescript
|
||||
type Range = [start: number, end: number];
|
||||
```
|
||||
|
||||
同时也支持与解构一起使用：
|
||||
|
||||
```typescript
|
||||
type Foo = [first: number, second?: string, ...rest: any[]];
|
||||
```
|
||||
|
||||
### Class 从构造函数推断成员变量类型
|
||||
|
||||
构造函数在类实例化时负责一些初始化工作，比如为成员变量赋值，在 Typescript 4，在构造函数里对成员变量的赋值可以直接为成员变量推导类型：
|
||||
|
||||
```typescript
|
||||
class Square {
|
||||
// Previously: implicit any!
|
||||
// Now: inferred to `number`!
|
||||
area;
|
||||
sideLength;
|
||||
|
||||
constructor(sideLength: number) {
|
||||
this.sideLength = sideLength;
|
||||
this.area = sideLength ** 2;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
如果对成员变量赋值包含在条件语句中，还能识别出存在 `undefined` 的风险：
|
||||
|
||||
```typescript
|
||||
class Square {
|
||||
sideLength;
|
||||
|
||||
constructor(sideLength: number) {
|
||||
if (Math.random()) {
|
||||
this.sideLength = sideLength;
|
||||
}
|
||||
}
|
||||
|
||||
get area() {
|
||||
return this.sideLength ** 2;
|
||||
// ~~~~~~~~~~~~~~~
|
||||
// error! Object is possibly 'undefined'.
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
如果在其他函数中初始化，则 TS 不能自动识别，需要用 `!:` 显式申明类型：
|
||||
|
||||
```typescript
|
||||
class Square {
|
||||
// definite assignment assertion
|
||||
// v
|
||||
sideLength!: number;
|
||||
// ^^^^^^^^
|
||||
// type annotation
|
||||
|
||||
constructor(sideLength: number) {
|
||||
this.initialize(sideLength);
|
||||
}
|
||||
|
||||
initialize(sideLength: number) {
|
||||
this.sideLength = sideLength;
|
||||
}
|
||||
|
||||
get area() {
|
||||
return this.sideLength ** 2;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 短路赋值语法
|
||||
|
||||
针对以下三种短路语法提供了快捷赋值语法：
|
||||
|
||||
```typescript
|
||||
a &&= b; // a = a && b
|
||||
a ||= b; // a = a || b
|
||||
a ??= b; // a = a ?? b
|
||||
```
|
||||
|
||||
### catch error unknown 类型
|
||||
|
||||
Typescript 4.0 之后，我们可以将 catch error 定义为 `unknown` 类型，以保证后面的代码以健壮的类型判断方式书写：
|
||||
|
||||
```typescript
|
||||
try {
|
||||
// ...
|
||||
} catch (e) {
|
||||
// error!
|
||||
// Property 'toUpperCase' does not exist on type 'unknown'.
|
||||
console.log(e.toUpperCase());
|
||||
|
||||
if (typeof e === "string") {
|
||||
// works!
|
||||
// We've narrowed 'e' down to the type 'string'.
|
||||
console.log(e.toUpperCase());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
PS：在之前的版本，`catch (e: unknown)` 会报错，提示无法为 `error` 定义 `unknown` 类型。
|
||||
|
||||
### 自定义 JSX 工厂
|
||||
|
||||
TS 4 支持了 `jsxFragmentFactory` 参数定义 Fragment 工厂函数：
|
||||
|
||||
```json
|
||||
{
|
||||
"compilerOptions": {
|
||||
"target": "esnext",
|
||||
"module": "commonjs",
|
||||
"jsx": "react",
|
||||
"jsxFactory": "h",
|
||||
"jsxFragmentFactory": "Fragment"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
还可以通过注释方式覆盖单文件的配置：
|
||||
|
||||
```typescript
|
||||
// Note: these pragma comments need to be written
|
||||
// with a JSDoc-style multiline syntax to take effect.
|
||||
/** @jsx h */
|
||||
/** @jsxFrag Fragment */
|
||||
|
||||
import { h, Fragment } from "preact";
|
||||
|
||||
let stuff = (
|
||||
<>
|
||||
<div>Hello</div>
|
||||
</>
|
||||
);
|
||||
```
|
||||
|
||||
以上代码编译后解析结果如下：
|
||||
|
||||
```typescript
|
||||
// Note: these pragma comments need to be written
|
||||
// with a JSDoc-style multiline syntax to take effect.
|
||||
/** @jsx h */
|
||||
/** @jsxFrag Fragment */
|
||||
import { h, Fragment } from "preact";
|
||||
let stuff = h(Fragment, null, h("div", null, "Hello"));
|
||||
```
|
||||
|
||||
### 其他升级
|
||||
|
||||
其他的升级快速介绍：
|
||||
|
||||
**构建速度提升**，提升了 `--incremental` + `--noEmitOnError` 场景的构建速度。
|
||||
|
||||
**支持 `--incremental` + `--noEmit` 参数同时生效。**
|
||||
|
||||
**支持 `@deprecated` 注释，** 使用此注释时，代码中会使用 ~~删除线~~ 警告调用者。
|
||||
|
||||
**局部 TS Server 快速启动功能，** 打开大型项目时，TS Server 要准备很久，Typescript 4 在 VSCode 编译器下做了优化，可以提前对当前打开的单文件进行部分语法响应。
|
||||
|
||||
**优化自动导入，** 现在 `package.json` `dependencies` 字段定义的依赖将优先作为自动导入的依据，而不再是遍历 `node_modules` 导入一些非预期的包。
|
||||
|
||||
除此之外，还有几个 Break Change：
|
||||
|
||||
`lib.d.ts` 类型升级，主要是移除了 `document.origin` 定义。
|
||||
|
||||
覆盖父 Class 属性的 getter 或 setter 现在都会提示错误。
|
||||
|
||||
通过 `delete` 删除的属性必须是可选的，如果试图用 `delete` 删除一个必选的 key，则会提示错误。
|
||||
|
||||
## 3 精读
|
||||
|
||||
Typescript 4 最大亮点就是可变元组类型了，但可变元组类型也不能解决所有问题。
|
||||
|
||||
拿笔者的场景来说，函数 `useDesigner` 作为自定义 React Hook 与 `useSelector` 结合支持 connect redux 数据流的值，其调用方式是这样的：
|
||||
|
||||
```typescript
|
||||
const nameSelector = (state: any) => ({
|
||||
name: state.name as string,
|
||||
});
|
||||
|
||||
const ageSelector = (state: any) => ({
|
||||
age: state.age as number,
|
||||
});
|
||||
|
||||
const App = () => {
|
||||
const { name, age } = useDesigner(nameSelector, ageSelector);
|
||||
};
|
||||
```
|
||||
|
||||
`name` 与 `age` 是 Selector 注册的，内部实现方式必然是 `useSelector` + reduce，但类型定义就麻烦了，通过重载可以这么做：
|
||||
|
||||
```typescript
|
||||
import * as React from 'react';
|
||||
import { useSelector } from 'react-redux';
|
||||
|
||||
type Function = (...args: any) => any;
|
||||
|
||||
export function useDesigner();
|
||||
export function useDesigner<T1 extends Function>(
|
||||
t1: T1
|
||||
): ReturnType<T1> ;
|
||||
export function useDesigner<T1 extends Function, T2 extends Function>(
|
||||
t1: T1,
|
||||
t2: T2
|
||||
): ReturnType<T1> & ReturnType<T2> ;
|
||||
export function useDesigner<
|
||||
T1 extends Function,
|
||||
T2 extends Function,
|
||||
T3 extends Function
|
||||
>(
|
||||
t1: T1,
|
||||
t2: T2,
|
||||
t3: T3,
|
||||
t4: T4,
|
||||
): ReturnType<T1> &
|
||||
ReturnType<T2> &
|
||||
ReturnType<T3> &
|
||||
ReturnType<T4> &
|
||||
;
|
||||
export function useDesigner<
|
||||
T1 extends Function,
|
||||
T2 extends Function,
|
||||
T3 extends Function,
|
||||
T4 extends Function
|
||||
>(
|
||||
t1: T1,
|
||||
t2: T2,
|
||||
t3: T3,
|
||||
t4: T4
|
||||
): ReturnType<T1> &
|
||||
ReturnType<T2> &
|
||||
ReturnType<T3> &
|
||||
ReturnType<T4> &
|
||||
;
|
||||
export function useDesigner(...selectors: any[]) {
|
||||
return useSelector((state) =>
|
||||
selectors.reduce((selected, selector) => {
|
||||
return {
|
||||
...selected,
|
||||
...selector(state),
|
||||
};
|
||||
}, {})
|
||||
) as any;
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，笔者需要将 `useDesigner` 传入的参数通过函数重载方式一一传入，上面的例子只支持到了三个参数，如果传入了第四个参数则函数定义会失效，因此业界做法一般是定义十几个重载，这样会导致函数定义非常冗长。
|
||||
|
||||
但参考 TS4 的例子，我们可以避免类型重载，而通过枚举的方式支持：
|
||||
|
||||
```typescript
|
||||
type Func = (state?: any) => any;
|
||||
type Arr = readonly Func[];
|
||||
|
||||
const useDesigner = <T extends Arr>(
|
||||
...selectors: T
|
||||
): ReturnType<T[0]> &
|
||||
ReturnType<T[1]> &
|
||||
ReturnType<T[2]> &
|
||||
ReturnType<T[3]> => {
|
||||
return useSelector((state) =>
|
||||
selectors.reduce((selected, selector) => {
|
||||
return {
|
||||
...selected,
|
||||
...selector(state),
|
||||
};
|
||||
}, {})
|
||||
) as any;
|
||||
};
|
||||
```
|
||||
|
||||
可以看到，最大的变化是不需要写四遍重载了，但由于场景和 `concat` 不同，这个例子返回值不是简单的 `[...T, ...U]`，而是 `reduce` 的结果，所以目前还只能通过枚举的方式支持。
|
||||
|
||||
当然可能存在不用枚举就可以支持无限长度的入参类型解析的方案，因笔者水平有限，暂未想到更好的解法，如果你有更好的解法，欢迎告知笔者。
|
||||
|
||||
## 4 总结
|
||||
|
||||
Typescript 4 带来了更强类型语法，更智能的类型推导，更快的构建速度以及更合理的开发者工具优化，唯一的几个 Break Change 不会对项目带来实质影响，期待正式版的发布。
|
||||
|
||||
> 讨论地址是：[精读《Typescript 4》· Issue #259 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/259)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,115 @@
|
||||
## 1 引言
|
||||
|
||||
在说低代码搭建之前，首先要理解什么是搭建（本文搭建指通过 Web 交互搭建一个自定义的新页面）。
|
||||
|
||||
**我认为搭建的本质是提效** ，而提效又分为对研发人员的提效，以及对客户的提效：
|
||||
|
||||
- 对研发人员的提效：相对于 Pro Code 模式，搭建的抽象程度更高，通过牺牲部分定制性换来更高效的开发方式。
|
||||
- 对客户的提效：如果用户有任何搭建 Web 应用的诉求，本质上从阿里云购买服务器自建是最普适的方案，但由于专业性要求高，用户群会很窄，因此需要针对不同用户的诉求开发定制方案，本质上是通过降低通用性换取更低的上手成本，或者针对某个领域降低上手成本，比如 BI 搭建。
|
||||
|
||||
提效虽然被说烂了，但软件工程发展中，几乎大部分工作都能归结到在提效。比如 Vscode、Typescript 提升编码效率；React、Vue 框架提升程序研发效率；工作台、可持续集成提升协同开发效率，等等，连微软都称自己的使命是赋能全球每一人、每个组织成就不凡，很大程度上就是在说提升整个社会的生产效能。
|
||||
|
||||
低代码开发平台（Low-Code Development Platform）则更进一步，允许通过零代码或少量代码就可以快速创建应用。
|
||||
|
||||
从实践结果来看，完全零代码想要覆盖所有领域是不可能的，而 100% 全代码是可以覆盖所有领域，但研发成本太高，所以介于两者之间的低代码模式是值得尝试的，因为许多定制场景往往不需要太多高深的代码就能搞定，很多复杂逻辑可能几个简单的赋值语句、或者条件语句就可以搞定，但如果不允许写代码，其使用成本甚至比写少量代码还要高。
|
||||
|
||||
所以搭建本质解决的是提效问题，考虑提效就要看性价比，是使用者学习几行简单代码后，利用低代码平台效率更高，还是使用者坚持不写代码，使用繁琐的搭建交互成本更高？有人说代码学不会，但简单代码本质和搭建无异，都是对电脑指令的输入。
|
||||
|
||||
还有一些场景将背后复杂度转移到了其他链路，比如数据搭建场景，虽然搭建器没有低代码能力，但却能实现复杂业务逻辑，原因是这个复杂度被 SQL 层吃掉了，既然复杂度无法消除，那么哪一层实现的效率更高，就由哪一层去做才是合理的。
|
||||
|
||||
## 2 精读
|
||||
|
||||
低代码不仅仅包括 “能写代码”，主要具备如下四个特性：物料接入、编排能力、渲染能力、出码能力。
|
||||
|
||||
### 物料接入
|
||||
|
||||
通用搭建引擎要能够接入通用物料，即组件自身不关心搭建环境，就可以被搭建平台所使用。
|
||||
|
||||
这需要搭建平台本身不对组件代码实现有入侵，可以对组件暴露的 props 做完全控制，要做到自动识别组件有哪些 props 变量，并根据类型自动推荐编辑表单类型。
|
||||
|
||||
除了简单的文本、数字、下拉框等编辑器 Setter 之外，还有如下几种复杂编辑器：
|
||||
|
||||
- 回调函数编辑器。
|
||||
- Node 节点编辑器。
|
||||
- 文本国际化编辑器。
|
||||
- 表达式编辑器。
|
||||
|
||||
回调函数编辑器与表达式编辑器都是低代码能力的体现，本质上就是利用代码描述某个变量值或者回调。
|
||||
|
||||
Node 节点编辑器专门处理节点类型 props 参数，比如 `props.header`、`propder.footer`，在代码模式描述为组件，在可视化模式需转化为画布下钻模式进行编辑。
|
||||
|
||||
### 编排能力
|
||||
|
||||
编排能力包含页面编排与逻辑编排，是低代码搭建的核心能力。
|
||||
|
||||
#### 页面编排
|
||||
|
||||
页面编排包含很多交互行为，比如拖拽组件、布局，其中布局大有可为，比如云凤蝶的编辑模式，通过自由拖拽布局，降低了使用者对 DOM 流式布局的理解成本，但通过自适应四周边距模拟出了流式布局自动撑开容器，容器间碰撞挤压的效果。
|
||||
|
||||
组件与组件形成的组合可以形成一个新的物料，一般称为模版，比如一个页面整体也可以称为模版，这个模版组件的 id 就是页面根节点的容器组件。但模版也有不能满足的场景，比如期望组件形成的组合拥有一套全新配置，此时就延伸出低代码业务组件的概念，可以认为将模版当作一个整体编辑，可以为模版设置任意的编辑表单，这个编辑表单的值可以透传到里面每个组件中读取。
|
||||
|
||||
#### 逻辑编排
|
||||
|
||||
逻辑编排是低代码能力的核心，在低代码引擎中，所有组件参数都可以用低代码描述，比如一个 `props.color` 可以通过颜色选择器选一个固定值，也可以转换为表达式模式写一段代码。
|
||||
|
||||
这段代码除了拥有普通 JS 能力外，还拥有基本状态管理的能力，即可以访问当前作用域下的状态 `this.state`，而状态作用域又被容器所分割，容器分为持有状态的容器与不持有状态的，一个持有状态容器内的子组件状态是互通的。
|
||||
|
||||
除了基本状态管理能力外，还拥有访问上下文能力，即调用引擎一些 API 对画布进行操作，一般都用于组件回调，在回调里调用 `this.setState` 设置状态也属于操作上下文的行为。除了上下文外，还有风格化、国际化、取数等能力可以通过 `this` 访问到，其中取数能力专门抽到引擎层做，就是为了让所有组件与取数逻辑解耦，组件只要拿到数据、isFetching，而不需要真正发送取数请求。
|
||||
|
||||
逻辑编排的另一个维度就是可视化，将上述低代码能力通过可视化方式表达为逻辑节点与线条，在描述与维护复杂逻辑时有一定优势。
|
||||
|
||||
### 渲染能力
|
||||
|
||||
搭建特殊之处在于，搭建过程几乎只能在 PC 端完成，但发布后的应用往往有多端渲染的诉求，比如越来越多的公司使用手机查看 BI 报表，甚至报表需要嵌入到微信、支付宝小程序中；PC 搭建的表单往往也有大量手机端填报的诉求。
|
||||
|
||||
所以编辑和渲染端应该是分离的，但为了保证逻辑一致性，核心代码需要复用，所以搭建引擎最好采用 UI 无关的内核 + 业务层拓展 UI 实现方式来做，UI 无关的内核只负责存储、操作画布数据，排除设计器附加的一堆 Panel 后，渲染时可以复用逻辑内核往往就足够了。
|
||||
|
||||
组件的跨端复用也是必须的，现在跨端渲染的技术方案也有不少。
|
||||
|
||||
### 出码能力
|
||||
|
||||
LowCode 与 ProCode 互转也是一大难题，首先互转的好处不必多说，可以自由的在提效与定制间切换，一定是最理想的开发模式，但实现起来有不少阻碍。
|
||||
|
||||
首先是 LowCode 转 ProCode，这个比较简单，原因是 LowCode 本身用 JSON 定义，代码是 JSON 的超集，从子集转换到超集本身没有技术障碍。
|
||||
|
||||
从 ProCode 转换到 LowCode 就麻烦了，一种方式是限定 ProCode 的能力，甚至用一种新的语法替代原生 JS，本质上都是通过将 ProCode 的能力范围限制住，使得 LowCode 可以接住。另一种方式是不对称转换，即从 ProCode 转换为 LowCode 后会存在功能缺失，或者即便功能不缺失，但 LowCode 无法对应的功能无法在搭建平台编辑。
|
||||
|
||||
### 运行时能力
|
||||
|
||||
只拥有上述低代码能力的搭建平台还是太通用了，虽然功能很强大，但在具体的业务场景不一定有多大的提效，具体的业务场景要有具体的解决方案，搭建本质是提效的，如果原子化、低代码的内容太多，就本末倒置，只是用另一种方式写代码罢了，并没有真正做到利用搭建提升开发效率。
|
||||
|
||||
通用的业务定制方式有如下三种：
|
||||
|
||||
- 定制业务组件：比如将某个复杂业务系统 80% 场景都要用到的组件固化为一个业务定制组件，省去了大部分配置时间，让使用者感受到提效。
|
||||
- 定制业务模版和低代码业务组件：更进一步，将业务模版固化下来，本质上类似代码模版，或者利用低代码业务组件，在不开发新组件的前提下，制作一个针对某个业务场景的混合组件。
|
||||
- 定制业务配置项：有些业务场景专业度很高，一方面是用户群不一样，一方面是搭建效率考虑，都应该提供一种基于业务角度出发的配置项，既符合业务思考逻辑，又节省配置步骤。
|
||||
|
||||
以上通用方式都是通过引擎已有的开放能力可以做到的，但对数据场景来说，有一些依赖引擎运行时能力场景，需要将引擎运行时能力抽象出来，配合低代码实现。
|
||||
|
||||
比如让当前页面所有配置相同数据集的组件自动建立筛选联动关联，虽然筛选联动关联可以通过低代码方式配置，但当画布组件数量变化时，或者有组件动态调用 API 新增组件时，静态的配置很难满足动态关联场景，此时我们可以拓展出一些全局运行时能力，让组件实现这些运行时能力时可以拿到画布信息，在引擎实际调用时再动态运行，而不是编辑生成一份静态 JSON 与渲染完全割裂。
|
||||
|
||||
运行时能力在不同平台针对不同垂直场景时会存在差异，如果希望打通底层引擎，可以提供拓展插槽，提供动态注册引擎运行时能力的机制。
|
||||
|
||||
## 3 总结
|
||||
|
||||
一个低代码搭建平台通吃一切场景是不可能的，只要有人愿意为垂直业务场景做 “量身定制”，用户就会立刻觉得搭建效率得到了提升，我们应当站在用户的角度，以用户利益最大化的方式做平台。
|
||||
|
||||
但搭建平台维护成本很高，每个业务场景都单独维护一套肯定不是长久之计，我们需要设计一套有弹性的低代码核心引擎，各个业务都可以基于他为自己的用户群 “量身定制” 一套专属设计器，共享搭建引擎通用的能力与协议，并自由拓展定制能力。
|
||||
|
||||
所以不仅渲染态是多态的，设计器也应该是多态的，其中可以被固化为标准的部分需要沉淀下来，比如物料接入规范、编排能力、出码能力、运行时能力，让各个搭建平台做到合而不同。
|
||||
|
||||
国内外都有非常多做的相当不错的搭建系统，但要不就太通用，具体场景提效不明显，要不就太垂直，换一个业务场景做不了。现在阿里中后台低代码搭建组织就在制定规范，将引擎通用能力固化为标准协议，让不同搭建平台可以对齐规范与功能，未来还会不断收敛核心引擎实现，基于它可以打造出千千万万个垂直领域的搭建平台，贴着业务做搭建提效，同时引擎内核与规范还能保持互通。
|
||||
|
||||
笔者所在阿里数据中台体验技术团队就是中后台低代码搭建组织的一员，将数据搭建领域做到极致。在技术上，我们在打通中后台搭建与数据搭建的技术方案，在产品上，我们正在逐渐统一阿里集团数据搭建平台，对外也携 QuickBI 成为国内唯一一家进入 Gartner 象限的 BI 产品，未来可期。
|
||||
|
||||
阿里数据中台体验技术团队正在火热招人中，如果感兴趣可以联系 ziyi.hzy@alibaba-inc.com 。
|
||||
|
||||
> 讨论地址是：[精读《对低代码搭建的理解》· Issue #260 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/260)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,308 @@
|
||||
## 1 引言
|
||||
|
||||
函数缓存是重要概念，本质上就是用空间（缓存存储）换时间（跳过计算过程）。
|
||||
|
||||
对于无副作用的纯函数，在合适的场景使用函数缓存是非常必要的，让我们跟着 https://whatthefork.is/memoization 这篇文章深入理解一下函数缓存吧！
|
||||
|
||||
## 2 概述
|
||||
|
||||
假设又一个获取天气的函数 `getChanceOfRain`，每次调用都要花 100ms 计算：
|
||||
|
||||
```jsx
|
||||
import { getChanceOfRain } from "magic-weather-calculator";
|
||||
function showWeatherReport() {
|
||||
let result = getChanceOfRain(); // Let the magic happen
|
||||
console.log("The chance of rain tomorrow is:", result);
|
||||
}
|
||||
|
||||
showWeatherReport(); // (!) Triggers the calculation
|
||||
showWeatherReport(); // (!) Triggers the calculation
|
||||
showWeatherReport(); // (!) Triggers the calculation
|
||||
```
|
||||
|
||||
很显然这样太浪费计算资源了，当已经计算过一次天气后，就没有必要再算一次了，我们期望的是后续调用可以直接拿上一次结果的缓存，这样可以节省大量计算。因此我们可以做一个 `memoizedGetChanceOfRain` 函数缓存计算结果：
|
||||
|
||||
```jsx
|
||||
import { getChanceOfRain } from "magic-weather-calculator";
|
||||
let isCalculated = false;
|
||||
let lastResult;
|
||||
// We added this function!
|
||||
function memoizedGetChanceOfRain() {
|
||||
if (isCalculated) {
|
||||
// No need to calculate it again.
|
||||
return lastResult;
|
||||
}
|
||||
// Gotta calculate it for the first time.
|
||||
let result = getChanceOfRain();
|
||||
// Remember it for the next time.
|
||||
lastResult = result;
|
||||
isCalculated = true;
|
||||
return result;
|
||||
}
|
||||
function showWeatherReport() {
|
||||
// Use the memoized function instead of the original function.
|
||||
let result = memoizedGetChanceOfRain();
|
||||
console.log("The chance of rain tomorrow is:", result);
|
||||
}
|
||||
```
|
||||
|
||||
在每次调用时判断优先用缓存，如果没有缓存则调用原始函数并记录缓存。这样当我们多次调用时，除了第一次之外都会立即从缓存中返回结果：
|
||||
|
||||
```jsx
|
||||
showWeatherReport(); // (!) Triggers the calculation
|
||||
showWeatherReport(); // Uses the calculated result
|
||||
showWeatherReport(); // Uses the calculated result
|
||||
showWeatherReport(); // Uses the calculated result
|
||||
```
|
||||
|
||||
然而对于有参数的场景就不适用了，因为缓存并没有考虑参数：
|
||||
|
||||
```jsx
|
||||
function showWeatherReport(city) {
|
||||
let result = getChanceOfRain(city); // Pass the city
|
||||
console.log("The chance of rain tomorrow is:", result);
|
||||
}
|
||||
|
||||
showWeatherReport("Tokyo"); // (!) Triggers the calculation
|
||||
showWeatherReport("London"); // Uses the calculated answer
|
||||
```
|
||||
|
||||
由于参数可能性很多，所以有三种解决方案：
|
||||
|
||||
### 1. 仅缓存最后一次结果
|
||||
|
||||
仅缓存最后一次结果是最节省存储空间的，而且不会有计算错误，但带来的问题就是当参数变化时缓存会立即失效：
|
||||
|
||||
```jsx
|
||||
import { getChanceOfRain } from "magic-weather-calculator";
|
||||
let lastCity;
|
||||
let lastResult;
|
||||
function memoizedGetChanceOfRain(city) {
|
||||
if (city === lastCity) {
|
||||
// Notice this check!
|
||||
// Same parameters, so we can reuse the last result.
|
||||
return lastResult;
|
||||
}
|
||||
// Either we're called for the first time,
|
||||
// or we're called with different parameters.
|
||||
// We have to perform the calculation.
|
||||
let result = getChanceOfRain(city);
|
||||
// Remember both the parameters and the result.
|
||||
lastCity = city;
|
||||
lastResult = result;
|
||||
return result;
|
||||
}
|
||||
function showWeatherReport(city) {
|
||||
// Pass the parameters to the memoized function.
|
||||
let result = memoizedGetChanceOfRain(city);
|
||||
console.log("The chance of rain tomorrow is:", result);
|
||||
}
|
||||
|
||||
showWeatherReport("Tokyo"); // (!) Triggers the calculation
|
||||
showWeatherReport("Tokyo"); // Uses the calculated result
|
||||
showWeatherReport("Tokyo"); // Uses the calculated result
|
||||
showWeatherReport("London"); // (!) Triggers the calculation
|
||||
showWeatherReport("London"); // Uses the calculated result
|
||||
```
|
||||
|
||||
在极端情况下等同于没有缓存：
|
||||
|
||||
```jsx
|
||||
showWeatherReport("Tokyo"); // (!) Triggers the calculation
|
||||
showWeatherReport("London"); // (!) Triggers the calculation
|
||||
showWeatherReport("Tokyo"); // (!) Triggers the calculation
|
||||
showWeatherReport("London"); // (!) Triggers the calculation
|
||||
showWeatherReport("Tokyo"); // (!) Triggers the calculation
|
||||
```
|
||||
|
||||
### 2. 缓存所有结果
|
||||
|
||||
第二种方案是缓存所有结果，使用 Map 存储缓存即可：
|
||||
|
||||
```jsx
|
||||
// Remember the last result *for every city*.
|
||||
let resultsPerCity = new Map();
|
||||
function memoizedGetChanceOfRain(city) {
|
||||
if (resultsPerCity.has(city)) {
|
||||
// We already have a result for this city.
|
||||
return resultsPerCity.get(city);
|
||||
}
|
||||
// We're called for the first time for this city.
|
||||
let result = getChanceOfRain(city);
|
||||
// Remember the result for this city.
|
||||
resultsPerCity.set(city, result);
|
||||
return result;
|
||||
}
|
||||
function showWeatherReport(city) {
|
||||
// Pass the parameters to the memoized function.
|
||||
let result = memoizedGetChanceOfRain(city);
|
||||
console.log("The chance of rain tomorrow is:", result);
|
||||
}
|
||||
|
||||
showWeatherReport("Tokyo"); // (!) Triggers the calculation
|
||||
showWeatherReport("London"); // (!) Triggers the calculation
|
||||
showWeatherReport("Tokyo"); // Uses the calculated result
|
||||
showWeatherReport("London"); // Uses the calculated result
|
||||
showWeatherReport("Tokyo"); // Uses the calculated result
|
||||
showWeatherReport("Paris"); // (!) Triggers the calculation
|
||||
```
|
||||
|
||||
这么做带来的弊端就是内存溢出，当可能参数过多时会导致内存无限制的上涨，最坏的情况就是触发浏览器限制或者页面崩溃。
|
||||
|
||||
### 3. 其他缓存策略
|
||||
|
||||
介于只缓存最后一项与缓存所有项之间还有这其他选择，比如 LRU（least recently used）只保留最小化最近使用的缓存，或者为了方便浏览器回收，使用 WeakMap 替代 Map。
|
||||
|
||||
最后提到了函数缓存的一个坑，必须是纯函数。比如下面的 CASE：
|
||||
|
||||
```jsx
|
||||
// Inside the magical npm package
|
||||
function getChanceOfRain() {
|
||||
// Show the input box!
|
||||
let city = prompt("Where do you live?");
|
||||
// ... calculation ...
|
||||
}
|
||||
// Our code
|
||||
function showWeatherReport() {
|
||||
let result = getChanceOfRain();
|
||||
console.log("The chance of rain tomorrow is:", result);
|
||||
}
|
||||
```
|
||||
|
||||
`getChanceOfRain` 每次会由用户输入一些数据返回结果，导致缓存错误，原因是 “函数入参一部分由用户输入” 就是副作用，我们不能对有副作用的函数进行缓存。
|
||||
|
||||
这有时候也是拆分函数的意义，将一个有副作用函数的无副作用部分分解出来，这样就能局部做函数缓存了：
|
||||
|
||||
```jsx
|
||||
// If this function only calculates things,
|
||||
// we would call it "pure".
|
||||
// It is safe to memoize this function.
|
||||
function getChanceOfRain(city) {
|
||||
// ... calculation ...
|
||||
}
|
||||
// This function is "impure" because
|
||||
// it shows a prompt to the user.
|
||||
function showWeatherReport() {
|
||||
// The prompt is now here
|
||||
let city = prompt("Where do you live?");
|
||||
let result = getChanceOfRain(city);
|
||||
console.log("The chance of rain tomorrow is:", result);
|
||||
}
|
||||
```
|
||||
|
||||
最后，我们可以将缓存函数抽象为高阶函数：
|
||||
|
||||
```jsx
|
||||
function memoize(fn) {
|
||||
let isCalculated = false;
|
||||
let lastResult;
|
||||
return function memoizedFn() {
|
||||
// Return the generated function!
|
||||
if (isCalculated) {
|
||||
return lastResult;
|
||||
}
|
||||
let result = fn();
|
||||
lastResult = result;
|
||||
isCalculated = true;
|
||||
return result;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
这样生成新的缓存函数就方便啦：
|
||||
|
||||
```jsx
|
||||
let memoizedGetChanceOfRain = memoize(getChanceOfRain);
|
||||
let memoizedGetNextEarthquake = memoize(getNextEarthquake);
|
||||
let memoizedGetCosmicRaysProbability = memoize(getCosmicRaysProbability);
|
||||
```
|
||||
|
||||
`isCalculated` 与 `lastResult` 都存储在 `memoize` 函数生成的闭包内，外部无法访问。
|
||||
|
||||
## 3 精读
|
||||
|
||||
### 通用高阶函数实现函数缓存
|
||||
|
||||
原文的例子还是比较简单，没有考虑函数多个参数如何处理，下面我们分析一下 Lodash `memoize` 函数源码：
|
||||
|
||||
```jsx
|
||||
function memoize(func, resolver) {
|
||||
if (
|
||||
typeof func != "function" ||
|
||||
(resolver != null && typeof resolver != "function")
|
||||
) {
|
||||
throw new TypeError(FUNC_ERROR_TEXT);
|
||||
}
|
||||
var memoized = function () {
|
||||
var args = arguments,
|
||||
key = resolver ? resolver.apply(this, args) : args[0],
|
||||
cache = memoized.cache;
|
||||
|
||||
if (cache.has(key)) {
|
||||
return cache.get(key);
|
||||
}
|
||||
var result = func.apply(this, args);
|
||||
memoized.cache = cache.set(key, result) || cache;
|
||||
return result;
|
||||
};
|
||||
memoized.cache = new (memoize.Cache || MapCache)();
|
||||
return memoized;
|
||||
}
|
||||
```
|
||||
|
||||
原文有提到缓存策略多种多样，而 Lodash 将缓存策略简化为 key 交给用户自己管理，看这段代码：
|
||||
|
||||
```jsx
|
||||
key = resolver ? resolver.apply(this, args) : args[0];
|
||||
```
|
||||
|
||||
也就是缓存的 key 默认是执行函数时第一个参数，也可以通过 `resolver` 拿到参数处理成新的缓存 key。
|
||||
|
||||
在执行函数时也传入了参数 `func.apply(this, args)`。
|
||||
|
||||
最后 `cache` 也不再使用默认的 Map，而是允许用户自定义 `lodash.memoize.Cache` 自行设置，比如设置为 WeakMap：
|
||||
|
||||
```jsx
|
||||
_.memoize.Cache = WeakMap;
|
||||
```
|
||||
|
||||
### 什么时候不适合用缓存
|
||||
|
||||
以下两种情况不适合用缓存：
|
||||
|
||||
1. 不经常执行的函数。
|
||||
2. 本身执行速度较快的函数。
|
||||
|
||||
对于不经常执行的函数，本身就不需要利用缓存提升执行效率，而缓存反而会长期占用内存。对于本身执行速度较快的函数，其实大部分简单计算速度都很快，使用缓存后对速度没有明显的提升，同时如果计算结果比较大，反而会占用存储资源。
|
||||
|
||||
对于引用的变化尤其重要，比如如下例子：
|
||||
|
||||
```jsx
|
||||
function addName(obj, name){
|
||||
return {
|
||||
...obj,
|
||||
name:
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
为 `obj` 添加一个 key，本身执行速度是非常快的，但添加缓存后会带来两个坏处：
|
||||
|
||||
1. 如果 `obj` 非常大，会在闭包存储完整 `obj` 结构，内存占用加倍。
|
||||
2. 如果 `obj` 通过 mutable 方式修改了，则普通缓存函数还会返回原先结果（因为对象引用没有变），造成错误。
|
||||
|
||||
如果要强行进行对象深对比，虽然会避免出现边界问题，但性能反而会大幅下降。
|
||||
|
||||
## 4 总结
|
||||
|
||||
函数缓存非常有用，但并不是所有场景都适用，因此千万不要极端的将所有函数都添加缓存，仅限于计算耗时、可能重复利用多次，且是纯函数的。
|
||||
|
||||
> 讨论地址是：[精读《函数缓存》· Issue #261 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/261)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,109 @@
|
||||
## 1 引言
|
||||
|
||||
[「可视化搭建系统」——从设计到架构，探索前端的领域和意义](https://juejin.im/post/6854573220532748302) 这篇文章主要分析了现阶段可视化搭建的几种表现形式和实现原理，并重点介绍了基于富文本的可视化搭建思路，让人耳目一新。
|
||||
|
||||
基于富文本的可视化搭建看似很新颖，但其实早就被广泛使用了，任何一个富文本编辑器几乎都有插入表格功能，这就是一个典型插入自定义组件的场景。
|
||||
|
||||
使用过 [语雀](https://www.yuque.com/) 的同学应该知道，这个产品的富文本编辑器可以插入各种各样自定义区块，是 “最像搭建” 的富文本编辑器。
|
||||
|
||||
那么积木式搭建和富文本搭建存在哪些差异，除了富文本更倾向于记录静态内容外，还有哪些差异，两者是否可以结合？本文将围绕这两点进行讨论。
|
||||
|
||||
## 2 精读
|
||||
|
||||
还是先顺着原文谈谈对可视化搭建的理解：
|
||||
|
||||
可视化搭建是通过可视化方式代替开发。**前端代码开发主要围绕的是 html + js + css**，那么无论是 markdown 语法，还是创建另一套模版语言亦或 JSON 构成的 DSL，**都是用一种 dsl + 组件 + css 的方式代替 html + js + css**，可视化搭建则更进一步，用 ui 代替了 dsl + 组件，**即精简为 ui 操作 + css**。
|
||||
|
||||
可以看到，这种转换的推演过程存在一定瑕疵，因为每次转换都有部分损耗：
|
||||
|
||||
**用 dsl + 组件 代替 html + js。**
|
||||
|
||||
如果 dsl 拓展得足够好，理论上可以达到 html 的水平，尤其在垂直业务场景是不需要那么多特殊 html 标签的。
|
||||
|
||||
但用组件代替 js 就有点奇怪了，首先并不是所有 js 逻辑都沉淀在组件里，一定有组件间的联动逻辑是无法通过一个组件 js 完成的，另一方面如果将 js 逻辑寄托在组件代码里，本质上是没有提效的，用源码开发项目与开发搭建平台的组件都是 pro code，更极端一点来说，无论是组件间联动还是整个应用都可以用一个组件来写，那搭建平台就无事可做了，这个组件也成了整个应用，game over。
|
||||
|
||||
为了弥补这块缺憾，低代码能力的呼声越来越高，而低代码能力的核心在于设计是否合理，比如暴露哪些 API 可以覆盖大部分需求？写多少代码合适，如何以最小 API 透出最大弥补组件间缺失的 js 能力？目前来看，以状态数据驱动的低代码是相对优雅的。
|
||||
|
||||
**用 ui 操作 代替 dsl + 组件。**
|
||||
|
||||
UI 操作并不是标准的，相比直接操作模版或者 JSON DSL，UI 化后就仁者见仁智者见智了，但 UI 化带来的效率提升是巨大的，因为所见即所得是生产力的源泉，从直观的 UI 布局来看，就比维护代码更轻松。但 UI 化也存在两个问题，一个是可能有人觉得不如 markdown 效率高，另一个是功能有丢失。
|
||||
|
||||
对于第一点 UI 操作效率不如 markdown 高，可能很多程序员都崇尚用 markdown 维护文档而不是富文本，原因是觉得程序员维护代码的效率反而比所见即所得高，但那可能是错觉，原因是还没有遇到好用的富文本编辑器，体验过语雀富文本编辑器后，相信大部分程序员都不会再想回头写 markdown。当然语雀富文本战胜 markdown 的原因有很多，我觉得主要两点是吸收并兼容了 markdown 操作习惯，与支持了更多仅 UI 能做到的拓展能力，对 markdown 形成降维打击。
|
||||
|
||||
第二点功能丢失很好理解，markdown 有一套标准语法和解析器可以验证，但 UI 操作并没有标准化，也没有独立验证系统，如果无法回退到源码模式，UI 没有实现的功能就做不到。
|
||||
|
||||
回到富文本搭建上，其实富文本搭建和普通网页构建并没有本质区别。html 是超文本标记语言，富文本是跨平台文档格式，从逻辑上这两个格式是可以互转的，只要富文本规则作出足够多的拓展，就可以大致覆盖 html 的能力。
|
||||
|
||||
但富文本搭建有着显著的特征，就是光标。
|
||||
|
||||
### 积木式搭建和富文本搭建的区别
|
||||
|
||||
富文本以文本为中心，因此编辑文字的光标会常驻，编辑的核心逻辑是排版文字，并考虑如何在文字周围添加一些自定义区块。
|
||||
|
||||
有了光标后，圈选也非常重要，因为大家编辑文字时有一种很自然的想法是，任何文字圈选后复制，可以粘贴到任何地方，那么所有插入到富文本中的自定义组件也要支持被圈选，被复制。
|
||||
|
||||
实际上富文本内插入自定义区块也可以转换为积木式搭建方案解决，比如下面的场景：
|
||||
|
||||
```text
|
||||
文本 A
|
||||
图表 B
|
||||
文本 C
|
||||
```
|
||||
|
||||
我们在文本 A 与 文本 C 之间插入图表 B，也可以理解为拖拽了三个组件：文本组件 A + 图表组件 B + 文本组件 C，然后分别编辑这三个组件，微调样式后可以达到与富文本一样的编辑效果，甚至加上自由布局后，在布局能力上会超越富文本。
|
||||
|
||||
虽然功能层面上富文本略有输给积木式搭建，但富文本在编辑体验上是胜出的，对于文字较多的场景，我们还是会选择富文本方式编辑而不是积木式搭建拖拽 N 个文本组件。
|
||||
|
||||
所以微软 OneNote 也吸取了这个经验，毕竟笔记本主要还是记录文字，因此还是采用富文本的编辑模式，但创造性的加入了一个个独立区块，点击任何区域都会创造一个区块，整个文档可以由一个区块构成，也可以是多个区块组合而成，这样对于连贯性的文字场景可以采用一个富文本区块，对于自定义区块较多，比如大部分是图片和表格的，还可以回到积木式搭建的体验。由于 OneNote 采用绝对定位模拟流式布局的思路，当区块重叠时还可以自动挤压底部区块，因此多区块模式下编辑体验还是相对顺畅的。
|
||||
|
||||
可以看出来这是一种结合的尝试，从前端角度来看，富文本本质上是对一个 div 进行 contenteditable 申明，那么一个应用可以整体是 contenteditable 的，也可以局部几个区块是，这种代码层面的自由度体现在搭建上就是积木式搭建可以与富文本搭建自由结合。
|
||||
|
||||
### 积木式搭建与富文本搭建如何结合
|
||||
|
||||
对于积木式搭建来说，富文本只是其中一个组件，在不考虑有富文本组件时是完全没有富文本能力的。比如一个搭建平台只提供了几个图表和基础控件，你是不可能在其基础上使用富文本能力的，甚至连写静态文本都做不到。
|
||||
|
||||
所以富文本只是搭建中一个组件，就像 contenteditable 也只能依附于一个标签，整个网页还是由标签组成的。但对于一个提供了富文本组件的积木式搭建系统来说，文字与控件混排又是一个痛点，毕竟要以一个个区块组件的方式去拖拽文本节点，成本比富文本模式大得多。
|
||||
|
||||
所以理想情况是富文本与整个搭建系统使用同一套 DSL 描述结构，富文本只是在布局上有所简化，简化为简单的平铺模式即可，但因为 DSL 描述打通，富文本也可以描述使用搭建提供的任意组件嵌套在内，所以只要用户愿意，可以将富文本组件拉到最大，整个页面都基于富文本模式去搭建，这就变成了富文本搭建，也可以将富文本缩小，将普通控件以积木方式拖拽到画布中，走积木式搭建路线。
|
||||
|
||||
用代码方式描述积木式搭建：
|
||||
|
||||
```html
|
||||
<bar-chart />
|
||||
<div>
|
||||
<p>header</p>
|
||||
<line-chart />
|
||||
<p>footer</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
上述模式需要拖拽 `bar-chart`、`div`、`p`、`line-chart`、`p` 共 5 个组件。富文本模式则类似下面的结构：
|
||||
|
||||
```html
|
||||
<bar-chart />
|
||||
<div contenteditable>
|
||||
<p>header</p>
|
||||
<line-chart />
|
||||
<p>footer</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
只要拖拽 `bar-chart`、`div` 两个组件即可，`div` 内部的文字通过光标输入，`line-chart` 通过富文本某个按钮或者键盘快捷键添加。
|
||||
|
||||
可以看到虽然操作方式不同，但本质上描述协议并没有本质区别，我们理论上可以将任何容器标签切换为富文本模式。
|
||||
|
||||
## 3 总结
|
||||
|
||||
富文本是一种重要的交互模式，可以基于富文本模式做搭建，也可以在搭建系统中嵌入富文本组件，甚至还可以追求搭建与富文本的结合。
|
||||
|
||||
富文本组件既可以是搭建系统中一个组件，又可以在内部承载搭建系统的所有组件，做到这一步才算是真正发挥出富文本的潜力。
|
||||
|
||||
> 讨论地址是：[精读《可视化搭建思考 - 富文本搭建》· Issue #262 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/262)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,185 @@
|
||||
## 1 引言
|
||||
|
||||
本周跟着 [Tasks, microtasks, queues and schedules](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/) 这篇文章一起深入理解这些概念间的区别。
|
||||
|
||||
先说结论：
|
||||
|
||||
- Tasks 按顺序执行，浏览器可能在 Tasks 之间执行渲染。
|
||||
- Microtasks 也按顺序执行，时机是：
|
||||
- 如果没有执行中的 js 堆栈，则在每个回调之后。
|
||||
- 在每个 task 之后。
|
||||
|
||||
## 2 概述
|
||||
|
||||
### Event Loop
|
||||
|
||||
在说这些概念前，先要介绍 Event Loop。
|
||||
|
||||
首先浏览器是多线程的，每个 JS 脚本都在单线程中执行，每个线程都有自己的 Event Loop，同源的所有浏览器窗口共享一个 Event Loop 以便通信。
|
||||
|
||||
Event Loop 会持续循环的执行所有排队中的任务，浏览器会为这些任务划分优先级，按照优先级来执行，这就会导致 Tasks 与 Microtasks 执行顺序与调用顺序的不同。
|
||||
|
||||
### promise 与 setTimeout
|
||||
|
||||
看下面代码的输出顺序：
|
||||
|
||||
```js
|
||||
console.log("script start");
|
||||
|
||||
setTimeout(function () {
|
||||
console.log("setTimeout");
|
||||
}, 0);
|
||||
|
||||
Promise.resolve()
|
||||
.then(function () {
|
||||
console.log("promise1");
|
||||
})
|
||||
.then(function () {
|
||||
console.log("promise2");
|
||||
});
|
||||
|
||||
console.log("script end");
|
||||
```
|
||||
|
||||
正确答案是 `script start`, `script end`, `promise1`, `promise2`, `setTimeout`，在线程中，同步脚本执行优先级最高，然后 promise 任务会存放到 Microtasks，setTimeout 任务会存放到 Tasks，Microtasks 会优先于 Tasks 执行。
|
||||
|
||||
Microtasks 中文可以翻译为微任务，只要有 Microtasks 插入，就会不断执行 Microtasks 队列直到结束，在结束前都不会执行到 Tasks。
|
||||
|
||||
### 点击冒泡 + 任务
|
||||
|
||||
下面给出了更复杂的例子，提前说明后面的例子 Chrome、Firefox、Safari、Edge 浏览器的结果完全不一样，但只有 Chrome 的运行结果是对的！为什么 Chrome 是对的呢，请看下面的分析：
|
||||
|
||||
```html
|
||||
<div class="outer">
|
||||
<div class="inner"></div>
|
||||
</div>
|
||||
```
|
||||
|
||||
```js
|
||||
// Let's get hold of those elements
|
||||
var outer = document.querySelector(".outer");
|
||||
var inner = document.querySelector(".inner");
|
||||
|
||||
// Let's listen for attribute changes on the
|
||||
// outer element
|
||||
new MutationObserver(function () {
|
||||
console.log("mutate");
|
||||
}).observe(outer, {
|
||||
attributes: true,
|
||||
});
|
||||
|
||||
// Here's a click listener…
|
||||
function onClick() {
|
||||
console.log("click");
|
||||
|
||||
setTimeout(function () {
|
||||
console.log("timeout");
|
||||
}, 0);
|
||||
|
||||
Promise.resolve().then(function () {
|
||||
console.log("promise");
|
||||
});
|
||||
|
||||
outer.setAttribute("data-random", Math.random());
|
||||
}
|
||||
|
||||
// …which we'll attach to both elements
|
||||
inner.addEventListener("click", onClick);
|
||||
outer.addEventListener("click", onClick);
|
||||
```
|
||||
|
||||
点击 `inner` 区块后，正确输出顺序应该是：
|
||||
|
||||
```text
|
||||
click
|
||||
promise
|
||||
mutate
|
||||
click
|
||||
promise
|
||||
mutate
|
||||
timeout
|
||||
timeout
|
||||
```
|
||||
|
||||
逻辑如下：
|
||||
|
||||
1. 点击触发 `onClick` 函数入栈。
|
||||
2. 立即执行 `console.log('click')` 打印 `click`。
|
||||
3. `console.log('timeout')` 入栈 Tasks。
|
||||
4. `console.log('promise')` 入栈 microtasks。
|
||||
5. `outer.setAttribute('data-random')` 的触发导致监听者 `MutationObserver` 入栈 microtasks。
|
||||
6. `onClick` 函数执行完毕，此时线程调用栈为空，开始执行 microtasks 队列。
|
||||
7. 打印 `promise`，打印 `mutate`，此时 microtasks 已空。
|
||||
8. 执行冒泡机制，outer div 也触发 `onClick` 函数，同理，打印 `promise`，打印 `mutate`。
|
||||
9. 都执行完后，执行 Tasks，打印 `timeout`，打印 `timeout`。
|
||||
|
||||
### 模拟点击冒泡 + 任务
|
||||
|
||||
如果将触发 `onClick` 行为由点击改为：
|
||||
|
||||
```js
|
||||
inner.click();
|
||||
```
|
||||
|
||||
结果会不同吗？答案是会（单元测试与用户行为不符合，单测也有无解的时候）。然而四大浏览器的执行结果也是完全不一样，但从逻辑上讲仍然 Chrome 是对的，让我们看下 Chrome 的结果：
|
||||
|
||||
```text
|
||||
click
|
||||
click
|
||||
promise
|
||||
mutate
|
||||
promise
|
||||
timeout
|
||||
timeout
|
||||
```
|
||||
|
||||
逻辑如下：
|
||||
|
||||
1. `inner.click()` 触发 `onClick` 函数入栈。
|
||||
2. 立即执行 `console.log('click')` 打印 `click`。
|
||||
3. `console.log('timeout')` 入栈 Tasks。
|
||||
4. `console.log('promise')` 入栈 microtasks。
|
||||
5. `outer.setAttribute('data-random')` 的触发导致监听者 `MutationObserver` 入栈 microtasks。
|
||||
6. 由于冒泡改为 js 调用栈执行，所以此时 js 调用栈未结束，不会执行 microtasks，反而是继续执行冒泡，outer 的 `onClick` 函数入栈。
|
||||
7. 立即执行 `console.log('click')` 打印 `click`。
|
||||
8. `console.log('timeout')` 入栈 Tasks。
|
||||
9. `console.log('promise')` 入栈 microtasks。
|
||||
10. `MutationObserver` 由于还没调用，因此这次 `outer.setAttribute('data-random')` 的改动实际上没有作用。
|
||||
11. js 调用栈执行完毕，开始执行 microtasks，按照入栈顺序，打印 `promise`，`mutate`，`promise`。
|
||||
12. microtasks 执行完毕，开始执行 Tasks，打印 `timeout`，`timeout`。
|
||||
|
||||
## 3 精读
|
||||
|
||||
基于任务调度这么复杂，且浏览器实现方式很不同，下面两件事是我很不推荐的：
|
||||
|
||||
1. 业务逻辑 “巧妙” 依赖了 microtasks 与 Tasks 执行逻辑的微妙差异。
|
||||
2. 死记硬背调用顺序。
|
||||
|
||||
且不说依赖了调用顺序的业务逻辑本身就很难维护，不同浏览器之间对任务调用顺序还是不同的，这可能源于对 W3C 标准规范理解的偏差，也可能是 BUG，这会导致依赖于此的逻辑非常脆弱。
|
||||
|
||||
虽然上面两个例子非常复杂，但我们也不必把这个例子当作经典背诵，只要记住文章开头提到的执行逻辑就可以推导：
|
||||
|
||||
- Tasks 按顺序执行，浏览器可能在 Tasks 之间执行渲染。
|
||||
- Microtasks 也按顺序执行，时机是：
|
||||
- 如果没有执行中的 js 堆栈，则在每个回调之后。
|
||||
- 在每个 task 之后。
|
||||
|
||||
记住 `Promise` 是 `Microtasks`，`setTimeout` 是 `Tasks`，JS 一次 Event Loop 完毕后，即调用栈没有内容时才会执行 `Microtasks` -> `Tasks`，在执行 `Microtasks` 过程中插入的 `Microtasks` 会按顺序继续执行，而执行 `Tasks` 中插入的 `Microtasks` 得等到调用栈执行完后才继续执行。
|
||||
|
||||
上面说的内容都是指一次 Event Loop 时立即执行的优先级，不要和执行延迟时间弄混淆了。
|
||||
|
||||
把 JS 线程的 Event Loop 当作一个函数，函数内同步逻辑执行优先级是最高的，如果遇到 `Microtasks` 或 `Tasks` 就会立即记录下来，当一次 Event Loop 执行完后立即调用 `Microtasks`，等 `Microtasks` 队列执行完毕后可能进行一些渲染行为，等这些浏览器操作完成后，再考虑执行 `Tasks` 队列。
|
||||
|
||||
## 4 总结
|
||||
|
||||
最后，还是要强调一句，不要依赖 `Microtasks` 与 `Tasks` 的执行顺序，尤其在申明式编程环境中，我们可以把 `Microtasks` 与 `Tasks` 都当作是异步内容，在渲染时做好状态判断即可，不用关心先后顺序。
|
||||
|
||||
> 讨论地址是：[精读《Tasks, microtasks, queues and schedules》· Issue #264 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/264)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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,306 @@
|
||||
[spring](https://spring.io/) 是 Java 非常重要的框架，且蕴含了一系列设计模式，非常值得研究，本期就通过 [Spring学习](https://www.cnblogs.com/wmyskxz/p/8820371.html) 这篇文章了解一下 spring。
|
||||
|
||||
## spring 为何长寿
|
||||
|
||||
spring 作为一个后端框架，拥有 17 年历史，这在前端看来是不可思议的。前端几乎没有一个框架可以流行超过 5 年，就最近来看，react、angular、vue 三大框架可能会活的久一点，他们都是前端相对成熟阶段的产物，我们或多或少可以看出一些设计模式。然而这些前端框架与 spring 比起来还是差距很大，我们来看看 spring 到底强大在哪。
|
||||
|
||||
### 设计模式
|
||||
|
||||
设计模式是一种思想，不依附于任何编程语言与开发框架。比如你学会了工厂设计模式，可以在后端用，也可以转到前端用，可以在 Go 语言用，也可以在 Typescript 用，可以在 React 框架用，也可以在 Vue 里用，所以设计模式是一种具有迁移能力的知识，学会后可以受益整个职业生涯，而语言、框架则不具备迁移性，前端许多同学都把精力花在学习框架特性上，遇到前端技术迭代时期就尴尬了，这就是为什么大公司面试要问框架原理，就是看看你能否抓住一些不变的东西，所以洋洋洒洒的说上下文相关的细节也不是面试官想要的，真正想听到的是你抽象后对框架原理共性的总结。
|
||||
|
||||
spring 框架就用到了许多设计模式，包括：
|
||||
|
||||
工厂模式：用工厂生产对象实例来代替原始的 new。所谓工厂就是屏蔽实例话的细节，调用处无需关心实例化对象需要的环境参数，提升可维护性。spring 的 BeanFactory 创建 bean 对象就是工厂模式的体现。
|
||||
代理模式：允许通过代理对象访问目标对象。Spring 实现 AOP 就是通过动态代理模式。
|
||||
单例模式：单实例。spring 的 bean 默认都是单例。
|
||||
包装器模式：将几个不同方法通用部分抽象出来，调用时通过包装器内部引导到不同的实现。比如 spring 连接多种数据库就使用了包装器模式简化。
|
||||
观察者模式：这个前端同学很熟悉，就是事件机制，spring 中可以通过 ApplicationEvent 实践观察者模式。
|
||||
适配器模式：通过适配器将接口转换为另一个格式的接口。spring AOP 的增强和通知就使用了适配器模式。
|
||||
模板方法模式：父类先定义一些函数，这些函数之间存在调用关联，将某些设定为抽象函数等待子类继承时去重写。spring 的 `jdbcTemplate`、`hibernateTemplate` 等数据库操作类使用了模版方法模式。
|
||||
|
||||
### 全家桶
|
||||
|
||||
spring 作为一个全面的 java 框架，提供了系列全家桶满足各种场景需求：spring mvc、spring security、spring data、spring boot、spring cloud。
|
||||
|
||||
- spring boot：简化了 spring 应用配置，约定大于配置的思维。
|
||||
- spring data：是一个数据操作与访问工具集，比如支持 jdbc、redis 等数据源操作。
|
||||
- spring cloud：是一个微服务解决方案，基于 spring boot，集成了服务发现、配置管理、消息总线、负载均衡、断路器、数据监控等各种服务治理能力。
|
||||
- spring security：支持一些安全模型比如单点登录、令牌中继、令牌交换等。
|
||||
- spring mvc：MVC 思想的 web 框架。
|
||||
|
||||
## IOC
|
||||
|
||||
IOC（Inverse of Control）控制反转。IOC 是 Spring 最核心部分，因为所有对象调用都离不开 IOC 模式。
|
||||
|
||||
假设我们有三个类：Country、Province、City，最大的类别是国家，其次是省、城市，国家类需要调用省类，省类需要调用城市类：
|
||||
|
||||
```java
|
||||
public class Country {
|
||||
private Province province;
|
||||
public Country(){
|
||||
this.province = new Province()
|
||||
}
|
||||
}
|
||||
|
||||
public class Province {
|
||||
private City city;
|
||||
public Province(){
|
||||
this.city = new City()
|
||||
}
|
||||
}
|
||||
|
||||
public class City {
|
||||
public City(){
|
||||
// ...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
假设来了一个需求，City 实例化时需增加人口（people）参数，我们就要改动所有类代码：
|
||||
|
||||
```java
|
||||
public class Country {
|
||||
private Province province;
|
||||
public Country(int people){
|
||||
this.province = new Province(people)
|
||||
}
|
||||
}
|
||||
|
||||
public class Province {
|
||||
private City city;
|
||||
public Province(int people){
|
||||
this.city = new City(people)
|
||||
}
|
||||
}
|
||||
|
||||
public class City {
|
||||
public City(int people){
|
||||
// ...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
那么在真实业务场景中，一个底层类可能被数以千计的类使用，这么改显然难以维护。IOC 就是为了解决这个问题，它使得我们可以只改动 City 的代码，而不用改动其他类的代码：
|
||||
|
||||
```java
|
||||
public class Country {
|
||||
private Province province;
|
||||
public Country(Province province){
|
||||
this.province = province
|
||||
}
|
||||
}
|
||||
|
||||
public class Province {
|
||||
private City city;
|
||||
public Province(City city){
|
||||
this.city = city
|
||||
}
|
||||
}
|
||||
|
||||
public lass City {
|
||||
public City(int people){
|
||||
// ...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，增加 `people` 属性只需要改动 city 类。然而这样做也是有成本的，就是类实例化步骤会稍微繁琐一些：
|
||||
|
||||
```java
|
||||
City city = new City(1000);
|
||||
Province province = new Province(city);
|
||||
Country country = new Country(province);
|
||||
```
|
||||
|
||||
这就是控制反转，由 Country 依赖 Province 变成了类依赖框架（上面的实例化代码）注入。
|
||||
|
||||
然而手动维护这种初始化依赖是繁琐的，spring 提供了 bean 容器自动做这件事，我们只需要利用装饰器 Autowired 就可以自动注入依赖：
|
||||
|
||||
```java
|
||||
@Component
|
||||
public class Country {
|
||||
@Autowired
|
||||
private Province province;
|
||||
}
|
||||
@Component
|
||||
public class Province {
|
||||
@Autowired
|
||||
public City city;
|
||||
}
|
||||
@Component
|
||||
public class City {
|
||||
}
|
||||
```
|
||||
|
||||
实际上这种自动分析并实例化的手段，不仅比手写方便，还能解决循环依赖的问题。在实际场景中，两个类相互调用是很常见的，假设现在有 A、B 类相互依赖：
|
||||
|
||||
```java
|
||||
@Component
|
||||
public class A {
|
||||
@Autowired
|
||||
private B b;
|
||||
}
|
||||
@Component
|
||||
public class B {
|
||||
@Autowired
|
||||
public A a;
|
||||
}
|
||||
```
|
||||
|
||||
那么假设我们想获取 A 实例，会经历这样一个过程：
|
||||
|
||||
```text
|
||||
获取 A 实例 -> 实例化不完整 A -> 检测到注入 B -> 实例化不完整 B -> 检测到注入 A -> 注入不完整 A -> 得到完整 B -> 得到完整 A -> 返回 A 实例
|
||||
```
|
||||
|
||||
其实 spring 仅支持单例模式下非构造器的循环依赖，这是因为其内部有一套机制，让 bean 在初始化阶段先提前持有对方引用地址，这样就可以同时实例化两个对象了。
|
||||
|
||||
除了方便之外，IOC 配合 spring 容器概念还可以使获取实例时不用关心一个类实例化需要哪些参数，只需要直接申明获取即可，这样在类的数量特别多，尤其是大量代码不是你写的情况下，不需要阅读类源码也可以轻松获取实例，实在是大大提升了可维护性。
|
||||
|
||||
说到这就提到了 Bean 容器，在 spring 概念中，Bean 容器是对 class 的加强，如果说 Class 定义了类的基本含义，那 Bean 就是对类进行使用拓展，告诉我们应该如何实例化与使用这个类。
|
||||
|
||||
举个例子，比如利用注解描述的这段 Bean 类：
|
||||
|
||||
```java
|
||||
@Configuration
|
||||
public class CityConfig {
|
||||
@Scope("prototype")
|
||||
@Lazy
|
||||
@Bean(initMethod = "init", destroyMethod = "destroy")
|
||||
public City city() {
|
||||
return new City()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，额外描述了是否延迟加载，是否单例，初始化与析构函数分别是什么等等。
|
||||
|
||||
下面给出一个从 Bean 获取实例的例子，采用比较古老的 xml 配置方式：
|
||||
|
||||
```java
|
||||
public interface City {
|
||||
Int getPeople();
|
||||
}
|
||||
```
|
||||
|
||||
```java
|
||||
public class CityImpl implements City {
|
||||
public Int getPeople() {
|
||||
return 1000;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
接下来用 xml 描述这个 bean：
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xmlns="http://www.springframework.org/schema/beans"
|
||||
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName">
|
||||
|
||||
<bean id="city" class="xxx.CityImpl"/>
|
||||
</beans>
|
||||
```
|
||||
|
||||
`bean` 支持的属性还有很多，由于本文并不做入门教学，就不一一列举了，总之 `id` 是一个可选的唯一标志，接下来我们可以通过 `id` 访问到 city 的实例。
|
||||
|
||||
```java
|
||||
public class App {
|
||||
public static void main(String[] args) {
|
||||
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:application.xml");
|
||||
|
||||
// 从 context 中读取 Bean，而不 new City()
|
||||
City city = context.getBean(City.class);
|
||||
|
||||
System.out.println(city.getPeople());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，程序任何地方使用 city 实例，只需要调用 `getBean` 函数，就像一个工厂把实例化过程给承包了，我们不需要关心 City 构造函数要传递什么参数，不需要关心它依赖哪些其他的类，只要这一句话就可以拿到实例，是不是在维护项目时省心了很多。
|
||||
|
||||
## AOP
|
||||
|
||||
AOP（Aspect Oriented Program）面向切面编程。
|
||||
|
||||
AOP 是为了解决主要业务逻辑与次要业务逻辑之间耦合问题的。主要业务逻辑比如登陆、数据获取、查询等，次要业务逻辑比如性能监控、异常处理等等，次要业务逻辑往往有：不重要、和业务关联度低、贯穿多处业务逻辑的特性，如果没有好的设计模式，只能在业务代码里将主要逻辑与次要逻辑混合起来，但 AOP 可以做到主要、次要业务逻辑隔离。
|
||||
|
||||
使用 AOP 就是在定义在哪些地方（类、方法）切入，在什么地方切入（方法前、后、前后）以及做什么。
|
||||
|
||||
比如说，我们想在某个方法前后分别执行两个函数计算执行时间，下面是主要业务逻辑：
|
||||
|
||||
```java
|
||||
@Component("work")
|
||||
public class Work {
|
||||
public void do() {
|
||||
System.out.println("执行业务逻辑");
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
再定义切面方法：
|
||||
|
||||
```java
|
||||
@Component
|
||||
@Aspect
|
||||
class Broker {
|
||||
@Before("execution(* xxx.Work.do())")
|
||||
public void before(){
|
||||
// 记录开始时间
|
||||
}
|
||||
|
||||
@After("execution(* xxx.Work.do())")
|
||||
public void after(){
|
||||
// 计算时间
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
再通过 xml 定义扫描下这两个 Bean，就可以在运行 `work.do()` 之前执行 `before()`，之后执行 `after()`。
|
||||
|
||||
还可以完全覆盖原函数，利用 `joinPoint.proceed()` 可以执行原函数：
|
||||
|
||||
```java
|
||||
@Component
|
||||
@Aspect
|
||||
class Broker {
|
||||
@Around("execution(* xxx.Work.do())")
|
||||
public void around(ProceedingJoinPoint joinPoint) {
|
||||
// 记录开始时间
|
||||
|
||||
try {
|
||||
joinPoint.proceed();
|
||||
} catch (Throwable throwable) {
|
||||
throwable.printStackTrace();
|
||||
}
|
||||
|
||||
// 计算时间
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
关于表达式 `"execution(* xxx.Work.do())"` 是用正则的方式匹配，`*` 表示任意返回类型的方法，后面就不用解释了。
|
||||
|
||||
可以看到，我们可以在不修改原方法的基础上，在其执行前后增加自定义业务逻辑，或者监控其报错，非常适合做次要业务逻辑，且由于不与主要业务逻辑代码耦合，保证了代码的简洁，且次要业务逻辑不容易遗漏。
|
||||
|
||||
## 总结
|
||||
|
||||
IOC 特别适合描述业务模型，后端天然需要这一套，然而随着前端越做越重，如果某个业务场景下需要将部分业务逻辑放到前端，也是非常推荐使用 IOC 设计模式来做，这是后端沉淀了近 20 年的经验，没有必要再另辟蹊径。
|
||||
|
||||
AOP 对前端有帮助但没有那么大，因为前端业务逻辑较为分散，如果要进行切面编程，往往用 `window` 事件监听来做会更彻底，可能这都是前端没有流行 AOP 的原因。当然前端约定大于配置的趋势下，比如打点或监控都集成到框架内部，往往也做到了业务代码无感，剩下的业务代码也就没有 AOP 的需求。
|
||||
|
||||
最后，spring 的低侵入式设计，使得业务代码不用关心框架，让业务代码能够快速在不同框架间切换，这不仅方便了业务开发者，更使得 spring 走向成功，这是前端还需要追赶的。
|
||||
|
||||
> 讨论地址是：[精读《Spring 概念》· Issue #265 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/265)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
|
||||
|
||||
|
||||
@@ -11,17 +11,3 @@
|
||||
## 关注前端精读微信公众号
|
||||
|
||||
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
|
||||
|
||||
## Special Sponsors
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td align="center" valign="middle">
|
||||
<a href="https://e.coding.net/?utm_source=weekly" target="_blank">
|
||||
<img width="300" src="https://img.alicdn.com/tfs/TB107D.QbrpK1RjSZTEXXcWAVXa-1000-332.png">
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
Reference in New Issue
Block a user