重新梳理EditableProTable高级表格组件之坑20220122

开发可编辑表格组件的荆棘之路

背景

在2022年1月22日的那个忙碌的周六，我坐在办公室里，拖着同事一起加班。我们正在开发一个表格组件，但是遇到了一个又一个问题。需求文档一变再变，交互设计面目全非，导致组件变得一团糟。更糟糕的是，第三方组件也被改得乱七八糟。产品要求1月24日上线，而我们还有10多个组件bug需要分析。

坑一：可编辑表格的噩梦

业务场景：我们的产品需要一个允许用户自定义创建表结构的功能。用户可以选中表行，点击添加按钮将该行数据作为表头，然后重复此步骤创建后续表头。但是，问题出在我们的接口限制。create接口只能接受20条数据，这意味着表格最多只能有20行。

解决方案：我们修改了create接口，将参数类型从数组更改为对象，允许用户创建无限行数的表结构。

坑二：无状态组件的陷阱

业务场景：我们希望根据不同的用户分组维护不同的表格。我们使用了React函数组件，最初打算用useState来管理数据。然而，我们的接口一次性返回所有表结构数据，因此我们尝试使用useMemo来提升性能。

问题是，当用户创建表结构时，新数据会覆盖现有数据，导致表格数据无法更新。

解决方案：我们放弃了useMemo，转而使用useState来管理表格数据，并通过useEffect同步存储的数据。

坑三：防抖的误区

业务场景：用户需要修改表格中的数据，在修改前会弹出一个确认模态框。我们为输入框绑定了onInput事件，并使用防抖来处理数据请求。

但是，我们犯了一个错误，将onInput事件作为useMemo的依赖项。这导致onInput函数内部的值在每次渲染时都被重置，从而无法发送请求。

解决方案：我们将onInput事件保留为依赖项，并引入一个变量来跟踪输入值。然后，我们在防抖函数中使用useCallback将此变量作为参数传递。最后，我们在useEffect中将变量值传递到后台接口。

坑四：业务逻辑的混乱

业务场景：我们最初根据需求文档开发了表格结构。文档中规定了数据类型的限制，例如第一列必须是数字，第二列必须是字符串，第三列必须是日期。

然而，业务人员违背了这些规则，将第一列数据类型更改为多行文本。这导致多行文本无法在表格中正确显示，破坏了表格布局。

解决方案：我们对业务人员进行了培训，强调遵守需求文档的重要性。同时，我们还改进了组件中的校验规则，以防止业务人员再次出现类似情况。

总结

开发可编辑表格组件是一个充满挑战的过程。我们遇到了许多坑，但我们一一克服了这些困难，最终完成了组件的开发。希望这篇博客能够帮助其他开发者避免类似的问题。

附录

• 可编辑表格组件 ：一种用于创建和编辑表格的React组件，具有高级功能，如可编辑单元格、可拖动列等。
• 产品业务逻辑 ：定义产品功能和行为的规则。
• 交互 ：用户与产品之间的互动。
• 业务流程 ：完成任务的步骤。
• 第三方组件 ：由其他开发者编写的组件，用于扩展产品功能。
• UED ：用户体验设计，关注产品的外观和用户交互。
• 产品要求 ：产品必须满足的功能和特性。
• 上线 ：产品发布并可供用户使用。
• 组件 ：产品中的小部件。
• bug分析 ：分析产品中错误的过程。
• 业务变更 ：产品需求或功能的变化。

常见问题解答

问：为什么可编辑表格组件会如此困难？

答：可编辑表格组件涉及许多复杂的逻辑和交互，例如数据校验、行添加和删除、排序和过滤。此外，与后台系统的集成也增加了复杂性。

问：有哪些技巧可以简化可编辑表格组件的开发？

答：使用组件库或框架可以提供开箱即用的功能，例如排序和过滤。此外，遵循最佳实践，例如单元格虚拟化和防抖，可以提高性能。

问：如何确保可编辑表格组件的健壮性？

答：全面测试组件，包括各种用户输入和场景，对于确保组件的健壮性至关重要。此外，使用类型检查器可以防止数据类型错误。

问：可编辑表格组件有哪些常见用例？

答：可编辑表格组件广泛用于数据管理、电子表格和CRM系统等应用程序中。

问：未来可编辑表格组件的趋势是什么？

答：可编辑表格组件未来将继续朝着提高性能、提供高级功能（例如拖放行）和整合人工智能（例如自动完成）的方向发展。