Skip to content

Latest commit

 

History

History
361 lines (283 loc) · 11.9 KB

265.精读《磁贴布局 - 功能分析》.md

File metadata and controls

361 lines (283 loc) · 11.9 KB

磁贴布局三部曲:功能分析、实现分析、性能优化的第一部 - 功能分析。

因为需要做自由布局与磁贴布局混排,以及磁贴布局嵌套,所以要实现一套磁贴分析功能,所以本系列不是简单的介绍使用 react-grid-layout 这个库就行了,而是深入分析磁贴布局的特性,以及重头实现一遍。

对磁贴布局不熟悉的话,react-grid-layout 也是个很好的 Demo 体验页,大家可以先体验一下再阅读文章。

精读

简单碰撞

磁贴布局最重要的就是碰撞了,用过 Demo 就会发现,磁贴左右不会碰撞,只有上下会产生碰撞,这是因为网页天然是从上而下阅读的,因此垂直碰撞比水平碰撞更自然。

那么垂直的碰撞方向是什么样的呢?实际上只有自上而下的碰撞,没有自下而上的碰撞

为了讲清楚这个原理,先看下面的例子:

[-----]   [-----]
|  A  | → |  B  |
[-----]   [-----]

如上所示,将方块 A 移动到方块 B 的位置,如果此时 A 的 Y 轴位置小于等于 B,则会将 B 挤下去。结果如下所示:

          [-----]
          |  A  |
          [-----]
          [-----]
          |  B  |
          [-----]

如果 A 的 Y 轴位置比 B 大,则碰撞结果是 A 跑到了 B 的下面:

          [-----]
[-----]   |  B  |
|  A  | → [-----]
[-----]

结果如下所示:

          [-----]
          |  B  |
          [-----]
          [-----]
          |  A  |
          [-----]

如果 A 挤到 B 和 C 中间会如何呢?见下图:

          [-----]
[-----]   |  B  |
|  A  | → [-----]
[-----]   [-----]
          [  C  ]
          [-----]

很容易想到,A 会落到 B 与 C 的中间位置。那问题来了,实现的时候,当时 A 放到 B 的下方,还是认为 A 放到 C 的上方?

乍一看会觉得,这不一样吗?对这个例子来说是的,但对其他例子就不同了。实际上应该始终认为是 A 放到了 B 的下方。原因的话,我们举一个反例就行,假设认为 A 放到了 C 的上方,那么看下面的例子:

          [-----]
[-----]   |  B  |
|  A  | → [-----]
[-----]       [    X    ]
          [-----]
          [  C  ]
          [-----]

如上图所示,B 和 C 中间夹了一个狭长的 X,此时 A 拖入 B 和 C 的中间,并未与 X 产生碰撞,那结果一定是 A 落在了 B 的下方。如果落在 C 的上方,A 就悬空了。

所以磁贴布局模式下,组件始终只能落在另一个组件下面,除了 Y 轴为 0 的情况下,可以定到组件上方。

连续碰撞

连续碰撞是指当磁贴布局产生碰撞而导致位置变化后,需要重新调整整体位置,或者继续与其他组件位置产生碰撞的情况,首先看下面这个简单例子:

[-----]
|  A  |
[-----]
   ↓
[-----]
|  B  |
[-----]
[-----]
|  C  |
[-----]

如果把 A 拖动到 B 位置,遵循简单碰撞原理,必须 Y 轴高于 B 的 Y 轴才会置于 B 下方,此时会把 C 顶上去。但仅做到这一步,A 原来的位置会产生空缺,需要重新吸附到顶部,这就是连续碰撞:

[     ]                    [-----]
|Empty|                    |  B  |
[     ]                    [-----]
[-----]                    [-----]
|  B  |                    [  A  ]
[-----] → Remove Empty     [-----]
[-----]                    [-----]
|  A  |                    [  C  ]
[-----]                    [-----]
[-----]
|  C  |
[-----]

