We Keep Coding

Data fetching in next js

There are many ways to fetch data from apis in next.js.
getServerSideProps,getStaticPaths,getStaticProps,Incremental Static
Regeneration and client side rendering.
If I have to make requests to backend on the change of any state, can I use other methods of data fetching apart from client side rendering?
I am from React.js background where client side rendering is mostly used.
What are the specific use cases of different fetching methods?
Can I always use client side rendering only in Next.js also.

Server-side rendering is good for SEO. You can check this, if you view the page source of a react app you won't get much HTML, this is the problem next.js fixes. With getServerSideProps and getStaticProps you can make calls to your API(such as DB back-end) to get your data and server-side render your page. Now when you have to update state of your page you can simply fetch as you normally would, since it doesn't matter because it is triggered by some action anyway.
Can I always use client side rendering only in next.js also.
Yes you can, but you want search engines to index your site and/or display relevant data such as review and preview text, right?
If I have to make requests to backend on the change of any state, Can I use other methods of data fetching apart from client side rendering
When the state is changed you will fetch new information just like you normally did in react.
GetServerSideProps and GetStaticProps only run once when the user visits the page(or reloads etc ofc). You can get the latest data by fetching and updating state with that.
Next.js is much more than react, it can be used as a back-end too i.e. creating APIs for saving data to db, handle authentication etc. Explaining it all is beyond the scope of this answer.
As for when to use what you can read more about it here, or search about it I'm sure SO has many questions about this.
One situation where you can be forced to use next.js features is when you want to consume an old API that does not implement CORS, here you can't control the dev on the other side so you can create an API on next.js which you fetch on your react code like: /getinfo. Now write code on your back-end to handle this which will delegate the result of that third-party API back to you, pretty neat right

Server side rendering with next.js vs traditional SSR

I am very used to the approach where SSR meant that the page got a full refresh and received a full HTML from the server, where it gets rendered with razor/pub/other depending on the backend stack. So every time the user would click on the navigation links, it would just send a request to the server and the whole page would refresh, receiving a new HTML. That is the traditional SSR which I understand.
With SPA however, we have for example react or angular, where we receive almost empty HTML on the beginning and then the JS so that the whole app gets initialized on the client side. We can then have some REST API to get json data and render views on the frontend (client side routing and rendering) without any page refresh. We don't even need any server really.
Now, what I have a problem understanding is how SSR (such as next.js) works with react.
From what I am reading, the first request returns full HTML+CSS (which helps with SEO etc - I get that), but what happens later? What happens after that first/initial request? Does the whole react app initialize in the browser and then it just behaves EXACTLY as if it was a normal SPA (meaning we have client side routing and rendering from now on, without any need to make requests to that server)? In other words, does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?
I spent lots of time reading but all the articles mainly focus on the initial request and SEO and time to first byte, paint etc. and I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.

does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?
You got it right. The first (initial) request is handled by the server and after that the frontend handles the routing (at least in the case of Next.js).
If you want to see an example OpenCollective is built with Next.js. Try playing around with it and see the Network tab in the DevTools.
I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.
It is called SSR because the app is effectively being rendered on the server. The fact that frontend routing takes over after the initial render doesn't remove the fact that the server did the work of rendering the app as oppose to the user machine.

That's Not all the things that happen with Next.js, In Next.js You can build something called Hybrid apps.
In traditional SSR, all of your client requests get handled by the server. Every request goes to the server and gets responses.
In classic CSR with something like React, as you said, all the things happens in the browser via the client-side javascript.
But, in Next.js you can define three different approaches (mainly two according to the docs) for pages to get delivered.
based on the app needs and requirements, you can serve a couple of pages in pure traditional SSR mode, a couple of them in classic CSR mode, and a couple of in SSR mode via dynamic data that get fetched and rendered into the pages on the fly.
these features bring lots of flexibility to design a web-app that behaves perfectly in every different scenario that is needed.

Prevent Redux actions performance on client side

I have a React/Redux/SSR app. Right now my app works as follows:
A user visits some url, browser sends request to Frontend server (Node.js)
Frontend server gets all necessary data for this url from Backend server (Ruby) and build html then responds to user's browser with filled window._PRELOADED_STATE_ with appropriated Redux store's state
User's browser renders received html and runs bundle.js script which is React app. It uses filled before window._PRELOADED_STATE_ to initialize app (at this time actions run again)
I want to prevent Redux actions performance on the first rendering on client because all is done on the server already.
What I have tried: on client after the first rendering I delete window._PRELOADED_STATE_ and run actions if window._PRELOADED_STATE_ exists only. But deleting of window._PRELOADED_STATE_ performs before app initialization so actions run anyway.
How can I get desired behaviour? Any ideas are appreciated.

Do you have the opportunity to use React in dev mode?
In dev mode React will complain if it's not able to match the SSR code with the front-end code. It looks to me that you can have a similar situation.
If that's not the case, which are the actions that run at the beginning?

Understanding the difference between Client Side Rendering and Server Side Rendering?

I am kind of in cross roads in the process of understanding the basic difference between Client Side Rendering and Server Side Rendering. After doing significant amount of research, here is my understanding
When we render on to the server it means:
You have a local server say Apache Tomcat, You host a web application
by clicking the run on server, It renders your HTML on the server.
I understand this completely. Now here starts my confusion:
Client Side Rendering?????
You host a web application without a local server???
I might be wrong, but this is what the conclusion it is taking me too.
I know, ReactJS does both serverSide Rendering and Client Side Rendering. However, I am not getting the basic difference between both these renderings.
Any help would be highly appreciated.

"Rendering" in this context means "Assembling the document from various component parts".
With server side rendering, you would do all that on the server and then send a complete HTML document to the browser.
This is:
Traditional
Robust
Search engine friendly
With client side rendering you would use client side JavaScript to load a template and some data (using multiple requests) and then put them together in the browser to form a DOM and create a page.
This can provide performance benefits for subsequent pages (since less data is being fetched for them) although the cost of bootstrapping the initial page is usually higher.
Lack of robustness and search engine friendliness can be compensated for by combining the techniques. A new request for a page (any page) uses server side rendering, but following links trigger JavaScript to involve Ajax, the History API, and client side rendering. If you use server side JavaScript, you can reuse some of the same code for both (this is sometimes called Isomorphic JS).

Rendering components on the server side with code splitting in webpack

I am trying to build a webapp using React, React Router and Webpack libraries, and taking advantage of server side rendering.
Now, I have a basic structure working - when I visit a URL, the page is rendered on the server, sent back to the client where React confirms that the output rendered on the client side matches with what's generated on the server and takes over from there.
My problem is when I try to open URLs which have to load components asynchronously.
When I visit a URL which has to load a dependency asynchronously, the server renders the output including all dependencies, but when it comes to the client, the markup which React renders does not include the asynchronously loaded components and therefore is different from server's and I get an error in the console which says
Warning: React attempted to reuse markup in a container but the checksum was invalid.
The way I see it the solution would be to either not render the asynchronously loaded components on server and lose out on the benefits of server side rendering or to somehow tell React to ignore the differences between the server and client, and not discard the server's markup, because I know that the component will eventually be loaded and markups will match.
Has anyone else come across this problem and knows what a good solution would be?

You need to also run match on the client side to load all the route components.
There's a fleshed out example available at https://github.com/rackt/example-react-router-server-rendering-lazy-routes.