OHIF Viewer自定义路由配置中的PUBLIC_URL问题解析

问题背景

在OHIF医学影像查看器的开发过程中，开发者发现了一个关于自定义路由配置的重要变更。在最新版本中，定义自定义路由时需要在路径中包含PUBLIC_URL，这与之前版本的行为有所不同。

问题现象

开发者报告称，在构建OHIF Viewer时如果设置了PUBLIC_URL（例如"/viewer-ohif/"），那么在定义自定义路由时必须显式包含这个前缀。例如：

{
  path: `/viewer-ohif/login`,
  children: () => RootGaelO(),
  private: true,
}

而在之前的版本中，可以直接使用相对路径：

{
  path: `/login`,
  children: () => RootGaelO(),
  private: true,
}

这种变化导致了路由定义与构建上下文产生了耦合，使得相同的代码无法在不同环境中直接复用。

技术分析

经过深入分析，这个问题源于OHIF Viewer的路由系统实现方式。在平台代码中，自定义路由是通过以下机制工作的：

1. 路由配置首先在应用初始化时被收集
2. 这些路由被应用到React Router的配置中
3. 最终路由会与routerBasename（通常就是PUBLIC_URL）结合使用

在最新版本中，路由匹配变得更加严格，要求路径必须完全匹配，包括基础路径部分。

解决方案

开发者发现可以通过动态获取window.PUBLIC_URL来解决这个问题：

{
  path: `${window.PUBLIC_URL}login`,
  children: () => RootGaelO(),
  private: true,
}

这种方法有几个优点：

1. 保持了路由定义的灵活性
2. 自动适应不同的构建环境
3. 不需要硬编码PUBLIC_URL值

最佳实践建议

基于这个问题的分析，我们建议开发者在OHIF Viewer项目中定义自定义路由时：

1. 总是使用window.PUBLIC_URL作为路径前缀
2. 避免在路由定义中硬编码环境相关的路径
3. 在文档中明确说明路由定义的要求

总结

这个问题的出现反映了前端路由配置中常见的基础路径处理挑战。通过使用动态的PUBLIC_URL，开发者可以创建更加灵活、可移植的路由配置，确保应用在不同部署环境下都能正常工作。这也提醒我们在设计路由系统时，需要考虑环境变量的注入方式和路由匹配的严格程度。