Translate "Sunsetting Create React App"

[smikitky]

No description provided.

[smikitky]

ここよく分かっていません。とりあえず直訳していますが、「コードがダウンロードされる間に並行してコードをフェッチ」って何やねん、と思っています。

「コードがダウンロードされる間に並行してデータをフェッチ」と言いたい？ 「コードがダウンロードされる間に並行して別のルートのコードをを（プリ）フェッチ」と言いたい？ ただ直後のコードサンプルからはそのような雰囲気が全く感じられませんし…。

[honey32]

僕はてっきり「ファイルがロードされたら、即座に該当するチャンクのダウンロードをする」という動作だと思っていましたが、

https://ja.react.dev/reference/react/lazy を見た感じ、「MarkdownPreview を 初回レンダーしたときに はじめてチャンクのダウンロードが始まる」という挙動になるらしいです。

ローカルでは試していませんが、同ページにデモがあったので、そちらで確認できました。

import { useState, Suspense, lazy } from 'react';
import Loading from './Loading.js';

const MarkdownPreview = lazy(() => delayForDemo(import('./MarkdownPreview.js')));
// MarkdownPreview.js のダウンロードは、トップレベルでいきなり開始する……のではなく、

export default function MarkdownEditor() {
  const [showPreview, setShowPreview] = useState(false);
  const [markdown, setMarkdown] = useState('Hello, **world**!');

  console.log("render")
  return (
    <>
      <textarea value={markdown} onChange={e => setMarkdown(e.target.value)} />
      <label>
        <input type="checkbox" checked={showPreview} onChange={e => setShowPreview(e.target.checked)} />
        Show preview
      </label>
      <hr />
      {showPreview && (
        <Suspense fallback={<Loading />}>
          <h2>Preview</h2>
          <MarkdownPreview markdown={markdown} />
          {/* ^ 実は、この JSX 式のぶんがレンダーされるときに始まる */}
        </Suspense>
      )}
    </>
  );
}

// Add a fixed delay so you can see the loading state
function delayForDemo(promise) {
  console.log("start loading")
  return new Promise(resolve => {
    setTimeout(resolve, 2000);
  }).then(() => promise);
}

[honey32]

なので、

• App.js が読み込まれる
• App.js において、<MarkdownPreview /> がレンダーされる
• MarkdownPreview.js のダウンロードが始まる

というウォーターフォールが発生してしまうので、それを避けたい、ということだと思うので、その訳文で問題ないと思います。

---

ただ、「コードがダウンロードされる間に並行してコードをフェッチ」は、それでもあと 30% ぐらいしっくり来ない…

downloading を「ダウンロードされる」ではなく「（何かを）ダウンロードしている」と訳すべきなのか…？

それとは別に、

• 前者の「コードが」は「createBrowserRouter が書かれているような、ルーター設定側のコード」
• 後者の「コードを」は、「そのファイルから参照されている、(lazy) な個別ルートのコード」

と解釈できなくもないですが、根拠がない…

[smikitky]

@koba04 よろしくお願いします！

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
legacy-ja-reactjs-org	⬜️ Ignored (Inspect)	Visit Preview		Apr 15, 2025 5:53am

[honey32]

Suggested change

	これにより、`/dashboard` というリンクを共有すれば、アプリはダッシュボードページに移動するようになります。ルーティングライブラリには、ルートのネスト、ルートガード、ルート間画面遷移効果 (root transition) などの追加機能もあり、これらはルーティングライブラリなしには実装困難です。
	これにより、`/dashboard` というリンクを共有すれば、アプリはダッシュボードページに移動するようになります。ルーティングライブラリには、ルートのネスト、ルートガード、ルート間画面遷移効果 (route transition) などの追加機能もあり、これらはルーティングライブラリなしには実装困難です。

[honey32]

"common option" は "common mistake" （ありがちな間違い）を意識していそう…？少し不安ですが、この「エフェクト内で fetch を呼ぶ」方法をネガティブに紹介しているというニュアンスを出すのが良いかと思います。

ほかにも、短く・こなれた表現にできるかもしれない点を変えてみました

Suggested change

	Create React App でのもうひとつの一般的な問題はデータフェッチです。Create React App には、特定のデータフェッチソリューションは含まれていません。まだ始めたばかりという場合、一般的な選択肢はデータをロードするためにエフェクト内で `fetch` を使用することです。
	Create React App でのもうひとつの一般的な問題はデータフェッチです。Create React App には、特定のデータフェッチソリューションは含まれていませんが、入門したばかりの方は、データをロードするためにエフェクト内で `fetch` を使う方法を選びがちです。

[honey32]

"immediately before" は「直前に」で良さそう

Suggested change

	初回ロード時に、ルータはルートがレンダーされる前にデータを即座にフェッチできます。ユーザがアプリ内を移動する際、ルータはデータとルートのフェッチを並列化して同時に行えます。これにより、画面上のコンテンツを見るまでの時間が短縮され、ユーザエクスペリエンスが向上します。
	初回ロード時に、ルータはルートがレンダーされる直前にデータをフェッチできます。ユーザがアプリ内を移動する際、ルータはデータとルートのフェッチを並列化して同時に行えます。これにより、画面上のコンテンツを見るまでの時間が短縮され、ユーザエクスペリエンスが向上します。

[honey32]

"trade off A (against | for) B" は、「B を得るために、A を得てしまうが、それを我慢する」みたいな語釈があるので、以下のように変えると少しの不自然さを解消できるかと思います。

https://dictionary.cambridge.org/ja/dictionary/english/trade-off

（ついでに、たぶん動詞 requires の目的節を、 文末の performance まで広げるのが正確かと思ったので、そのように語順を入れ替えました。）