这时候你可能会想,结果不就是 B 和 A 交换了位置嘛,实际上用 react-grid-layout 看起来效果也是如此,那么代码实现时是不是不用这么麻烦?直接判断 A 与 B 是否产生位置交换,如果交换了,按照交换的方式处理不就行了吗?

听上去很美好,因为按照 A 与 B 交换的思路处理效果一致,而且性能更优,因为不用重新计算 C 组件被挤走,然后 A、B、C 再重新挤上去。但实际上交换方案是不可行的,我们看下面的例子:

        [-----]
        |  A  |
        [-----]
           ↓
[-------------]
|      B      |
[-------------]
[-----]
|  C  |
[-----]

如果把 A 和 B 位置交换,会发现 C 悬空了。之所以上面的例子可以用交换思路,是因为 A 与 B 交换后,A 还可以 “挡住” C 的上移。但这个例子因为 B 很长,但 A 很短,A、B 交换后,A 就挡不住 C 的上移了:

[-------------]
|      B      |
[-------------]
[-----] [-----]
|  C  | |  A  |
[-----] [-----]

所以为了保证任何时候位移都不会产生 BUG,需要老老实实的分两步来判断:1. 判断 A 移到 B 的底部。2. 新的 A 把下面组件挤走,同时如果上面还有空位置,需要整体向上位移。

看起来还是比较消耗性能的,但通过一些优化手段是可以极大减少计算量的,我们到系列的 “性能优化” 部分再说。

碰撞边界 case

我们再考虑两个极端情况,第一种是要碰撞的组件过于矮的时候,第二种是要碰撞的组件过高的时候。

首先是过矮的情况,我们看下面 5 种情况:

[-----]
|     | ← [ A ]
|  B  |
|     |
[-----]
[-----]
|     |
|  C  |
|     |
[-----]

上面的情况插入到 B 的上方(假设 B 上方没有元素了,如果有的话,假设 B 上方为 X,那么应该认为 A 插入到 X 的底部)。

[-----]
|     |
|  B  |
|     | ← [ A ]
[-----]
[-----]
|     |
|  C  |
|     |
[-----]

上面的情况插入到 B 的下方。

[-----]
|     |
|  B  |
|     |
[-----]
[-----]
|     | ← [ A ]
|  C  |
|     |
[-----]

上面的情况插入到 B 的下方。

[-----]
|     |
|  B  |
|     |
[-----]
[-----]
|     |
|  C  |
|     | ← [ A ]
[-----]

上面的情况插入到 C 的下方。

[-----]
|     |
|  B  |
|     |   [---]
[-----] ← [ A ]
[-----]   [---]
|     |
|  C  |
|     |
[-----]

上面的情况和简单碰撞里提到的例子一样,碰撞位置在 B 与 C 之间,还是会认为插入到 B 的下方。

总结一下,过矮的情况下很多时候拖动组件只会与一个组件产生碰撞,当拖拽中心点在碰撞组件中心点上方时,插入到碰撞组件上方的组件下面(如果上方没有组件则插入到顶部)。当然插入到上方组件下面也不是真的找到上方组件是什么,具体如何做我们等到【实现分析】篇再讲。反之,如果中心点相对在下方,就插入到碰撞组件的下方。如果同时碰撞了多个组件,则忽略中心点偏移量靠上的碰撞,仅考虑中心点偏移量靠下的碰撞。

关于中心点上方其实也可以进一步优化,比如当目标碰撞组件太长的时候,可能比较难移到下方,此时在还没有拖拽到中心点下方时就要做下方碰撞判定了,此时判断依据可以优化为:碰撞时,拖拽组件的 Y 只要比目标组件的 Y 大(或者再加一个常数阈值,该阈值由拖拽组件高度决定,比如是高度的 1/3),那么就认为拖入到目标组件底部,比如:

[-----]
|     |   [---]
|     | ← [ A ]
|  B  |   [---]
|     |
|     |
[-----]

如上图所示,虽然 A 的中心点在 B 中心点上方,但因为 A.y - B.y > A.height / 3,所以判定插入到 B 的下方。当然这也会导致拖入超高组件上方很困难,所以要不要这么设定看用户喜好。

