address: medux - react - SSR
Render Server (Server Side Rendering) is not a complex technology, and Rendering with Server isomorphism Rendering is two different concepts, the focus is on: , to do a perfect set of code to run on the browser and server is not a simple matter, the industry also have no satisfactory solution in particular, need to be more or less do differentiation with different environments,
isomorphism rendering goal and the significance of
usually isomorphism rendering mainly to:
- good for SEO search engine included
- to speed up the first screen rendering time
- at the same time has single pages (SPA) and more routing user experience
isomorphism rendering usually need to do it:
- the browser and server to reuse the same set of code,
- user access to the first page (the first screen) by the server rendering output, for SEO and speed up the rendering speed,
- the first screen by the server after rendering the output, the browser on the basis of the further rendering, but no longer do repetitive work, including not repeat the request data,
- after the user to access other pages are no longer after server rendering, in order to reduce the server pressure and achieve the user experience of the single page (SPA),
- in the process of interaction after refresh the browser, need to keep the current page to render by the server, so as to realize the user experience, multi-page routing
isomorphism of rendering the difficulty and key
obtain initialization data:
Homogeneous when rendering the main difficulty is that the Client end of the rendering component lifecycle hooks bearing too many functions and side effects, such as: to get the data, and routing, on-demand loaded, modularization, etc, these logic are scattered in various components with the rendering dynamic execution of components, and their execution cause components to render again, is simply:
Render - & gt; Hooks - & gt; The Effects - & gt; ReRender - & gt; Hooks - & gt; The Effects...
The rendering process on the Server side is not enough, because usually won't ReRender Sever end, so you must put all the side effects are carried out in advance, and then the one-time Render, is simply:
Effects - & gt; The State - & gt; Render
Then the solution is to these side effects and the life cycle of the components of hooks from as far as possible, and the introduction of independent state management mechanism to manage them, let the UI rendering into simple pure PrueRender, and that is exactly what the @ medux advocated state drive concept,
Asynchronous on-demand loaded:
On the Client side render time, in order to improve loading speed we usually the chunk of code of the subcontract, and use the asynchronous on-demand loading to optimize the user experience, and on the Server side rendering it totally did not need, it will slow down the loading speed, how to replace the asynchronous code on the Server side for synchronous code? Just @ medux module loading is regarded as a kind of allocation strategy, it can be easy to load the module in synchronous and asynchronous switching between,
CodePudding user response:
No one needs server isomorphism rendering?
CodePudding user response:
