Next.js ルーティングの革命：なぜ App Router が将来的に重要か、しかし Pages Router はまだ重要です。

Next.js 中為什麼 App Router 可能是未來，但 Pages Router 仍然重要？#

Next.js 作為一個強大的 React 框架，為開發者提供了兩種路由系統：App Router 和 Pages Router。這兩種路由系統各有特色，適用於不同的場景。本文將深入探討這兩種路由系統的區別、優缺點和使用場景，幫助你做出最佳選擇。

App Router：新一代的路由革命#

App Router 是 Next.js 13 引入的新路由系統，它使用 app 目錄來組織路由，帶來了許多令人興奮的新特性。

優點：#

React 伺服器組件支援：這是一個遊戲規則改變者，允許在伺服器端渲染複雜組件，大大提升了性能。
靈活的佈局系統：通過嵌套佈局，你可以更容易地創建複雜的頁面結構。
內建加載 UI 和錯誤處理：提供了更好的用戶體驗，無需額外配置。
性能優化：得益於伺服器組件和其他優化，App Router 通常能提供更好的性能。
並行路由：允許在同一佈局中同時渲染多個頁面。

缺點：#

學習曲線較陡：對於習慣了傳統 React 開發的人來說，可能需要一些時間來適應。
第三方庫兼容性：一些老舊的庫可能不兼容新的伺服器組件模式。
仍在發展中：作為較新的技術，可能會有一些未知的問題或變化。

Pages Router：經典可靠的選擇#

Pages Router 是 Next.js 的傳統路由系統，使用 pages 目錄來組織路由。它仍然是許多項目的首選，特別是對於較老的 Next.js 版本。

優點：#

簡單易上手：對於初學者來說，學習曲線相對平緩。
文件系統路由直觀：路由結構與文件結構一一對應，易於理解和管理。
豐富的社區資源：由於使用時間較長，有大量的教程、示例和第三方庫支援。
穩定性高：經過多年的使用和優化，bug 較少，表現穩定。

缺點：#

不支援 React 伺服器組件：無法利用這一新特性帶來的性能提升。
佈局系統相對簡單：實現複雜佈局可能需要更多的代碼和配置。
數據獲取方法較為固定：主要依賴 getServerSideProps 和 getStaticProps，靈活性較低。

實戰對比：博客頁面實現#

讓我們通過一個簡單的博客頁面來對比這兩種路由系統的實現方式：

Pages Router 實現#

// pages/posts/[id].js
import { useRouter } from 'next/router';

export default function Post({ post }) {
    const router = useRouter();

    if (router.isFallback) {
        return <div>Loading...</div>;
    }

    return (
        <div>
            <h1>{post.title}</h1>
            <p>{post.content}</p>
        </div>
    );
}

export async function getStaticProps({ params }) {
    const res = await fetch(`https://api.example.com/posts/${params.id}`);
    const post = await res.json();
    return { props: { post } };
}

export async function getStaticPaths() {
    const res = await fetch('https://api.example.com/posts');
    const posts = await res.json();

    const paths = posts.map(post => ({
        params: { id: post.id.toString() },
    }));

    return { paths, fallback: true };
}

在這個例子中，我們使用 getStaticProps 和 getStaticPaths 來實現靜態生成。這是 Pages Router 的典型用法，適合內容不經常變化的博客文章。

App Router 實現#

// app/posts/[id]/page.js
import { notFound } from 'next/navigation';

async function getPost(id) {
    const res = await fetch(`https://api.example.com/posts/${id}`);
    if (!res.ok) return undefined;
    return res.json();
}

export default async function Post({ params }) {
    const post = await getPost(params.id);

    if (!post) {
        notFound();
    }

    return (
        <div>
            <h1>{post.title}</h1>
            <p>{post.content}</p>
        </div>
    );
}

App Router 的實現更加簡潔。這裡我們直接在組件中進行異步數據獲取，這得益於 React 伺服器組件的支援。同時，我們使用 notFound 函數來處理文章不存在的情況，這是 App Router 提供的內建錯誤處理機制之一。

如何選擇？#

選擇 App Router 還是 Pages Router，沒有絕對的對錯。以下是一些建議：

項目規模和複雜度：對於大型、複雜的項目，App Router 的靈活性和性能優勢可能更有吸引力。
團隊熟悉度：如果團隊對 Next.js 較為陌生，可能從 Pages Router 開始更容易上手。
性能需求：如果項目對性能有較高要求，App Router 的伺服器組件可能是更好的選擇。
項目時間線：對於需要快速開發的項目，Pages Router 可能更適合，因為學習成本較低。
未來展望：考慮到 Next.js 的發展方向，長期來看，掌握 App Router 可能更有優勢。

個人經驗分享#

作為一個初使用 Next.js 的開發者，我最初對 App Router 也感到困惑。但是，當我開始處理複雜的佈局和需要優化性能的場景時，App Router 的優勢就顯現出來了。

例如，在一個需要頻繁更新的數據密集型應用中，App Router 的伺服器組件讓我能夠在伺服器端處理大部分數據邏輯，顯著減少了傳輸到客戶端的 JavaScript 數量，提升了應用的整體性能。

然而，對於一些簡單的項目或者時間緊迫的情況，我仍然會選擇 Pages Router。它簡單直接，能讓我快速搭建原型並上線。

結論#

App Router 和 Pages Router 各有千秋，選擇哪一個取決於你的具體需求和場景。

我的建議是：不要害怕嘗試新事物。即使你現在使用的是 Pages Router，也值得花些時間了解 App Router。

畢竟，技術在不斷進步，保持學習才能不被淘汰。

記住，技術只是工具，真正重要的是解決問題和創造價值。選擇最適合你的工具，才能事半功倍。

結語#

上次寫了一個用於批量清理無用倉庫的工具，如果感興趣那就去看看 😊

介紹文章： https://mp.weixin.qq.com/s/t7lgc6b7xJiNhfm5vWo5-A

GitHub 倉庫地址： https://github.com/yaolifeng0629/del-repos

如果你覺得這個工具對你有所幫助，請不要忘記給我的 GitHub 倉庫點個 Star！你的支持是我前進的動力！

感謝閱讀，我們下次再見！