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

控心つcrazy發表於2024-08-01
JSAPP

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。

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

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

結語

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

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

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

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

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

相關文章