Suggested change

	ただし、これにはアプリ内のローダを正しく設定する必要があり、パフォーマンスのために複雑さが犠牲になっています。
	ただし、そのためには、アプリ内のローダを正しく設定することと、パフォーマンスのために複雑さを受け入れることが必要になります。

[honey32]

• 文頭の「サーバーレンダーにより」が「送信される」「削減し」のどちらに掛かっているのかで両義的になってしまっているので、それを回避するために「サーバーレンダーは」としました。
• 後半
  • This is why the について、訳文で抜けている箇所があったので補いました
  • 「節」が長くなりすぎたので、それを避けるように "This is why ~" の訳文の語順を大きく見直しました。
    • 談話標識？が後ろに行ってしまってますが、いきなり「Chrome チームが、」と、文と文の繋がりが切れてるので、十分に流れは分かりやすい…はず

Suggested change

サーバレンダーによりクライアントに送信される JavaScript を全体的に削減し、完全な HTML ドキュメントを生成することで、[First Contentful Paint (FCP)](https://web.dev/articles/fcp) を高速化し、[Total Blocking Time (TBD)](https://web.dev/articles/tbt) を削減し、またそれにより [Interaction to Next Paint (INP)](https://web.dev/articles/inp) を低下させることができます。これが、Chrome チームが開発者に静的またはサーバサイドレンダリングを[検討するよう促した](https://web.dev/articles/rendering-on-the-web)理由でもあります。

サーバレンダーはクライアントに送信される JavaScript を全体的に削減し、完全な HTML ドキュメントを送信することで、[First Contentful Paint (FCP)](https://web.dev/articles/fcp) を高速化し、[Total Blocking Time (TBD)](https://web.dev/articles/tbt) を削減し、またそれにより [Interaction to Next Paint (INP)](https://web.dev/articles/inp) を低下させることができます。Chrome チームが開発者に向けて、パフォーマンス最大化のために、完全にクライアントサイドに寄せた戦略ではなく静的ないしサーバサイドレンダリングを[検討するよう促している](https://web.dev/articles/rendering-on-the-web)のには、このような理由があるのです。

[honey32]

原文では "before" を使っているので、「見れるようになるまでの間に…」のほうが良いと思います。

Suggested change

	サーバレンダーは SEO も改善しますが、ユーザが画面上のコンテンツを見るためにダウンロード・パースする必要のある JavaScript の量を減らすことで、パフォーマンスも向上させるものです。
	サーバレンダーは SEO も改善しますが、ユーザが画面上のコンテンツを見れるようになるまでの間にダウンロード・パースする必要のある JavaScript の量を減らすことで、パフォーマンスも向上させるものです。

[honey32]

server-rendering-is-optional にもほぼ同じ文があるので、それに寄せて

Suggested change

	これが、Chrome チームが開発者に対し、最高のパフォーマンスを達成するために、完全なクライアントサイドのアプローチではなく、静的ないしサーバサイドレンダリングを検討するよう[促している](https://web.dev/articles/rendering-on-the-web)理由です。
	Chrome チームが開発者に向けて、パフォーマンス最大化のために、完全なクライアントサイドに寄せた戦略ではなく、静的ないしサーバサイドレンダリングを検討するよう[促している](https://web.dev/articles/rendering-on-the-web)のには、このような理由があるのです。

[honey32]

僕はてっきり「ファイルがロードされたら、即座に該当するチャンクのダウンロードをする」という動作だと思っていましたが、

https://ja.react.dev/reference/react/lazy を見た感じ、「MarkdownPreview を 初回レンダーしたときに はじめてチャンクのダウンロードが始まる」という挙動になるらしいです。

ローカルでは試していませんが、同ページにデモがあったので、そちらで確認できました。

import { useState, Suspense, lazy } from 'react';
import Loading from './Loading.js';

const MarkdownPreview = lazy(() => delayForDemo(import('./MarkdownPreview.js')));
// MarkdownPreview.js のダウンロードは、トップレベルでいきなり開始する……のではなく、

export default function MarkdownEditor() {
  const [showPreview, setShowPreview] = useState(false);
  const [markdown, setMarkdown] = useState('Hello, **world**!');

  console.log("render")
  return (
    <>
      <textarea value={markdown} onChange={e => setMarkdown(e.target.value)} />
      <label>
        <input type="checkbox" checked={showPreview} onChange={e => setShowPreview(e.target.checked)} />
        Show preview
      </label>
      <hr />
      {showPreview && (
        <Suspense fallback={<Loading />}>
          <h2>Preview</h2>
          <MarkdownPreview markdown={markdown} />
          {/* ^ 実は、この JSX 式のぶんがレンダーされるときに始まる */}
        </Suspense>
      )}
    </>
  );
}

// Add a fixed delay so you can see the loading state
function delayForDemo(promise) {
  console.log("start loading")
  return new Promise(resolve => {
    setTimeout(resolve, 2000);
  }).then(() => promise);
}

[honey32]

なので、

• App.js が読み込まれる
• App.js において、<MarkdownPreview /> がレンダーされる
• MarkdownPreview.js のダウンロードが始まる

というウォーターフォールが発生してしまうので、それを避けたい、ということだと思うので、その訳文で問題ないと思います。

---

ただ、「コードがダウンロードされる間に並行してコードをフェッチ」は、それでもあと 30% ぐらいしっくり来ない…

downloading を「ダウンロードされる」ではなく「（何かを）ダウンロードしている」と訳すべきなのか…？

それとは別に、

• 前者の「コードが」は「createBrowserRouter が書かれているような、ルーター設定側のコード」
• 後者の「コードを」は、「そのファイルから参照されている、(lazy) な個別ルートのコード」

と解釈できなくもないですが、根拠がない…