再看组件过高的情况:

          [---]
[-----]   [   ]
|  B  | ← [ A ]
[-----]   [   ]
[-----]   [---]
|  C  |
[-----]

上面的情况插入 B 的上方(如果 B 上面还有组件 X,则判定为插入该 X 下方)。

[-----]   [---]
|  B  |   [   ]
[-----] ← [ A ]
[-----]   [   ]
|  C  |   [---]
[-----]

上面的情况插入 B 的下方。

[-----]
|  B  |
[-----]
[-----]   [---]
|  C  |   [   ]
[-----] ← [ A ]
          [   ]
          [---]

上面的情况插入 C 的下方。

总结一下,当拖拽组件过高时,还是维持中心点判断规则,但更可能同时碰撞到多个组件,此时沿用 “中心点偏移量靠上的碰撞” 的原则就行了。但这里有一个较大的区别,拖拽组件矮的时候最多同时和两个组件碰撞,但拖拽组件高的时候,可能同时和 N 个组件碰撞,如下图所示:

[-----]   [---]
|  B  |   [   ]
[-----]   [   ]
[-----]   [   ]
|  C  |   [   ]
[-----] ← [ A ]
[-----]   [   ]
|  D  |   [   ]
[-----]   [   ]
[-----]   [   ]
|  E  |   [---]
[-----]

此时就要看和哪个组件碰撞的优先级最高了。我们单从 B、C、D、E 的角度看,A 分别应该放在 B 下方、C 下方、D 上方、E 上方,其中 B 下方与 C 上方是同一个位置,但与 D 上方、E 上方都不是同一个位置,此时就要看拖拽到哪个位置产生的位移最小了,因为最小的位移是最不突兀的,最符合用户的预期。

另一个边界情况就是拖拽组件过高时,如果中心点还未移动到下方,但高度却超出了下面组件下方,也要视为拖拽到下方:

[-----]
|     |
|     |
|     |
|  A  |
|     |
|     |
|     |
[-----]
   ↓
[-----]
|  B  |
[-----]

如上图所示,A 非常高,B 很矮,当 A 往下移动时,可能 A 的底部都超出 B 底部了(可以优化为 B 的中间),但 A 的中心点仍然在 B 中心点上方,此时在用户已经认为可以交换位置了,所以判断是否移动到下方多了一个优先判断条件:拖拽组件底部超出目标组件底部。同理拖拽到上方也类似。

要注意的是,这个例子与下面的例子表现并不一致,下面的例子 A 向左移时,应该放置 B 的上方,而上面的例子却放置 B 的下方:

          [-----]
          |     |
          |     |
          |     |
        ← |  A  |
[-----]   |     |
|  B  |   |     |
[-----]   |     |
          [-----]

发现了吗?单从垂直位置来看,都是 A 的底部超过了 B 底部,但有时候和 B 互换,有时候却不互换。区分方法就是该碰撞发生时,这两个区块是否已经发生过碰撞。如果未发生过碰撞则严格根据中心点偏移量判断,偏移量靠上则放在上方,反之下方;已经处于碰撞状态则根据顶部或底部判断,顶部超出目标中心点则放上方,底部超出目标中心点则放下方。

碰撞边界与静态区块

如果没有静态组件,碰撞边界就只有容器顶部。加上静态组件后,产生位移时要判断加上一段位移是否会把静态组件挤走,如果会挤走,则该拖拽位置无效。

固定步长

磁贴布局为了方便对齐,往往会把父容器切割为 12 或者 6 等分,此时拖拽位置就不会完全跟手,当拖拽没有超过临界点的时候,实际拖拽位置不会跟随移动。

总结

磁贴布局的功能主要聚焦在组件间碰撞逻辑上,目标是让用户能够自然的布局,所以组件间碰撞逻辑也要尽可能自然,符合直觉。

讨论地址是:精读《磁贴布局 - 功能分析》· Issue #458 · dt-fe/weekly

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

关注 前端精读微信公众号

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