尧图网站建设 
Langfuse 前端实践Lift State into Provider——在 React 19 中把状态提升进 Provider 组件的组合模式指南【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse把状态放进专属的 Provider 组件而非散落在 UI 组件内部是构建可组合、可维护 React 组件的核心手段之一。本指南以 langfuse 仓库内置的 Vercel Composition Patterns 技能中的state-lift-state规则为主线完整拆解三种常见错误写法与正确的 Provider 提升方案并结合作者仓库的 React 19.2.4 环境与实际 Context 源码如 CommandMenuProvider.tsx帮助你在项目里让不在同一视觉层级的兄弟组件也能安全共享状态与动作摆脱 prop drilling 与 ref 黑盒。规则定位State 管理四类模式中的一席在 langfuse 仓库的 web/.agents/skills/vercel-composition-patterns 中React 组合模式被划分为四个优先级类别Component ArchitectureHIGH、State ManagementMEDIUM、Implementation PatternsMEDIUM与 React 19 APIsMEDIUM。本次讲解的state-lift-state属于State Management状态管理类别与另外两条规则构成完整的状态组合方案state-decouple-implementationProvider 是唯一知道状态如何被管理的组件state-context-interface用state/actions/meta三段式泛型接口支撑依赖注入state-lift-state本文把状态搬进 Provider 组件实现组件边界之外的状态共享。该规则文件的 frontmatter 明确标注了impact: HIGH其影响描述为 enables state sharing outside component boundaries即让状态共享突破组件视觉边界。问题场景转发消息对话框里的状态困局规则以一个非常贴近真实业务的前向转发消息Forward Message对话框为例。界面结构大致如下function ForwardMessageDialog() { return ( Dialog ForwardMessageComposer / MessagePreview / {/* 需要访问 composer 的状态 */} DialogActions CancelButton / ForwardButton / {/* 需要触发提交 */} /DialogActions /Dialog ) }MessagePreview消息预览和ForwardButton转发按钮在视觉上并不位于ForwardMessageComposer消息输入框内部却需要读取输入内容、触发提交动作。规则依次否定了三种想当然的写法。错误一状态被困在组件内部state trapped inside componentfunction ForwardMessageComposer() { const [state, setState] useState(initialState) const forwardMessage useForwardMessage() return ( Composer.Frame Composer.Input / Composer.Footer / /Composer.Frame ) }useState和useForwardMessage都封装在ForwardMessageComposer内部状态被困在组件里。ForwardButton与MessagePreview无法从组件外部访问它——这正是规则注释中提出的疑问How does this button access composer state?这个按钮如何访问 composer 的状态错误二用 useEffect 向上同步状态useEffect to sync state upfunction ForwardMessageDialog() { const [input, setInput] useState() return ( Dialog ForwardMessageComposer onInputChange{setInput} / MessagePreview input{input} / /Dialog ) } function ForwardMessageComposer({ onInputChange }) { const [state, setState] useState(initialState) useEffect(() { onInputChange(state.input) // 每次变化都同步 }, [state.input]) }这是一种状态冒泡反模式子组件内部仍持有状态却通过useEffect在每次输入变化时把值同步给父组件。规则明确批评了这种做法同步逻辑脆落、多余渲染、代码意图混乱属于典型的用副作用模拟单向数据流。错误三提交时才从 ref 读取状态reading state from ref on submitfunction ForwardMessageDialog() { const stateRef useRef(null) return ( Dialog ForwardMessageComposer stateRef{stateRef} / ForwardButton onPress{() submit(stateRef.current)} / /Dialog ) }把状态塞进一个ref传给子组件等到按钮提交时再取出来。这种写法把状态藏在可变引用里绕过了 React 的渲染模型组件无法感知状态变化也破坏了类型安全与可读性。正确方案状态提升到 Providerstate lifted to provider规则的正确答案是将状态管理整体上移到一个专门的 Provider 组件中让需要共享状态的组件全部成为它的子节点function ForwardMessageProvider({ children }: { children: React.ReactNode }) { const [state, setState] useState(initialState) const forwardMessage useForwardMessage() const inputRef useRef(null) return ( Composer.Provider state{state} actions{{ update: setState, submit: forwardMessage }} meta{{ inputRef }} {children} /Composer.Provider ) } function ForwardMessageDialog() { return ( ForwardMessageProvider Dialog ForwardMessageComposer / MessagePreview / {/* 自定义组件可访问状态与动作 */} DialogActions CancelButton / ForwardButton / {/* 自定义组件可访问状态与动作 */} /DialogActions /Dialog /ForwardMessageProvider ) } function ForwardButton() { const { actions } use(Composer.Context) return Button onPress{actions.submit}Forward/Button }这段代码中出现了Composer.Provider与Composer.Context它们来自复合组件Compound Components模式Composer是一组共享同一 Context 的子组件集合Provider、Frame、Input、Footer等通过 Context 而非 props 传递共享状态。ForwardButton虽然渲染在Composer.Frame之外但因为身处ForwardMessageProvider之内依然能通过use(Composer.Context)拿到actions.submit。规则强调即便它是一个一次性组件也能从 UI 外部访问 composer 的状态与动作。关键洞察Provider 边界优先于视觉嵌套规则在文末给出了全文最有价值的结论Key insight:Components that need shared state dont have to be visually nested inside each other—they just need to be within the same provider.需要共享状态的组件不必在视觉上互相嵌套——它们只需要处于同一个 Provider 之内。这一点在配套的 state-context-interface.md 中被进一步展开ForwardButton与MessagePreview虽然在视觉上不在 composer 输入框内部却依然能访问其状态与动作——这正是把状态提升进 Provider这一模式的核心价值。支撑模式三段式 Context 接口与状态解耦要让同一套 UI、多个 Provider成为可能规则要求 Context 遵循统一契约。按 state-context-interface.md 的定义Context 值由三部分组成interface ComposerState { input: string attachments: Attachment[] isSubmitting: boolean } interface ComposerActions { update: (updater: (state: ComposerState) ComposerState) void submit: () void } interface ComposerMeta { inputRef: React.RefObjectTextInput } interface ComposerContextValue { state: ComposerState actions: ComposerActions meta: ComposerMeta } const ComposerContext createContextComposerContextValue | null(null)state当前状态数据actions修改状态/触发业务的动作函数如update、submitmeta非状态类引用如inputRef这类 DOM/原生组件引用。UI 组件只消费这个接口不关心背后是useState、Zustand 还是服务端同步。正如 state-decouple-implementation.md 所说Provider is the only place that knows how state is managedProvider 是唯一知道状态如何被管理的地方——同一个Composer.Input既可以由本地useState驱动的ForwardMessageProvider供给也可以由全局同步的ChannelProvider供给UI 完全无需改动。React 19 适配use() 与 ref 的新写法state-lift-state的正确示例中使用了use(Composer.Context)这是 React 19 的 API 变化。langfuse 前端恰好运行在 React 19 环境web/package.json 中react为19.2.4、react-dom为19.2.4、next为16.3.3因此这套模式可以直接落地。配套规则 react19-no-forwardref.md 给出了两条硬性建议用use()替代useContext()// ❌ React 18 写法 const value useContext(MyContext) // ✅ React 19 写法 const value use(MyContext)use()相比useContext()的额外优势是可以条件调用。ref作为普通 prop不再需要forwardRef// ❌ React 19 中不再需要 const ComposerInput forwardRefTextInput, Props((props, ref) { return TextInput ref{ref} {...props} / }) // ✅ ref 作为普通 prop function ComposerInput({ ref, ...props }: Props { ref?: React.RefTextInput }) { return TextInput ref{ref} {...props} / }注意该规则仅适用于 React 19若项目仍停留在 React 18 或更早应跳过这一节继续使用forwardRef与useContext。仓库实证langfuse 中的 Provider 模式这一套状态提升 Context 契约并非纸上谈兵。在 langfuse 前端中createContext Provider 自定义 Hook 的组合大量存在例如命令面板的 CommandMenuProvider.tsxinterface CommandMenuContextType { open: boolean; setOpen: (open: boolean) void; } const CommandMenuContext createContextCommandMenuContextType | undefined( undefined, ); export function CommandMenuProvider({ children }: { children: ReactNode }) { const [open, setOpen] useState(false); const value useMemo(() ({ open, setOpen }), [open]); return ( CommandMenuContext.Provider value{value} {children} /CommandMenuContext.Provider ); } export function useCommandMenu() { const context useContext(CommandMenuContext); if (context undefined) { throw new Error(useCommandMenu must be used within a CommandMenuProvider); } return context; }该实现体现了两条与本规则一致的工程决策状态上移到 Provideropen状态由CommandMenuProvider持有任何处于 Provider 之下的菜单按钮、浮层、快捷键监听都能通过useCommandMenu()访问无需逐层传 props越界即报错useCommandMenu在context undefined时直接throw new Error(...)把在 Provider 之外消费 Context的误用提前暴露在运行时。类似的 Provider 模式还广泛存在于 SessionDetailStoreProvider.tsx、InlineCommentSelectionContext.tsx、CorrectionCacheContext.tsx、ActiveCellContext.tsx 等文件中可以作为参考范式。此外你还可以在完整的编译版技能文档 web/.agents/skills/vercel-composition-patterns/AGENTS.md 中查看包含本规则在内的全部组合模式扩展讲解。落地清单当你在 langfuse 前端或任何 React 19 项目中遇到兄弟组件需要共享状态时按以下步骤重构定位共享状态哪些状态/动作被多个视觉上不相邻的组件需要创建 Provider新建XxxProvider把useState、业务 Hook如useForwardMessage与useRef全部收进 Provider 内部定义 Context 契约按state/actions/meta三段式定义泛型接口UI 组件只依赖接口用use()消费React 19 下用use(Composer.Context)替代useContextref直接作为 prop 传递检查 Provider 边界所有需要共享状态的组件无论视觉位置都应落在同一个 Provider 内而不是挤进同一个视觉容器。记住规则的核心论断共享状态靠的是 Provider 边界而不是视觉嵌套。把状态提升进 Provider既摆脱了 prop drilling也避免了useEffect同步与 ref 黑盒这三类反模式。【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Langfuse 前端实践：Lift State into Provider——在 React 19 中把状态提升进 Provider 组件的组合模式指南
Langfuse 前端实践Lift State into Provider——在 React 19 中把状态提升进 Provider 组件的组合模式指南【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse把状态放进专属的 Provider 组件而非散落在 UI 组件内部是构建可组合、可维护 React 组件的核心手段之一。本指南以 langfuse 仓库内置的 Vercel Composition Patterns 技能中的state-lift-state规则为主线完整拆解三种常见错误写法与正确的 Provider 提升方案并结合作者仓库的 React 19.2.4 环境与实际 Context 源码如 CommandMenuProvider.tsx帮助你在项目里让不在同一视觉层级的兄弟组件也能安全共享状态与动作摆脱 prop drilling 与 ref 黑盒。规则定位State 管理四类模式中的一席在 langfuse 仓库的 web/.agents/skills/vercel-composition-patterns 中React 组合模式被划分为四个优先级类别Component ArchitectureHIGH、State ManagementMEDIUM、Implementation PatternsMEDIUM与 React 19 APIsMEDIUM。本次讲解的state-lift-state属于State Management状态管理类别与另外两条规则构成完整的状态组合方案state-decouple-implementationProvider 是唯一知道状态如何被管理的组件state-context-interface用state/actions/meta三段式泛型接口支撑依赖注入state-lift-state本文把状态搬进 Provider 组件实现组件边界之外的状态共享。该规则文件的 frontmatter 明确标注了impact: HIGH其影响描述为 enables state sharing outside component boundaries即让状态共享突破组件视觉边界。问题场景转发消息对话框里的状态困局规则以一个非常贴近真实业务的前向转发消息Forward Message对话框为例。界面结构大致如下function ForwardMessageDialog() { return ( Dialog ForwardMessageComposer / MessagePreview / {/* 需要访问 composer 的状态 */} DialogActions CancelButton / ForwardButton / {/* 需要触发提交 */} /DialogActions /Dialog ) }MessagePreview消息预览和ForwardButton转发按钮在视觉上并不位于ForwardMessageComposer消息输入框内部却需要读取输入内容、触发提交动作。规则依次否定了三种想当然的写法。错误一状态被困在组件内部state trapped inside componentfunction ForwardMessageComposer() { const [state, setState] useState(initialState) const forwardMessage useForwardMessage() return ( Composer.Frame Composer.Input / Composer.Footer / /Composer.Frame ) }useState和useForwardMessage都封装在ForwardMessageComposer内部状态被困在组件里。ForwardButton与MessagePreview无法从组件外部访问它——这正是规则注释中提出的疑问How does this button access composer state?这个按钮如何访问 composer 的状态错误二用 useEffect 向上同步状态useEffect to sync state upfunction ForwardMessageDialog() { const [input, setInput] useState() return ( Dialog ForwardMessageComposer onInputChange{setInput} / MessagePreview input{input} / /Dialog ) } function ForwardMessageComposer({ onInputChange }) { const [state, setState] useState(initialState) useEffect(() { onInputChange(state.input) // 每次变化都同步 }, [state.input]) }这是一种状态冒泡反模式子组件内部仍持有状态却通过useEffect在每次输入变化时把值同步给父组件。规则明确批评了这种做法同步逻辑脆落、多余渲染、代码意图混乱属于典型的用副作用模拟单向数据流。错误三提交时才从 ref 读取状态reading state from ref on submitfunction ForwardMessageDialog() { const stateRef useRef(null) return ( Dialog ForwardMessageComposer stateRef{stateRef} / ForwardButton onPress{() submit(stateRef.current)} / /Dialog ) }把状态塞进一个ref传给子组件等到按钮提交时再取出来。这种写法把状态藏在可变引用里绕过了 React 的渲染模型组件无法感知状态变化也破坏了类型安全与可读性。正确方案状态提升到 Providerstate lifted to provider规则的正确答案是将状态管理整体上移到一个专门的 Provider 组件中让需要共享状态的组件全部成为它的子节点function ForwardMessageProvider({ children }: { children: React.ReactNode }) { const [state, setState] useState(initialState) const forwardMessage useForwardMessage() const inputRef useRef(null) return ( Composer.Provider state{state} actions{{ update: setState, submit: forwardMessage }} meta{{ inputRef }} {children} /Composer.Provider ) } function ForwardMessageDialog() { return ( ForwardMessageProvider Dialog ForwardMessageComposer / MessagePreview / {/* 自定义组件可访问状态与动作 */} DialogActions CancelButton / ForwardButton / {/* 自定义组件可访问状态与动作 */} /DialogActions /Dialog /ForwardMessageProvider ) } function ForwardButton() { const { actions } use(Composer.Context) return Button onPress{actions.submit}Forward/Button }这段代码中出现了Composer.Provider与Composer.Context它们来自复合组件Compound Components模式Composer是一组共享同一 Context 的子组件集合Provider、Frame、Input、Footer等通过 Context 而非 props 传递共享状态。ForwardButton虽然渲染在Composer.Frame之外但因为身处ForwardMessageProvider之内依然能通过use(Composer.Context)拿到actions.submit。规则强调即便它是一个一次性组件也能从 UI 外部访问 composer 的状态与动作。关键洞察Provider 边界优先于视觉嵌套规则在文末给出了全文最有价值的结论Key insight:Components that need shared state dont have to be visually nested inside each other—they just need to be within the same provider.需要共享状态的组件不必在视觉上互相嵌套——它们只需要处于同一个 Provider 之内。这一点在配套的 state-context-interface.md 中被进一步展开ForwardButton与MessagePreview虽然在视觉上不在 composer 输入框内部却依然能访问其状态与动作——这正是把状态提升进 Provider这一模式的核心价值。支撑模式三段式 Context 接口与状态解耦要让同一套 UI、多个 Provider成为可能规则要求 Context 遵循统一契约。按 state-context-interface.md 的定义Context 值由三部分组成interface ComposerState { input: string attachments: Attachment[] isSubmitting: boolean } interface ComposerActions { update: (updater: (state: ComposerState) ComposerState) void submit: () void } interface ComposerMeta { inputRef: React.RefObjectTextInput } interface ComposerContextValue { state: ComposerState actions: ComposerActions meta: ComposerMeta } const ComposerContext createContextComposerContextValue | null(null)state当前状态数据actions修改状态/触发业务的动作函数如update、submitmeta非状态类引用如inputRef这类 DOM/原生组件引用。UI 组件只消费这个接口不关心背后是useState、Zustand 还是服务端同步。正如 state-decouple-implementation.md 所说Provider is the only place that knows how state is managedProvider 是唯一知道状态如何被管理的地方——同一个Composer.Input既可以由本地useState驱动的ForwardMessageProvider供给也可以由全局同步的ChannelProvider供给UI 完全无需改动。React 19 适配use() 与 ref 的新写法state-lift-state的正确示例中使用了use(Composer.Context)这是 React 19 的 API 变化。langfuse 前端恰好运行在 React 19 环境web/package.json 中react为19.2.4、react-dom为19.2.4、next为16.3.3因此这套模式可以直接落地。配套规则 react19-no-forwardref.md 给出了两条硬性建议用use()替代useContext()// ❌ React 18 写法 const value useContext(MyContext) // ✅ React 19 写法 const value use(MyContext)use()相比useContext()的额外优势是可以条件调用。ref作为普通 prop不再需要forwardRef// ❌ React 19 中不再需要 const ComposerInput forwardRefTextInput, Props((props, ref) { return TextInput ref{ref} {...props} / }) // ✅ ref 作为普通 prop function ComposerInput({ ref, ...props }: Props { ref?: React.RefTextInput }) { return TextInput ref{ref} {...props} / }注意该规则仅适用于 React 19若项目仍停留在 React 18 或更早应跳过这一节继续使用forwardRef与useContext。仓库实证langfuse 中的 Provider 模式这一套状态提升 Context 契约并非纸上谈兵。在 langfuse 前端中createContext Provider 自定义 Hook 的组合大量存在例如命令面板的 CommandMenuProvider.tsxinterface CommandMenuContextType { open: boolean; setOpen: (open: boolean) void; } const CommandMenuContext createContextCommandMenuContextType | undefined( undefined, ); export function CommandMenuProvider({ children }: { children: ReactNode }) { const [open, setOpen] useState(false); const value useMemo(() ({ open, setOpen }), [open]); return ( CommandMenuContext.Provider value{value} {children} /CommandMenuContext.Provider ); } export function useCommandMenu() { const context useContext(CommandMenuContext); if (context undefined) { throw new Error(useCommandMenu must be used within a CommandMenuProvider); } return context; }该实现体现了两条与本规则一致的工程决策状态上移到 Provideropen状态由CommandMenuProvider持有任何处于 Provider 之下的菜单按钮、浮层、快捷键监听都能通过useCommandMenu()访问无需逐层传 props越界即报错useCommandMenu在context undefined时直接throw new Error(...)把在 Provider 之外消费 Context的误用提前暴露在运行时。类似的 Provider 模式还广泛存在于 SessionDetailStoreProvider.tsx、InlineCommentSelectionContext.tsx、CorrectionCacheContext.tsx、ActiveCellContext.tsx 等文件中可以作为参考范式。此外你还可以在完整的编译版技能文档 web/.agents/skills/vercel-composition-patterns/AGENTS.md 中查看包含本规则在内的全部组合模式扩展讲解。落地清单当你在 langfuse 前端或任何 React 19 项目中遇到兄弟组件需要共享状态时按以下步骤重构定位共享状态哪些状态/动作被多个视觉上不相邻的组件需要创建 Provider新建XxxProvider把useState、业务 Hook如useForwardMessage与useRef全部收进 Provider 内部定义 Context 契约按state/actions/meta三段式定义泛型接口UI 组件只依赖接口用use()消费React 19 下用use(Composer.Context)替代useContextref直接作为 prop 传递检查 Provider 边界所有需要共享状态的组件无论视觉位置都应落在同一个 Provider 内而不是挤进同一个视觉容器。记住规则的核心论断共享状态靠的是 Provider 边界而不是视觉嵌套。把状态提升进 Provider既摆脱了 prop drilling也避免了useEffect同步与 ref 黑盒这三类反模式。【免费下载链接】langfuse Open source AI engineering platform: LLM evals, observability, metrics, prompt management, playground, datasets. Integrates with OpenTelemetry, LangChain, OpenAI SDK, LiteLLM, and more. YC W23项目地址: https://gitcode.com/GitHub_Trending/la/langfuse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考