> "There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder. There’s great documentation for everything else, but old-fashioned data loading is relegated to one example of how to mock out ‘fetch’ for testing, and lots of Medium posts of varying quality."
The truly old fashioned way is to load your data and render the page with it in the server. A simplicity that was lost in the SPA, but that's what SSR gives back to you. But since this is an anti-SSR piece I'm not sure what it's getting at.
The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks, resulting in the need to override all the basics with bulky JavaScript that doesn't load until some time after rendering.
Which, as a user, has bitten me many times. I hate hate hate when a page seems loaded, but something has stalled, and I can't interact with anything.
As much as I hate Java, I still kind of long for old fashioned Tomcat web apps that sent out fully formed and usable HTML with small bits of JavaScript enhancements.
> So, Server-Side Rendering runs your JavaScript frontend code on the backend, creating a filled-out HTML page. The user loads the page, which now has pre-rendered content, and then the JavaScript loads and makes the page interactive.
Does this mean that one could make the page interactive with server side rendering, but it's not normally done? Or did I completely misunderstand this paragraph.
If you click on an <a> tag before the JavaScript has loaded and React has hydrated, the browser will do a full page load of the URL that you clicked on. Assuming that new page is also rendered on the server, it should work fine and feel just as good as if it was a traditional server-rendered HTML web site or if you had JavaScript turned off. (Of course, things that do require JavaScript for interactivity, like custom tooltips on hover, custom form validation, etc. won't work until the JavaScript has loaded.)
Just to add to the above, this is specifically when your pages are server-side rendered. Hydration is a concept of taking a server-rendered page and making it interactive with Javascript.
You can have your NextJS/React app server-rendered, and then users visiting a page will get the page. Clicking links within the application will use Javascript routing to load the part of the application that needs to be displayed (and prevent the default navigation from clicking said links). I think in practice it's more likely for users to fall back to default navigation which then relies on full server rendering when they have Javascript disabled, than it is because they've clicked before the front-end router has started working.
Also, before this thread I didn't realize React itself could be server-rendered (I thought that was the distinguishing point of Nextjs). Is it common to use non-next React for SSR?
I believe so. I've encountered it used in several projects longer before Next.js (or at least before Next.js was so popular). The basic idea is really simple, on the server you just ReactDOMServer.renderToString(<App />) in Node and respond with the HTML string.
Of course, the devil is in the details. You probably need some conventions for statically determining what data needs to be loaded based on the URL (before you renderToString), some way of passing that global data to the client for React hydration, perhaps some API client that can handle making requests from both the client and the server, some system for handling HTML-specific concerns like meta tags and cache-control headers, etc. Frameworks like Next.js presumably make all these decisions for you!
What they mean is that, with a normal React SPA, the html content sent to the client will be little more than something like `<div id="react-app"></div>`. After the JavaScript loads, react hooks into this div and starts filling it with the html it generates for your app. With SSR, that div will be populated with html when it’s downloaded - this is the html that was rendered by the server. When the page is first rendered it will look like your app, but it’s totally static html. The JavaScript has to load and react has to take over managing the html within that div before any of the interactive content (think: button click handlers on so on) will be functional.
> Does this mean that one could make the page interactive with server side rendering, but it's not normally done?
It can be done, it is actually, how things were done a quarter of a century ago: server-side rendered content with tiny triggers for interactivity directly embedded in the code. In the next step, as complexity grew and as an attempt at separating concerns, you would send the content and along with it a bundle of code for interactivity (which may have been sent in the same request or as a separate resource). Then, we got frameworks. Technically, these could do this as well, but it doesn't match their basic pattern.
JQuery document ready handler that makes a XMLHttpRequest and then a pile of jquery DOM manipulation calls to make the DOM state reflect the data you just got back from the server. Basically just a lot of imperative DOM manipulation calls. No templating, no MVC patterns, etc. This is the kind of frontend JS that was all over the web in the early 2000's.
JSON or XML, using REST or websocket maybe? One request per "page load" is an anti-pattern in SPA's though - you should send all static data once, lazy load large assets like images, and sync only the dynamic non cacheable data.
It kind of depends on your mental model for your user. For mobile devices in many countries outside the United states, you're doing your user no favors shipping them a bunch of static data that they don't actually need yet because you've wasted their bandwidth if they never use it and bandwidth costs money.
What is "old-fashioned data loading"?