What's the system architecture of a non-SPA reactive application?

Question

I'm starting to learn about reactive web applications, and I pretty much get the hang of the whole components, virtual DOM, states and more.

First of all, I usually don't name a technology, but for the sake of simplicity I'll use ReactJS as the example, but I'm sure the concepts also applies for other libraries/framework like VueJS and Angular.

Now, I know the easiest architecture to explain would be the SPA (though definitely not the easiest to implement), since the system architecture consists of 2 completely different applications: a client side (SPA) and the server side (REST/GraphQL service).

With that in mind, let's dig into how is the architecture of a non-SPA reactive application.

From the top of my head, being new at the reactive application paradigm, I'd say server-side rendering would be one option (I'm talking about monolithic architecture, server-side rendering. Think of an MVC project). In this architecture the server would render views into HTML, and those HTML files would have the JS inline or embed. However, when trying to implement it, I realize this doesn't make any sense as on reactive apps you're not supposed to render HTML (view from MVC) and embed JS into it; but it's the other way around, you template HTML INSIDE the JS components.

So now, I'm confused. I could be wrong with my previous statement about server-side rendering not making any sense, but I am unable to see how since I'm inexperienced with reactive apps.

So, what's the architecture of a non-SPA reactive application, that would consume a REST/GraphQL service to populate data into it's component?

Update:

I have been doing research since the day I posted the question and today, and I think my confusion lies in mostly the may to bundle things up.

I can't think of a way of attaching a component ItemList to a DOM element, that doesn't involve using an Id like <div id="item-list"> and then makings sure the same id doesn't repeat in the rest of the codebase so that it won't get attached there by accident.

Say my component is defined in ItemList.js, and the last line would be render(<ItemList />, 'item-list'); If I process that file with webpack into a bundle.js that is imported in the main layout file, every view in the app will attempt to attach my component to said DOM element. That's where my confusion lies.

Answer 1

The thing that seems to be confusing you is that you think the choice of server-side rendering or client-side rendering is either/or, that choosing one automatically precludes the other.

That's not the case.

There are plenty of SPA-like applications that start with an HTML page rendered by the server, and then populated (or even modified) in the client. Architecturally, there isn't that much difference; you can have more rendering on the server and less on the client, or vice versa, and your architectural layers could be exactly the same.

Further, there are many non-spa applications (primarily server-side rendering) that implement further rendering and DOM modification in the client. So the architectural lines are not nearly as clearly drawn as you might imagine.