WordPress Gutenberg数据存储中resolveSelect与select的演进与最佳实践

背景介绍

在WordPress Gutenberg项目中，数据管理是一个核心功能。随着项目的发展，数据存储相关的API也在不断演进。最近一个重要的变化是关于select和resolveSelect控制器的使用方式变更，这对开发者构建自定义数据存储产生了显著影响。

问题起源

在Gutenberg 5.7版本之前，开发者通常使用@wordpress/data-controls包中的select控制器来处理数据存储的异步操作。然而，从5.7版本开始，这个控制器被标记为弃用，官方推荐改用@wordpress/data包内置的resolveSelect控制器。

这种变更导致了一些开发者在迁移过程中遇到问题，特别是当他们在Redux数据存储解析器中使用生成器函数时。原本正常工作的代码在替换为resolveSelect后出现了功能异常。

技术分析

select与resolveSelect的区别

1. select控制器：

   • 位于@wordpress/data-controls包中
   • 主要用于生成器函数中
   • 通过yield关键字调用
   • 在5.7版本后被标记为弃用

2. resolveSelect控制器：

   • 直接内置在@wordpress/data包中
   • 设计用于更现代的异步处理方式
   • 可以与async/await语法配合使用
   • 是官方推荐的替代方案

类型系统问题

开发者还注意到resolveSelect的类型定义不够完善，相比自定义数据存储中为select创建的类型重载，resolveSelect的类型提示体验较差。这增加了迁移的复杂度。

解决方案演进

从生成器到Thunk的转变

Gutenberg核心团队推荐了一种更现代的解决方案：使用Thunk替代生成器函数。Thunk是Redux中处理异步逻辑的标准方式，相比生成器具有以下优势：

1. 更简单的语法：不需要处理yield和生成器函数
2. 更好的类型支持：与TypeScript配合更自然
3. 更直观的流程：代码结构更接近常规异步函数

迁移实践

对于需要从生成器迁移到Thunk的开发者，可以遵循以下步骤：

1. 将生成器函数改为普通异步函数
2. 使用async/await替代yield
3. 直接调用resolveSelect而不是通过控制流
4. 确保正确处理Promise和错误情况

最佳实践建议

1. 新项目开发：直接使用Thunk和resolveSelect的组合
2. 现有项目迁移：
   • 评估影响范围
   • 分阶段逐步替换
   • 优先处理关键路径
3. 类型系统优化：为自定义存储创建类型扩展，改善开发体验

总结

WordPress Gutenberg项目中的数据管理API正在向更现代、更简洁的方向发展。虽然从生成器和select控制器迁移到Thunk和resolveSelect需要一定的重构工作，但最终会带来更好的开发体验和更可维护的代码结构。

对于正在使用自定义数据存储的开发者，建议尽快规划迁移路线，利用Thunk的简洁性和resolveSelect的官方支持，构建更健壮的编辑器扩展功能。