PRNext 0.1.19: 最初の使用時にコンパイルし、状態を保持します

#コード編集を通じて作業を継続する

レイアウトにフィルターが含まれるダッシュボードと、サーバー アクションを呼び出すフォームを考えてみましょう。フォーム応答が到着している間にコンポーネントを保存します。 PRNext は、更新に互換性がある場合、更新されたアクション参照をページを再度開始する理由として扱うのではなく、マウントされたレイアウトを保持するようにこれらの操作を調整します。

ソースが変更されていないアクションは、キャッシュ コンポーネントを含め、開発セッション内でそのアイデンティティを維持します。変更されたアクションは新しい ID を受け取ります。実稼働ビルドは独立した ID を保持します。古いフライト応答は新しい世代のレンダリングを上書きできず、ナビゲーションがそのレンダリングを置き換えた場合でもアクション エラーが観察可能なままになります。

突然変異とその表示は別個の操作のままです。新しいインタラクションにより古い表示が無関係になる可能性がありますが、PRNext が再び突然変異を送信することはありません。互換性のない編集、一部の構成変更、ドキュメント全体のリロードによって、メモリに保持されている状態がリセットされる可能性があります。

#大きなツールを開いたときにコンパイルする

通常の動的インポートでは、コンパイル中にチャンクが生成され、ダウンロード中も対話を待機します。開発では、experimental.lazyDynamicImports はさらに進んでいます。適格なクライアント ターゲットを初期ブラウザ グラフの外側に保持し、最初の使用を待ってから変換およびコンパイルします。

ネイティブ コンパイラを使用して App Router アプリケーションでこのオプションを有効にします。エディタ、ビューア、またはめったに開かれないパネルは、動作を比較するのに便利な場所です。このオプションはデフォルトでは無効になっています。

export default {
  experimental: {
    lazyDynamicImports: true
  }
};

最初の使用では、そのサブグラフをコンパイルするコストが発生します。ファイルはプライベート ステージングで準備され、完全に公開されます。スタイルはインポートが解決される前に読み込まれます。アクティブ化されると、モジュールは JavaScript および CSS の更新に参加します。すでにロードされている ESM 依存関係は、その ID とライブ バインディングを保持します。 2 つのインポーターも同じ JSON オブジェクトを共有します。

意図された利点は、ワークフローでそのツールを使用しないときに、作業を起動時から移動できることです。起動と初回使用の遅延を一緒に測定します。このオプションは、実稼働チャンクもサーバーのレンダリング動作も変更しません。

#ブラウザ専用エディタを使用した例

ssr: false の next/dynamic コンポーネントは、ブラウザー内にエディターを保持します。この例では、パネルが開いた後にのみコンポーネントが要求されます。遅延コンパイルが有効になっていると、対象となるクライアント コードはその使用まで待機します。

'use client';

import { useState } from 'react';
import dynamic from 'next/dynamic';

const Editor = dynamic(() => import('./editor'), {
  ssr: false,
  loading: () => <p>Loading the editor…</p>
});

export default function EditorPanel() {
  const [open, setOpen] = useState(false);
  return open
    ? <Editor />
    : <button onClick={() => setOpen(true)}>Open the editor</button>;
}

初期スコープには、Webpack フックとカスタム ローダーは含まれません。計算されたインポート、インポート属性、および ? を含むリテラル パスまたは # 通常のコンパイルを維持します。遅延グラフ内のエイリアスまたは依存関係によってサフィックスが導入されると、明示的なエラーが生成されます。 ID を保持できない共有 CommonJS 依存関係と、そのグラフを通じてのみ検出される新しいサーバー アクションも、通常のパスまたは適切な静的インポートを必要とします。

アクティブ化されたスタイルは、並列ルートを含め、開発世代にロードされたままになります。ツールにローカルな CSS モジュールまたはセレクターを優先します。このメカニズムでは、その世代のファイルシステムにハードリンクが必要です。環境で作成できない場合は、オプションを無効にしてください。

#JavaScript ビルドをコピーせずにスタイルシートを編集する

互換性のある CSS 編集により、影響を受けるバンドルが再構築され、現在の JavaScript 世代に小さなスタイル世代が公開されます。 PRNext は、その更新のためにすべての JavaScript ファイルをスキャンまたはコピーすることなく、イメージ、フォント、ソース マップなどの使用中のリソースを保持します。

1 つのパネルのスタイルを編集してから別のパネルを数回編集した場合、最初のパネルで変更されたリソースは、境界付きスタイル カタログで引き続き使用できます。変更されていないリソースは、基本世代でも引き続きアクセスできます。出所が不完全、カタログが大きすぎる、または互換性のない変更がある場合は、完全なビルドにフォールバックします。

インクリメンタル グラフでは、メイン コンピレーションとスタイルの間で予算も分割されます。プロジェクトに多数の CSS スコープがある場合、スタイルはメイン グラフを継続的に削除することなく、未使用の容量を借用できます。制限はグローバルのままであり、作業はセッションが終了すると破棄されます。

