Lichess移动端棋盘坐标训练器的触摸事件处理优化

在Lichess移动端应用(lichess-org/mobile)的坐标训练功能中，开发者发现了一个关于触摸事件处理的交互问题。这个问题涉及到用户在棋盘上滑动手指时，系统会持续触发坐标选择事件，而实际上应该只在单次点击时响应。

问题背景

坐标训练是国际象棋学习中的一个重要功能，它帮助棋手快速识别棋盘上的坐标位置。在移动设备上，这个功能通常通过触摸屏幕上的棋盘格子来实现。然而，当前实现中存在一个不太符合用户预期的行为：当用户在棋盘上滑动手指时，系统会持续触发坐标选择事件，而不是只在初始点击时响应一次。

技术分析

这个问题源于底层棋盘编辑器组件(chessground)的事件处理机制。在当前的实现中：

1. 坐标训练屏幕(CoordinateTrainingScreen)通过onGuess方法处理用户的选择
2. 这个方法被传递给棋盘编辑器(BoardEditor)的onEditedSquare回调
3. 棋盘编辑器组件在_ontouchedEvent处理中，对触摸和拖动事件都调用了相同的回调

这种设计原本是为了支持棋盘编辑功能——比如当用户需要快速删除多个棋子时，滑动手指可以连续触发删除操作。然而，这种机制并不适合坐标训练场景。

解决方案探讨

开发团队提出了两种可能的解决方案：

1. 扩展编辑器指针模式：在EditorPointerMode枚举中添加新的模式，专门用于坐标训练场景。这种方案保持了组件的灵活性，同时为不同使用场景提供专门的行为。

2. 使用专门的点击回调：为Chessboard组件添加onTappedSquare回调，完全绕过BoardEditor组件的事件处理机制。这种方法更直接，但可能意味着需要重构部分代码结构。

实现考量

在决定最终解决方案时，需要考虑以下因素：

• 组件复用性：保持棋盘组件在不同场景下的通用性
• 用户体验一致性：确保交互行为符合用户预期
• 代码维护性：选择易于理解和维护的实现方式

经过讨论，团队倾向于第一种方案，因为它既解决了当前问题，又保持了组件的灵活性，为未来可能的其他交互模式预留了扩展空间。

总结

这个案例展示了在移动应用开发中，通用组件设计与特定场景需求之间的平衡艺术。通过分析用户交互的预期行为，并灵活调整底层实现，开发团队能够提供更加符合直觉的用户体验。这也提醒我们，在组件设计时考虑不同使用场景的重要性，以及如何通过合理的架构设计来支持这种灵活性。