基于React构建多设备状态展示组件的最优方案探讨

场景回顾 #

需开发React表格组件展示多设备状态，包含IP、名称等属性，每个设备轮询耗时数秒，要求单独显示单设备的加载状态。现有两种接口方案：

1. 单设备信息接口（GET /device_info）：前端发起多并行请求
2. 全量设备信息接口（GET /devices_info）：前端发起单次请求

两种方案的优缺点已明确：

• 方案一：易实现，可基于React Query/RTK Query快速构建行级并行请求；但请求数量多，服务端共享资源同步难度大
• 方案二：单次请求，服务端无共享资源同步问题；但实现复杂，需处理多设备的不同状态及周期性更新

1. 哪种方案更适合构建该组件？ #

需结合设备规模和业务需求判断：

• 设备数量少（≤20台）：优先选方案一。React Query/RTK Query的行级查询能力可以快速实现单设备加载状态，开发成本低，且单个设备的轮询间隔可灵活调整（比如部分设备无需高频轮询）。
• 设备数量多（≥50台）：必须选方案二。大量并行请求会导致服务端压力激增、浏览器请求队列阻塞，全量接口能避免这些问题，同时服务端可一次性批量处理设备状态查询，效率更高。
• 特殊业务场景：如果不同设备的状态更新频率差异大，方案一的灵活性更适配；如果设备状态依赖共享资源查询，方案二能避免服务端重复计算资源，减少同步问题。

2. 最优方案是否对应特定设计模式？ #

两种方案分别对应不同的设计模式：

• 方案一：对应组件级数据获取模式，将数据查询逻辑下沉到表格行组件中，每个行组件独立管理自身的查询、加载状态和轮询逻辑。结合React Query/RTK Query的缓存机制，本质是利用了缓存优先模式，减少重复请求。
• 方案二：对应数据归一化与状态分片模式，全量获取数据后，将设备状态按ID拆分存储，单独管理每个设备的加载、更新状态。同时轮询逻辑可采用观察者模式，监听全局轮询触发，更新对应设备的状态；如果需要精细化控制单个设备的轮询，可结合策略模式，为不同设备设置不同的更新策略。

3. 有无相关优质参考资料？ #

• React Query官方文档：并行查询、行级查询、缓存管理相关章节
• RTK Query官方文档：批量请求处理、缓存归一化、自定义轮询配置内容
• React官方状态管理指南：组件级状态与全局状态的边界划分
• RESTful接口设计规范：批量数据获取的最佳实践

内容的提问来源于stack exchange，提问作者Evgen