Skip to content

Latest commit

 

History

History
243 lines (182 loc) · 12.5 KB

266.精读《磁贴布局 - 功能实现》.md

File metadata and controls

243 lines (182 loc) · 12.5 KB

经过上一篇 精读《磁贴布局 - 功能分析》 的分析,这次我们进入实现环节。

精读

实现磁贴布局前,先要实现最基础的组件拖拽流程,然后我们才好在拖拽的基础上增加磁贴效果。

基础拖拽能力

对布局抽象来说,它关心的就是 可拖拽的组件容器 的 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 实例,以及相对于父容器的 xywidthheight
  • containerMap 表示容器组件信息,之所以存储 rectXrectY 这两个相对浏览器绝对定位,是因为容器的直接父组件可能是 element,比如 Card 组件可以同时渲染 HeaderFooter,这两个位置都可以拖入 element,所以这两个位置都是 container,它们是相对父 element Card 定位的,所以存储绝对定位方便计算。

接下来给 elementMap 的每一个组件绑定鼠标按下事件作为 onDragStart 时机:

Object.keys(elementMap).forEach((componentId) => {
  elementMap[componentId].dom.onmousedown = () => {
    // 记录拖拽开始
  };
});

然后在 document 监听 onMouseMoveonMouseUp,分别作为 onDragonDragEnd 时机,这样我们就抽象了拖拽的前、中、后三个阶段:

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 阶段。在之前的逻辑中,拖拽是完全自由的,那么磁贴布局就会约束两点:

  1. 对当前拖拽组件位置做约束。
  2. 可能把其他组件挤走。

对拖拽组件位置的约束是由背后的 “松手 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

如果你想参与讨论,请 点击这里,每周都有新的主题,周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

版权声明:自由转载-非商用-非衍生-保持署名(创意共享 3.0 许可证