3 ms·
Was hoping for a second there that they found the way not to include the serialized state (as json sitting inside the script tags) in the body of the html docum
by azangru 8y ago
Was hoping for a second there that they found the way not to include the serialized state (as json sitting inside the script tags) in the body of the html document (to make the page lighter), but no, that's not the case.
Anyway, it’s interesting how they separate the code for fetching data (making it a responsibility of one server) from the code for rendering data (making it a responsibility of another, Node-based, server). Which means that although they re-use the code for components, the code for data fetching logic must get duplicated.
- Can_Not 8y ago> Which means that although they re-use the code for components, the code for data fetching logic must get duplicated. In my experience, the rendering server has a copy of the SPA mounted. I'm not aware of any normal reasons for duplicated fetching logic.
- cynicalreason 8y agoyou don't NEED to include the serialized state in the body of the HTML, this is the common practice, you can wait for the client to parse your js and then make a separate request for the state data. I don't get point 2, if they are to 'hydrate' the react renders in node with data, they have to have a 'fetching' logic in there, the fact that it connects to an 'API' instance makes no difference, the client could use the same connection with same logic client side.
- azangru 8y ago> I don't get point 2, if they are to 'hydrate' the react renders in node with data, they have to have a 'fetching' logic in there The way I am understanding their blog post, they have a dedicated server (let's call it server1) for api requests, and then a server for rendering (let's call it server2). Server1 does all the fetching logic and then sends the received and appropriately processed json to server2, which needs only to use this data for rendering.