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

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

App Router：新一代的路由革命

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

優點：

1. React 伺服器組件支持：這是一個游戲規則改變者，允許在伺服器端渲染複雜組件，大大提升了性能。

2. 靈活的佈局系統：通過嵌套佈局，你可以更容易地創建複雜的頁面結構。

3. 內置載入 UI 和錯誤處理：提供了更好的用戶體驗，無需額外配置。

4. 性能優化：得益於伺服器組件和其他優化，App Router 通常能提供更好的性能。

5. 並行路由：允許在同一佈局中同時渲染多個頁面。

缺點：

1. 學習曲線較陡：對於習慣了傳統 React 開發的人來說，可能需要一些時間來適應。

2. 第三方庫相容性：一些老舊的庫可能不相容新的伺服器組件模式。

3. 仍在發展中：作為較新的技術，可能會有一些未知的問題或變化。

Pages Router：經典可靠的選擇

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

優點：

1. 簡單易上手：對於初學者來說，學習曲線相對平緩。

2. 文件系統路由直觀：路由結構與文件結構一一對應，易於理解和管理。

3. 豐富的社區資源：由於使用時間較長，有大量的教程、示例和第三方庫支持。

4. 穩定性高：經過多年的使用和優化，bug 較少，表現穩定。

缺點：

1. 不支持 React 伺服器組件：無法利用這一新特性帶來的性能提升。

2. 佈局系統相對簡單：實現複雜佈局可能需要更多的代碼和配置。

3. 數據獲取方法較為固定：主要依賴 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，沒有絕對的對錯。以下是一些建議：

1. 項目規模和複雜度：對於大型、複雜的項目，App Router 的靈活性和性能優勢可能更有吸引力。

2. 團隊熟悉度：如果團隊對 Next.js 較為陌生，可能從 Pages Router 開始更容易上手。

3. 性能需求：如果項目對性能有較高要求，App Router 的伺服器組件可能是更好的選擇。

4. 項目時間線：對於需要快速開發的項目，Pages Router 可能更適合，因為學習成本較低。

5. 未來展望：考慮到 Next.js 的發展方向，長期來看，掌握 App Router 可能更有優勢。

個人經驗分享

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

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

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

結論

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

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

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

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

結語

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