macOS では、ディレクトリ通知に複数の変更を組み合わせることができます。 PRNext は、ソース サブツリー内のファイルをチェックして、開発中と build --watch の両方での深い編集を検出します。検証が不完全なままの場合は、回復可能なエラーが報告され、コンパイル ループを開始せずに以前のビルドが保持されます。

#ランタイムを変更する前に非互換性を理解する

ソース内でサポートされている next/* インポートでは、別のプライベート API を使用する依存関係を非表示にすることができます。移行監査は、インストールされたパッケージへの到達可能な静的インポートに従います。これは、ブラウザー、ノード、React サーバー コンポーネントのコンテキストを考慮し、診断の背後にあるファイル、行、インポート チェーンを報告します。

使用サーバー境界は、クライアント コンポーネントが再エクスポートを通じてサーバー境界に到達したときもサーバー境界のままです。ノード API に対するブラウザーの依存関係は、パッケージが存在するという理由だけで受け入れられるのではなく、ブラウザーのマッピングとインストールされた実装を使用してチェックされます。

目的の PRNext バージョンがすでにインストールされているプロジェクトから、移行を適用しないチェックから始めます。

npx --no-install prnext migrate --dry-run
npx --no-install prnext migrate --check --json

レポートでは、検査された動作と未知の動作が区別されます。計算されたインポート、ローダー出力、またはトラバーサル制限は、暗黙的な成功にはなりません。監査では、検査する依存関係モジュールは実行されませんが、構成を評価することでプロジェクト コードを実行できます。これは、信頼できないコード用のサンドボックスでも互換性証明書でもありません。実際のビルドとアプリケーションのワークフローは依然として必要です。

#デモ ページを超えて、アカウントを備えたアプリケーションに移動する

saas 参照の例では、フランス語と英語のアプリケーションで Better Auth、PostgreSQL、Drizzle、next-intl を組み合わせています。各アカウントはそれぞれのメモを所有します。ダッシュボードはセッションをチェックし、すべての変更でユーザーとデータの所有権を再度チェックします。ボタンを非表示にしたり、ページのみを保護したりするだけでは不十分です。

認証フォームは、高価なパスワードのハッシュ化の前に、共有されたアトミックな PostgreSQL バジェットを適用します。資格ワークフローでは、制御されたローカル プロバイダーと安全な Cookie をチェックする HTTPS プロキシを使用して、セッションの取り消し、CSRF の拒否、および無効な OpenID Connect コールバックを実行します。

同じアプリケーションは、スタンドアロン出力を再配置した後、2 つのワーカーと元のソースを削除してテストされます。それは検証可能な出発点です。アクセス ルール、アカウントの回復、検証、および不正使用の制限は、引き続きお使いの製品と一致する必要があります。デプロイメントでは、転送ヘッダーを上書きする信頼できるプロキシの背後でバックエンドをプライベートに保ちます。

#プリフェッチを明示的かつバインドされたアイドル状態にする フライト保持

キャッシュ コンポーネントの外側では、Link prefetch={true} が宛先の完全なプリフェッチを要求するようになりました。この明示的な選択は、プリフェッチ ポリシーとブラウザーの予算の影響を受けます。クリック時に宛先が再検証されます。プリフェッチでは、古くなったプライベート応答を表示することは許可されません。

また、フライト トランスポートは、使用されなくなったベースの保持を制限し、不必要なキャッシュ バッファのコピーを回避します。これらの変更は特定のパスを対象としています。 SSR ページまたはアプリケーション全体の応答が速くなるということは確立されていません。

#適切なチェックを行ってリリースを採用する

更新後、実際にインストールされているバージョンと調整された React 依存関係を確認し、アプリケーションを再構築して再起動します。 Next.js から移行する場合は、監査レポートを保持し、認証されたルート、フォーム、スタイル、およびナビゲーションを実行してください。有効にしておく前に、自分のプロジェクトで実験的なオプションを比較してください。

PRNext は、部分的な Next.js 互換性を備えたアルファ版のままです。機能認定には、Linux、macOS、Windows、さらに Chromium、Firefox、WebKit が含まれます。これらのチェックでは、一般的なパフォーマンスの向上は確立されません。プロセスの観察が不完全であるため、歴史的なキャンペーンは決定的なものではありません。このリリースのパフォーマンスを確立するものではありません。アトミックな開発状態の公開中の以前の Windows EPERM エラーは文書化されたままであり、原因や具体的な修正は示されていません。

代表的なワークフローは、開始点として役立ちます。コールド ルートを開き、そのスタイルを編集し、フォームを送信し、以前にアクセスしたページに戻ります。これにより、アプリケーションのリリースでの変更内容、依存関係、認証、デプロイメントの制約が確認されます。