React API 和代码重用的演变!( 四 )

在 Next.js 中,如果一个文件顶部有“use server”,它告诉打包工具所有导出都是服务端  Action 函数,这确保函数不会包含在客户端捆绑包中 。
当后端和前端共享同一个模块依赖图时,有可能会意外地发送一堆不想要的客户端代码,或者更糟糕的是,意外将敏感数据导入到客户端捆绑包中 。为了确保这种情况不会发生,还有“server-only”包作为标记边界的一种方式,以确保其后的代码仅在服务端组件上使用 。这些实验性的指令和模式也正在其他框架中进行探索,超越了 React,并使用类似于server$的语法来标记这种区别 。
全栈组合在这个转变中,组件的抽象被提升到一个更高的层次,包括服务端和客户端元素 。这使得可以重用和组合整个全栈功能垂直切片的可能性 。
// 可以想象可共享的全栈组件// 封装了服务端和客户端的细节<Suspense fallback={<LoadingSkelly />}><AIPoweredRecommendationThingapiKey={proccess.env.AI_KEY}promptContext={getPromptContext(user)}/></Suspense>这种强大的能力是建立在 React 之上的元框架中使用的高级打包工具、编译器和路由器的基础上的,因此付出的代价来自于其底层的复杂性 。同时,作为前端开发者,我们需要扩展自己的思维模型,以理解将后端代码与前端代码写在同一个模块依赖图中所带来的影响 。
总结本文探讨了很多内容,从mixin到服务端组件,探索了 React 的演变和每种范例的权衡 。理解这些变化及其基础原则是构建一个清晰的 React 思维模型的好方法 。准确的思维模型使我们能够高效地构建,并快速定位错误和性能瓶颈 。




推荐阅读