React Cosmos 在 Next.js 中处理 window/document 未定义问题的解决方案

问题背景

在使用 React Cosmos 进行组件开发时，开发者在 Next.js 环境下遇到了 window 或 document 全局变量未定义的问题。这是一个典型的服务端渲染(SSR)与客户端渲染(CSR)环境差异导致的问题。

问题本质

Next.js 默认支持服务端渲染，而 window 和 document 是浏览器环境特有的全局对象，在 Node.js 服务端环境中并不存在。当 React Cosmos 尝试在服务端渲染这些组件时，就会抛出引用错误。

解决方案

1. 使用客户端组件指令

Next.js 14+ 提供了明确的客户端组件标记方式。在组件文件顶部添加以下指令：

'use client'

这会明确告知 Next.js 该组件仅在客户端渲染，从而避免服务端渲染时访问浏览器 API。

2. 动态导入组件

对于需要访问浏览器 API 的组件，可以采用动态导入的方式：

import dynamic from 'next/dynamic'

const ClientComponent = dynamic(
  () => import('./ClientComponent'),
  { ssr: false }
)

这种方式特别适合与 React Cosmos 配合使用，因为它可以确保组件只在客户端环境中加载。

3. 条件性访问浏览器 API

在组件内部，可以通过检查运行环境来安全地访问浏览器 API：

if (typeof window !== 'undefined') {
  // 安全地使用 window 或 document
}

或者使用 useEffect 钩子确保代码只在客户端执行：

useEffect(() => {
  // 这里可以安全地使用浏览器 API
}, [])

最佳实践建议

1. 明确组件边界：将与浏览器 API 交互的逻辑封装在独立的客户端组件中
2. 错误处理：对可能缺失的浏览器 API 提供优雅降级方案
3. 测试策略：在 React Cosmos 中为这些组件编写特定的测试用例
4. 文档注释：在组件中明确标注其运行环境要求

总结

React Cosmos 与 Next.js 的集成需要特别注意运行环境的差异。通过合理使用客户端组件标记、动态导入和环境判断，可以优雅地解决浏览器 API 访问问题，同时保持组件在 React Cosmos 中的可测试性和开发体验。

对于复杂的场景，建议将浏览器相关的逻辑抽象为独立的 Hook 或高阶组件，这样可以更好地管理环境依赖并提高代码的可维护性。