Normally the Cookies will be sent to the server directly because of the browsers. But in server rendering it would be a proxy browser to deliver the Cookies. And how do you handle that?
What you call "server side rendering" is a new buzzword for simple classic "HTTP response". How you structure you app and how you load your templates is noway connected to HTTP cookies.
Usually server in HTTP response sends Set-Cookie header telling browser to create a new cookie.
Sometimes it is needed to create a cookie from a browser and it is done by a document.cookie
Browser sends all cookies itself on each HTTP request.
More information about HTTP Cookies on MDN
Since you're asking about server-side rendering I'm guessing you are thinking of an architecture where the code that is run to render on the server is the same that is run on the client and therefore would make AJAX requests to a separate backend API (which may require cookies for authentication).
The simple answer is: decouple your data fetching layer from the view layer and write one "API client" for fetching over AJAX from the client and one for fetching from server to server (or even directly talking to the database if the rendering and API servers are the same).
In React you could do this by passing in the API client to the root of the component tree (like a Redux store).
Otherwise you can just keep the two API clients in different modules and swap out the require paths in your module bundler (this is trivial in browserify and webpack) so the browser version gets the AJAX code and the server version gets the other one.
Sandeep Panda
co-founder, Hashnode
Cookie handling is not related to how you render views. In case of SSR, the browser will still send an HTTP request to load a view, which means cookies will be automatically sent to server as a part of request header.