Liveblocks项目中react-tiptap组件的FloatingComposer提交事件处理问题分析

在Liveblocks项目的react-tiptap包中，FloatingComposer组件存在一个重要的功能缺陷：其onComposerSubmit属性回调函数无法正常工作。这个问题影响了开发者对该组件的自定义使用，特别是在需要处理评论提交事件时。

问题本质

FloatingComposer组件作为评论编辑器的重要组成部分，本应提供onComposerSubmit回调来允许开发者在用户提交评论时执行自定义逻辑。然而，当前实现中虽然接收了这个属性，但在内部逻辑中完全没有调用它，导致传入的回调函数永远不会被执行。

技术细节分析

在组件内部，handleComposerSubmit函数负责处理表单提交事件。当前实现直接创建新线程并添加到编辑器中，跳过了对onComposerSubmit回调的调用。这与react-lexical包中的实现形成了明显差异，后者正确地调用了这个回调并提供了阻止默认行为的能力。

解决方案建议

正确的实现应该遵循react-lexical包中的模式：

1. 首先调用onComposerSubmit回调
2. 检查事件是否已被阻止默认行为
3. 如果没有被阻止，则继续执行默认的创建线程逻辑

这种模式既保持了向后兼容性，又为开发者提供了足够的灵活性来控制提交行为。

更深层次的问题

这个问题反映出Liveblocks项目中不同编辑器实现之间存在的代码重复问题。TipTap和Lexical的实现存在功能分歧，长期来看应该考虑将核心组件抽象到react-ui包中统一维护，包括：

• 锚定线程组件
• 浮动编辑器组件
• 浮动线程组件

这种重构不仅能解决当前的功能一致性问题，还能降低未来的维护成本。

对开发者的影响

对于使用react-tiptap的开发者来说，当前的问题意味着他们无法：

• 在评论提交前进行自定义验证
• 修改或增强默认的提交行为
• 根据业务需求阻止特定评论的提交

这些限制在需要精细控制评论功能的场景下会造成明显障碍。

总结

虽然这个问题可以通过简单添加回调调用来解决，但它揭示了项目架构上更深层次的优化空间。理想的解决方案应该包括短期修复和长期重构两个层面，既解决当前的功能缺陷，又为未来的功能扩展打下坚实基础。