Rendering Content & the Kanji Edge Case

Website Rebuild with Astro

Chapter 7 · Rendering Content & the Kanji Edge Case

Two of this chapter's three usual questions are already answered by earlier chapters, unchanged. The third has a real, small, honest wrinkle worth covering.

Routing & Rendering: Already Solved

Kanji's two original constraints — a fixed-depth hierarchy, and no self-contained-fragment convention — never applied to this course's own design in the first place. Chapter 2's arbitrary-depth Drizzle schema has no special-cased depth limit, and Chapter 4's set:html={page.body} renders a kanji page's own inline markup through the exact same path as any other page. Nothing new to solve here, matching every sibling course's own resolution.

String Safety: Genuinely Already Solved Too

The identical resolution as Next.js, because it's the identical runtime
Astro runs on Node.js — the exact same JavaScript engine, and the exact same UTF-16 string model, that the Next.js rebuild already worked with. Whatever string-slicing safety conclusion that course's own Chapter 7 reached applies here completely unchanged, since this isn't two frameworks reaching a similar answer independently — it's the literal same language and runtime being reused a second time within this series.

A Real, Small, Honest Difference: mysql2's Own Charset

// db/client.ts const connection = await mysql.createConnection({ uri: process.env.DATABASE_URL, charset: 'utf8mb4', });
Not automatic the way Rails' own generator was
Rails Rebuild's own Chapter 7 found a genuinely positive default: rails new --database=mysql has configured utf8mb4 automatically since Rails 5.2, with nothing to set manually. The Node mysql2 driver Drizzle uses has no equivalent automatic default — charset: 'utf8mb4' has to be set explicitly in the connection config, or the connection falls back to a less complete charset that risks the same historical 3-byte truncation issue Rails' own chapter described. A small, real, honest difference — not every framework in this series reached the same quiet win Rails did.

Kanji Across the Series

Next.jsDjangoLaravelRailsAstro
String-slicing riskNone — UTF-16, same as AstroNone — Python 3 stringsReal — mb_substr() neededNone — Ruby stringsNone — same runtime as Next.js
utf8mb4 handlingManual (Prisma config)Manual (Django DB config)Manual (migration charset)Automatic since Rails 5.2Manual — mysql2 connection option

Hands-On Exercises

Exercise 1

Confirm the two original kanji constraints are already resolved by Chapters 2 and 4, without writing any new code for this chapter.

📄 View solution
Exercise 2

In a Node REPL, confirm '水のページ'.length and slicing behavior are safe for typical kanji content — the same JavaScript string model the Next.js rebuild already relied on.

📄 View solution
Exercise 3

Omit charset: 'utf8mb4' from the mysql2 connection config, and confirm the connection does NOT default to it automatically the way Rails' own generator did — a real, observable difference between the two frameworks.

📄 View solution

Chapter 7 Quick Reference

  • Routing/rendering — already solved by Chapters 2 and 4, no new work
  • String safety — identical to Next.js, since both share the same Node.js/V8 runtime
  • charset: 'utf8mb4' — has to be set explicitly on the mysql2 connection; no automatic default the way Rails 5.2+ has
  • Not every sibling reached the same quiet win — a real, honest difference from Rails' own Chapter 7
  • Next chapter: Dynamic Content & Forms