解决Factory项目中SwiftUI预览模式下的依赖注入问题

背景介绍

在SwiftUI开发中，预览功能(Preview)是一个极其重要的开发工具，它允许开发者实时查看界面效果而无需完整运行应用。然而，当项目采用模块化架构时，特别是在使用依赖注入框架Factory的情况下，预览功能可能会遇到一些挑战。

问题现象

在采用Clean Architecture的多模块项目中，开发者报告了一个典型问题：当Presentation模块作为独立包存在，而App模块负责依赖注入时，SwiftUI预览功能无法正常工作。具体表现为使用@LazyInjected注入依赖时，系统抛出resetAndTriggerFatalError错误，提示某些类型未被注册。

问题根源分析

经过深入分析，发现问题出在Factory的promised方法实现上。该方法原本的设计在DEBUG模式下会检查依赖是否已注册，若未注册则触发错误。然而，这种设计没有考虑到SwiftUI预览模式的特殊情况：

1. 预览模式本质上是DEBUG构建的一部分
2. 但在预览模式下，完整的依赖注册流程可能不会执行
3. 当前的错误触发机制过于严格，没有为预览模式提供特殊处理

解决方案

针对这一问题，社区提出了一个优雅的解决方案：在判断是否触发错误时，不仅检查是否为DEBUG模式，还要额外检查当前是否处于预览模式。具体实现如下：

private var _promiseTriggersError: Bool = FactoryContext.current.isDebug && !FactoryContext.current.isPreview

这一修改的核心思想是：

• 在常规DEBUG模式下保持原有严格检查
• 但在预览模式下放宽限制，允许依赖未注册的情况
• 既保证了开发期的错误检测，又不影响预览功能的使用

实现细节

该解决方案的关键在于FactoryContext提供的环境判断能力。通过检查isPreview属性，我们可以准确识别当前是否运行在预览模式下。这种设计具有以下优点：

1. 精确性：能够准确区分常规DEBUG运行和预览模式
2. 非侵入性：不需要修改现有的依赖注册逻辑
3. 灵活性：为不同环境提供差异化的行为
4. 可维护性：逻辑清晰，易于理解和维护

最佳实践建议

基于这一问题的解决经验，我们建议开发者在处理类似场景时：

1. 始终考虑不同运行环境(DEBUG/RELEASE/Preview)的差异
2. 为预览模式提供适当的容错处理
3. 保持依赖注入逻辑的环境感知能力
4. 在模块化项目中，确保预览目标能够访问必要的测试依赖

总结

Factory 2.4.0版本引入的这一改进，有效解决了SwiftUI预览在多模块项目中的依赖注入问题。这提醒我们，在设计依赖注入系统时，必须充分考虑各种使用场景，特别是像预览这样的特殊开发工具。良好的框架设计应该在保证安全性的同时，不牺牲开发者的工作效率。