我的想法是,首先渲染页面的服务器将导致更好的体验,而不必解析所有的javascript然后再渲染服务器.
我很困惑代码拆分如何适应ssr模型,是ssr渲染第一个命中,然后在客户端上完成代码拆分？
React.Lazy指出react.client是在客户端上完成的.它与服务器上的代码拆分有何不同？如果你去一个特定的路线然后你为第一次渲染检索那个块？
我理解React.Lazy都是在客户端完成的,他们已经明确表达了这一点.如果在服务器上完成它会有什么不同.
解决方法
根据您的用例,您可以仅使用SSR,仅根据需要进行代码拆分或组合.
SSR的优点
>更好的搜索引擎优化,因为搜索机器人有标记可以使用(并且不一定依赖于执行javascript)进行索引.
>自从服务器发送标记后,初始渲染速度更快,浏览器不必等待执行javascript来渲染它. (虽然标记仍然缺乏交互性,直到反应是水合客户端).
>首先提供关键的CSS.初始页面呈现的关键CSS可以是内联的,更好的用户体验,因为加载的标记已经准备好了样式.
>更简单的路由拆分. SSR imo使得分解应用程序的路由变得更加简单.例如,您可能有/ about和/ home的不同页面,您可以将其拆分以减少捆绑包大小(如果需要,可以在客户端预加载其他路由).
结合代码拆分组件和SSR
服务器可能没有必要呈现整个页面.例如,考虑您的主页(您希望服务器渲染)包含聊天组件,以便用户可以直接向您提问.
如果此组件很大,您可能决定不对服务器进行渲染,以便用户可以首先获取页面中最重要的部分.这将通过在主页组件中拆分此组件的代码来减少初始页面加载.
当浏览器解析了标记时,它会在主包之后加载您的Chat组件.通过这种方式,您可以识别并保持捆绑包的大小.
仅使用代码拆分
如果您对SSR的好处不感兴趣,这是构建应用程序的完美方式.
例如,如果您的应用程序是经过身份验证的用户的用户仪表板,那么最好不要担心SSR,只需将代码拆分为应用程序.另请注意,由于必须生成标记,因此呈现应用程序的服务器将花费更多时间在服务器上发送响应(而不是简单的REST API).
来你的问题：
I am confused how code splitting fits into the ssr model,is it that ssr renders the first hit and then code splitting is done thereafter on the client?
是的,有点.在客户端负责加载必要的位之后,浏览器从服务器接收初始加载.现在,您可以决定预加载组件服务器端并发送所有内容(请检查我在本答复结尾处提到的反应加载).
How would it differ from code splitting on the server. Is that if you go to a specific route then you retrieve that chunk for the first render?
lazy只是一个更干净的API,支持Suspense进行代码分割.理想情况下,在第一次加载路由时,您将服务器呈现初始标记,然后让客户端负责加载下一个位和路由. Imo Next.js非常好.
How would it differ if it was done on the server.
您可以预加载所有组件或仅预加载必要的位.请检查拆分组件和SSR部分的组合代码.
Is there any real benefit to ssr with code splitting. Does it not just add complexity?
在这里,一切都有自己的权衡.正如我在“仅使用代码分割”部分中提到的,如果您的用例不需要SSR的优点,那么完全可以使用代码分割.
Note
Currently
lazy(in React v16.6.1) doesn’t support SSR completely. You might want to check out 07001 to handle the cases where you wish to preload components server side.
