React DnD

我非常推荐大家阅读原文 React Dnd Tutorial在新窗口打开，

Dan 是少数几个给我启发最大并且我还记得住名字的作者。

在教程中他不仅仅讲述了如何使用 React-Dnd 更重要的是展现了他如何编写前端程序的思维方式。

思维方式

方向或者顺序
- 从下而上，从细节到抽象
- 始终能看得到程序的变化
- 为了能让细节能工作，在抽象层面可以做一些临时的方案
  - 例如往 Board 棋盘对象里面传递一个 Knight 骑士 🐴 的位置
- 先从简单的规则开始再到具体复杂的规则
  - 例如先实现一个旗子的移动再增加移动的约束
先目的，后技术
- 最终的方案不是一撮而就
- 先有需求（目的）
- 后有技术，选择合理的技术方案
状态设计
- 什么是 props，是不是必要的
- 什么是 states，到底有多少个相关的业务状态

APP 设计细节

i vs [x,y]
- 如果我来设计一个关于格子位置的入参我大概率会先考虑 [x,y]，我觉得这样简单直观符合语义
- 但是再仔细一想， i 从数据结构上来讲更简单，而且 [x,y] 更像是派生状态而不是原始的状态
observe
- 我加上我个人的理解，拖拽可以理解成 UI交互的两个状态，一个是起始位置，一个是终点位置
- 对于棋子而言我只需知道我的下一个位置然后我正确的渲染到这个位置即可
- 这样一来一个简单的事件订阅完全就能满足引入 Drag and Drop API 前，游戏状态的设计需求
Square 的位置
提示
If a component doesn't need some data for rendering, it doesn't need that data at all.
- 位置是不是应该是 Square 的 Props 一直是 Dan 抓住的矛盾主线。这确实很重要。不到万不得已不要轻易给一个 组件 增加不必要的状态(数据)

Dnd 接口设计

useDrag

function Knight() {
  const [{isDragging}, drag] = useDrag(() => ({
    type: ItemTypes.KNIGHT,
    collect: monitor => ({
      isDragging: !!monitor.isDragging(),
    }),
  }))

  return (
    <div
      ref={drag}
      style={{
        opacity: isDragging ? 0.5 : 1,
        fontSize: 25,
        fontWeight: 'bold',
        cursor: 'move',
      }}
    >
      ♘
    </div>,
  )
}

In & Out
- In
  - type
    - 给予被拖拽元素一个类型标识
  - collect callback
    - 你可以根据这个回调访问 dnd 的核心接口，从而自定义你需要的状态
    - 换句话说 dnd 不关系你程序的具体业务状态比如 isDragging , 相反是你自己基于 monitor.isDragging() 接口计算了这个状态
- Out
  - drag
    drag 是一个 ref，所以它也不单纯是输出也可以看做是输入，将被拖拽的元素传入到 useDrag hook
  - {}
    - isDragging 是自定义的状态

useDrop

function BoardSquare({ x, y, children }) {
  const black = (x + y) % 2 === 1;
  const [{ isOver, canDrop }, drop] = useDrop(
    () => ({
      accept: ItemTypes.KNIGHT,
      drop: () => moveKnight(x, y),
      canDrop: () => canMoveKnight(x, y),
      collect: (monitor) => ({
        isOver: !!monitor.isOver(),
        canDrop: !!monitor.canDrop(),
      }),
    }),
    [x, y]
  );

  return (
    <div
      ref={drop}
      style={{
        position: "relative",
        width: "100%",
        height: "100%",
      }}
    >
      <Square black={black}>{children}</Square>
      {isOver && !canDrop && <Overlay type={OverlayType.IllegalMoveHover} />}
      {!isOver && canDrop && <Overlay type={OverlayType.PossibleMove} />}
      {isOver && canDrop && <Overlay type={OverlayType.LegalMoveHover} />}
    </div>
  );
}

In & Out
- In
  - accept
    - 对应 useDrag 传入的 type
  - canDrop callback
    - 是否可以放下
    - 依赖于 上下文 信息
  - drop callback
    - 放下后执行的回调
  - collect callback
    - 和 useDrag 一样你也需要自己定制你需要的业务状态
    - 通过访问 monitor 的 API
- Out
  - drop
    drop 是一个 ref，所以它也不单纯是输出也可以看做是输入，将可被落下的元素传入到 useDrop hook
- {}
  - isOver 是自定义的状态
  - canDrop 是自定义的状态

小结

Dnd 的接口设计

基于 hook
相对于常见的 hook 接口设计无疑是比较复杂的
- 这里返回的第一个参数无疑非常有趣
  - 你可以理解不是 dnd 设计接口而是用户自己！只不过你需要通过 monitor 的 API 来计算每个接口属性
- 当你熟悉了这个接口你又会认为这个设计无疑是足够抽象简洁
  - 没有对比，没有伤害
  - 业务复杂（拖拽），接口不可能简单
  - 不简单不意味着不简洁
Drag
- 关注
  - 拖动元素的类型
Drop
- 关注
  - 可接受的拖动元素的类型（能放下）
  - 是否可以接受的放下操作的回调（允许放下）
  - 放下后的后续动作的回调
换句话说
- 我们关心
  - 什么被拖动了
  - 什么能够被放下
  - 什么情况下允许被放下
  - 放下后的后续操作

# React DnD

# 思维方式

# APP 设计细节

# Dnd 接口设计

# useDrag

# useDrop

# 小结

React DnD

思维方式

APP 设计细节

Dnd 接口设计

useDrag

useDrop

小结