Romaji to Kana Converter: React & Next.js — Chapter 7, Exercise 2
=====================================================================

TASK
This chapter showed that skipping the manual public/.next-static copy
step produces a real 404 for a static file while the homepage itself
still returns 200. Explain why these two things fail differently,
tracing the difference back to where each one's own content actually
comes from.

SOLUTION

The homepage's own HTML is generated code, not a file sitting on
disk waiting to be served as-is. When a request for "/" reaches the
standalone server.js, Next.js's own routing and rendering logic --
which server.js already has bundled inside it, per this chapter's
own real ls .next/standalone listing (node_modules/, package.json,
server.js, nothing else needed) -- runs the actual React page
component and produces the HTML response on the spot. Nothing about
that process ever needs to read from the public/ folder, so the
homepage keeps working perfectly even when public/ was never copied
in at all.

A file like /file.svg is the opposite kind of thing entirely: it's a
real, literal file that's meant to be served byte-for-byte, exactly
as it sits in the public/ folder, with no code generating it at
request time. There's no fallback logic for this -- server.js simply
looks for a physical file at that path, and if the copy step was
skipped, there's genuinely nothing there to find. That's a real,
correct 404, not a bug: the server did exactly what it was asked,
which was to serve a file that doesn't exist at that location on this
particular deployment.

Put together, the real reason the two requests fail differently is
that they were never depending on the same thing in the first place.
The homepage's own correctness depends on the bundled server code
inside server.js, which the standalone build always includes
automatically. A static asset's own correctness depends on a
physical file existing in a folder the standalone build deliberately
leaves out unless it's copied in by hand -- so forgetting that one
step doesn't touch server-rendered pages at all, it only breaks
whichever specific assets were never actually copied.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly separates the two kinds of content by where they
actually come from -- generated HTML produced by bundled server code
versus literal files that have to physically exist on disk -- and
explains that the copy step's own absence only affects the second
kind, which is exactly why one request keeps working and the other
doesn't.