经过上一篇 精读《磁贴布局 - 功能分析》 的分析,这次我们进入实现环节。
精读
实现磁贴布局前,先要实现最基础的组件拖拽流程,然后我们才好在拖拽的基础上增加磁贴效果。
基础拖拽能力
对布局抽象来说,它关心的就是 可拖拽的组件 与 容器 的 DOM,至于这些 DOM 是如何创建的都可以不用关心,在这个基础上,甚至可以再做一套搭建或者布局框架层,专门实现对 DOM 的管理,但这篇文章还是聚焦在布局的实现层。
布局组件首先要收集到有哪些可拖拽组件与容器,假设业务层将这些 DOM 生成好传给了布局:
const elementMap: Record<
string,
{
dom: HTMLElement;
x: number;
y: number;
width: number;
height: number;
}
> = {};
const containerMap: Record<
string,
{
dom: HTMLElement;
rectX: number;
rectY: number;
width: number;
height: number;
}
> = {};
elementMap
表示可拖拽的组件信息,包括其 DOM 实例,以及相对于父容器的x
、y
、width
、height
。containerMap
表示容器组件信息,之所以存储rectX
与rectY
这两个相对浏览器绝对定位,是因为容器的直接父组件可能是element
,比如Card
组件可以同时渲染Header
与Footer
,这两个位置都可以拖入element
,所以这两个位置都是container
,它们是相对父element
Card
定位的,所以存储绝对定位方便计算。
接下来给 elementMap
的每一个组件绑定鼠标按下事件作为 onDragStart
时机:
Object.keys(elementMap).forEach((componentId) => {
elementMap[componentId].dom.onmousedown = () => {
// 记录拖拽开始
};
});
然后在 document 监听 onMouseMove
与 onMouseUp
,分别作为 onDrag
与 onDragEnd
时机,这样我们就抽象了拖拽的前、中、后三个阶段:
function onDragStart(context, componentId) {
context.dragComponent = componentId;
}
function onDrag(context, event) {
// 根据 context.dragComponent 响应组件的拖动
// 将 element x、y 改为 event.clientX、event.clientY 即可
}
function onDragEnd(context) {
context.dragComponent = undefined;
}
这样最基础的拖拽能力就做好了,在实际代码中,可能包含进一步的抽象这里为了简化先忽略,比如可能对所有事件的监听进行 Action 化,以便单测在任何时候模拟用户输入。
磁贴布局影响因子
磁贴布局入场后,仅影响 onDrag
阶段。在之前的逻辑中,拖拽是完全自由的,那么磁贴布局就会约束两点:
对当前拖拽组件位置做约束。
可能把其他组件挤走。
对拖拽组件位置的约束是由背后的 “松手 DOM” 决定的,也就是拖拽时 element 是实时跟手的,但如果拖拽位置无法放置,就会在松手时修改落地位置,这个落地位置我们叫做 safePosition
,即当前组件的安全位置。
所以 onDrag
就要计算一个新的 safePosition
,它应该如何计算,由磁贴的碰撞方式决定,我们可以在 onDrag
函数里做如下抽象:
function onDrag(context, event) {
// 根据 context.dragComponent 响应组件的拖动
const { safeX, safeY } = collision(context, event.clientX, event.clientY);
// 实时的把组件位置改为 event.clientX、event.clientY
// 把背后实际落点 DOM 位置改为 safeX、safeY
// onDragEnd 时,再把组件位置改为 safeX、safeY,让组件落在安全的位置上
}
接下来就到了重点函数 collision
的实现部分,它需要囊括磁贴布局的所有核心逻辑。
collision
函数包括两大模块,分别是拖入拖出模块与碰撞模块。拖入拖出判断当前拖拽位置是否进入了一个新容器,或者离开了当前容器;碰撞模块判断当前拖拽位置是否与其他 element
产生了碰撞,并做出相应的碰撞效果。
除此之外,磁贴布局还允许组件按照重力影响向上吸附,因此我们需要做一个 runGravity
函数,把所有组件按照重力作用排列。
function collision(context, x, y) {
// 先做拖入拖出判断
if (judgeDragInOrOut(context, event)) {
// 如果判定为拖入或拖出,则不会产生碰撞,提前 return
// 但是拖出时需要对原来的父节点做一次 runGravity
// 拖入时不用对原来父节点做 runGravity
return { safeX: x, safeY: y };
}
// 碰撞模块
return gridCollsion(context, x, y);
}
为什么拖入时不用对原来父节点做 runGravity: 假设一个 element
从上向下移动入一个 container
,那么一旦拖入 container
就会在其上方产生 Empty 区域,如果此时 container
立即受重力作用挤了上去,但鼠标还没松手,可能鼠标位置又立即落在了 container
之外,导致组件触发了拖出。因此拖入时,先不要立刻对原先所在的父容器作用重力,这样可以维持拖入时结构的稳定。
拖入拖出模块
拖入拖出判断很简单,即一个 element
如果有 x% 进入了 container
就判定为拖入,有 y% 离开了 container
就判定为离开。
碰撞模块
碰撞模块 gridCollsion
比较复杂,这里展开来讲。首先需要写一个矩形相交函数判断两个组件是否产生了碰撞:
function gridCollsion(context, x, y) {
Object.keys(context.elementMap).forEach((componentId) => {
// 判断 context.dragComponent 与 context.elementMap[componentId] 是否相交,相交则认为产生了碰撞
});
}
如果没有产生碰撞,那我们要根据重力影响计算落点 safeY
(横向不受重力作用且一定跟手,所以不用算 safeX
)。此时直接调用 runGravity
函数,传一个 extraBox
,这个 extraBox
就是当前鼠标位置产生的 box,这个 box 因为没有与任何组件产生碰撞,直接判断一下在重力的作用下,该 extraBox
会落在哪个位置即可,这个位置就是 safeY
:
function gridCollision(context, x, y) {
// 在某个父容器内计算重力,同时塞入一个 extraBox,返回这个 extraBox 生效重力后的 Y:extraBoxY
const { extraBoxY } = runGravity(context, parentId, extraBox);
return { safeY: extraBoxY };
}
没有产生碰撞的逻辑相对简单,如果产生了碰撞的逻辑是这样的:
// 是否为初始化碰撞。初始化碰撞优先级最低,所以只要发生过非初始碰撞,与其他组件的初始碰撞也视为非初始碰撞
let isInitCollision = true;
Object.keys(context.elementMap).forEach((componentId) => {
// 判断 context.dragComponent 与 context.elementMap[componentId] 是否相交
const intersect = areRectanglesOverlap();
// 相交
if (intersect.isIntersect) {
// 1. 在 context 存储一个全局变量,判断当前组件之前是否相交过,以此来判断是否要修改 isInitCollision
// 2. 判断产生碰撞后,该碰撞会导致鼠标位置的 box,也就是 extraBox 放到该组件之上还是之下
}
});
首先要确定当前碰撞是否为初始化碰撞,且一旦有一个组件不是初始化碰撞,就认为没有发生初始化碰撞。原因是初始化碰撞的位置判断比较简单,直接根据 source 与 target element
的水平中心点的高低来判断落地位置。如果 source 水平中心点位置比 target 的高,则放到 target 上方,否则放在 target 下方。
如果是非初始化碰撞逻辑会复杂一些,比如下面的例子:
// [---] [ C ]
// [ B ]
// [---]
// ↑
// [-------]
// [ A ]
// [-------]
当 A 组件向上移动时,因为已经与 B 产生了碰撞,所以就会尝试判断合适置于 B 之上,否则永远会把自己锁在 B 的下方。实际上,我们希望 A 的上边缘超过 B 的水平中心点就产生交换,此时 A 的水平中心点还在 B 的水平中心点之下,所以此时按照两种不同的判断规则会产生不同的位置判定,区分的手段就是 A 与 B 是否已经处于相交状态。
现在终于把插入位置算好了(根据是否初始化碰撞,判断 extraBox 落在哪个 element
的上方或者下方),那么就进入 runGravity
函数:
function runGravity(context, parentId, extraBox) {}
这个函数针对某个父容器节点生效重力,因此在不考虑 extraBox
的情况下逻辑是这样的:
先拿到该容器下所有子 element
,对这些 element
按照 y 从小到大排序,然后依次计算落点,已经计算过的组件会计算到碰撞影响范围内,也就是新的组件 y 要尽可能小,但如果水平方向与已经算过的组件存在重叠,那么只能顶到这些组件的下方。
如果有 extraBox
的话,问题就复杂了一些,看下面的图:
// [---] [ C ]
// [ B ]
// [---]
// ↑
// [-------]
// [ A ]
// [-------]
// A 这个 extraBox before B
// 这个例子应该按照 C -> A -> B 的顺序计算重力
// 规则:如果有 before ids(ids y,bottom 都一样),则把排序结果中 y >= ids.y & bottom < ids[0].bottom 的组件抽出来放到 ids 第一个组件之前
// [-------]
// [ A ]
// [-------]
// ↓
// [---] [ C ]
// [ B ]
// [---]
// A 这个 extraBox after B
// 这个例子应该按照 C -> A -> B 的顺序计算重力
// 规则:如果有 after ids(ids y,bottom 都一样),则把排序结果中 y <= ids.y & bottom > ids[0].bottom 的组件抽出来放到 ids 最后一个组件之后
因为 extraBox
是一个插入性质的位置,所以计算方式肯定有所不同。以第一个例子为例:当 A 向上移动并可以与 B 产生交换时,最后希望的结果自上至下是 C -> A -> B,但因为 C 和 B 的 y 都是 0,如果我们把 A 与 B 交换理解为 A 的 y 变成 0 从而把 B 挤下去,那么 A 也会把 C 挤下去,导致结果不对。
因此重要的是计算重力的优先级,上面的例子重力计算顺序应该是先算 C,再算 A,再算 B,这个逻辑的判断依据如上面注释所说。
上面说的都是 isInitCollision=false
的算法,如果 isInitCollision=true
,则 extraBox
按照 y 顺序普通插入即可。原因看下图:
// [-------] [-]
// [ ] [ ]
// [ ] [D]
// [ A ] → [ ]
// [ ] [-]
// [ ] [-----------------]
// [-------] [ ]
// [-----] [ C ]
// [ B ] [ ]
// [-----] [-----------------]
当将 A 向右移动直到与 C 碰撞时,按照 y 来计算重力优先级时结果是正确的。如果按照 extraBox 已产生过碰撞的算法,则会认为 A 放到 C 的上方,但因为 B 相对于 C 满足 y >= ids.y & bottom < ids[0].bottom
,所以会被提取到 C 的前面计算,导致 B 放在了 A 前面,产生了错误结果。因为这种碰撞被误判为 “A 从 C 的下方向上移动,直到与 C 交换,此时 B 依然要置于 A 的上方”,但实际上并没有产生这样的移动,而是 A 与 C 的一次初始化碰撞,因此不能适用这个算法。
总结
因为篇幅有限,本文仅介绍磁贴布局实现最关键的部分,其他比如步长功能,如果后续有机会再单独整理成一篇文章发出来。
从上面的讨论可以发现,在每次移动时都要重新计算 safe 位置的落点,而这个落点又依赖 runGravity
函数,如果每次都要把容器下所有组件排序,并一一计算落点位置的话,时间复杂度达到了 O(n²),如果画布有 100 个组件,就会至少循环一万次,对性能压力是比较大的。因此磁贴布局也要做性能优化,这个我们放到下篇文章介绍。
讨论地址是:精读《磁贴布局 - 功能实现》· Issue #459 · dt-fe/weekly
如果你想参与讨论,请 点击这里,每周都有新的主题,周末或周一发布。前端精读 - 帮你筛选靠谱的内容。
关注 前端精读微信公众号
![93bf9a9e4612e4d4904b8caadf69a220.jpeg](https://i-blog.csdnimg.cn/blog_migrate/1de4f39aa79f0961249e13a8f3d6fec5.png)
版权声明:自由转载-非商用-非衍生-保持署名(创意共享 3.0 许可证)