liveBook · Manning

Framework

As explained in React in Depth

A software framework written for or centered on JavaScript that structures frontend application development.

A React website framework runs React on a server as well as in the browser. It can generate HTML with page data already included, then deliver that page before browser-side React starts. This makes server-side rendering (SSR), backend data loading, and the frontend UI parts of one application. section 11.1 section 11.3.2

The architecture changes where work happens:

  • Server-rendered HTML can shorten the wait for visible content, with potential benefits for visitors and search ranking. The gain depends on correct implementation, not merely adopting a framework. section 11.0 section 11.5
  • Server-side JavaScript can fetch database or external API data, including data requiring secrets, and place the result in the rendered page. section 11.1
  • Pages connect URLs to React components. Route files can also load data and accept URL parameters, rather than relying solely on a collection of client-side components. section 11.3.1 section 11.5
Table 11.3 The three routes required in our weather application and their file locations inside Next.js, Remix v1, and Remix v2
Component location
URL
Next.js
Remix v1
Remix v2
http://localhost
/pages
/app/routes
/app/routes
/
/index.jsx
/index.jsx
/_index.jsx
/{country}
/[cc]/index.jsx
/$cc/index.jsx
/$cc.jsx
/{country}/{city}
/[cc]/[city].jsx
/$cc/$city.jsx
/$cc.$city.jsx

Compare the files for a weather application's home, country, and city URLs. Next.js and Remix express the same routes with different file names; Remix v2 uses flat, period-separated route names. section 11.3.1

Load a category before rendering its page

For a URL such as /shop/shoes, a route reads the category identifier and fetches its data on the server. In the illustrated Next.js pages setup, getServerSideProps returns that data as component props. In Remix, a loader returns it and the component reads it with useLoaderData. Both can redirect when the category is missing; their file names and data APIs differ. section 11.3.2

SSR has a hard constraint: the browser's initial React output must match the server-rendered HTML for hydration. A mismatch can erase the initial performance advantage. Server code also cannot read browser local storage; for relatively small items, cookies may be an alternative, though their handling differs between frameworks. Choose a framework for the application's needs rather than treating either Next.js or Remix as universally preferable. section 11.1 section 11.5

How React in Depth covers it

How deep it goes
Works through route-file and data-loading implementations in two frameworks, while leaving their broader APIs to their documentation.
Examples
Uses weather-app country and city routes and a category page loaded through Next.js or Remix.
What it assumes
Assumes familiarity with React components and JavaScript while explaining how server execution changes routing and data delivery.
What you can do after
Build it from scratch: create server-rendered React routes that load page data using Next.js or Remix.
How it connects
Connects server-side rendering and hydration to file-based routing, dynamic URLs, database access, external APIs, and cookies.

Also explained in

Compare how 5 books explain framework →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of React in Depth. The section links point to the parts of the book it draws on.