Posts on Kaisekukun

現代 CSS 新功能的實際使用（子網格/容器查詢）

Wed, 14 Oct 2026 00:00:00 +0900

從視窗標準到獨立組件的典範轉移

傳統的響應式網頁設計依賴螢幕（視口）的整體寬度。然而，在當今元件導向的設計世界中，UI 元件的可用寬度會根據它們所在的父元素（側邊欄或主列）而有所不同。

隨著CSS Grid的「子網格」和「容器查詢」的出現，佈局的靈活性和可維護性得到了極大的提升。

配方 1：「subgrid」在對齊卡片高度的同時同步按鈕位置

即使在多列卡片UI中標題字元數不均勻，每張卡片中「圖像、標題、文字和按鈕」的高度也可以在水平線上完美對齊。

.card-grid {
 display: grid;
 grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
 gap: 1.5rem;
}

.card {
 display: grid;
 grid-template-rows: subgrid;
 grid-row: span 4; /* 画像・タイトル・本文・フッターの4行を親グリッドに同期 */
}

不需要任何 JavaScript 來計算每張卡片的高度。

方法 2：`@container` 其佈局依其寬度調整

卡片組件會根據其所在容器的寬度自動在水平和垂直對齊之間切換。

.card-wrapper {
 container-type: inline-size;
 container-name: card-container;
}

@container card-container (min-width: 450px) {
 .card-content {
 flex-direction: row; /* 横幅に余裕があれば横並びへ自動変形 */
 }
}

您可以在主頁的寬區域和側邊欄的窄區域中重複使用相同的元件。

實際實作的概念

子網格和容器查詢已經在主要的現代瀏覽器中完全支援。擺脫整個螢幕上的斷點造成的破壞，並轉向每個組件都可以獨立存在的 CSS 設計。

使用 Vitest 和測試庫進行高效率的前端測試

Tue, 06 Oct 2026 00:00:00 +0900

Vite原生測試環境帶來的開發速度提升

Jest 多年來一直是前端測試的主流，但其設定複雜性和開銷是問題。透過組合共享 Vite 設定的“Vitest”和“React 測試庫”，您可以獲得極快的測試環境。

我們總結了建造高度可維護且難以破壞的測試套件的實用原則。

原則：測試“使用者行為”而不是“實作細節”

直接測試組件的內部狀態會導致脆弱的測試，每次重構都會破壞測試。基本思想是驗證螢幕向使用者顯示的行為。

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { LoginForm } from './LoginForm';

test('入力からログイン完了までのフローを検証', async () => {
 const user = userEvent.setup();
 render(<LoginForm />);

 await user.type(screen.getByLabelText('メールアドレス'), 'test@example.com');
 await user.click(screen.getByRole('button', { name: 'ログイン' }));

 expect(await screen.findByText('ようこそ')).toBeInTheDocument();
});

非同步更新的陷阱：正確使用查詢函數

getBy**：同步驗證元素「現在存在」。如果不存在則立即錯誤。
findBy**：等待API取得等「非同步延遲顯示」的元素（傳回Promise）。
queryBy**：用於斷言該元素「螢幕上不存在」（傳回 null）。

並行化點減少 CI 執行時間

Vitest預設使用執行緒並行執行。對於涉及 DOM 操作的測試，請在「afterEach」中正確重置模擬，以保持每個測試案例的獨立性，最大化並行測試的數量，並降低 CI 成本。

UI 元件設計考慮到 Web 可存取性 (a11y)

Tue, 29 Sep 2026 00:00:00 +0900

平衡設計和可用性的輔助功能基礎

網路可訪問性 (a11y) 是一項品質標準，旨在改善每個人的體驗，不僅針對特定殘疾人，還針對鍵盤使用者以及暫時受傷或單手操作的使用者。

我們整理了組件設計的要點，以便任何人都可以直觀地操作它。

模態對話框設計的三個基本要求

模態框是最常發生可訪問性違規的部分。您必須確保滿足以下三個要求。

焦點陷阱：開啟時，Tab 鍵移動僅限於模態，防止焦點洩漏到其後面的元素。
Escape鍵操作：按ESC鍵立即關閉，關閉後將焦點回到「開啟模態方塊的原始按鈕」。
適當的 WAI-ARIA 屬性：
- 授予role =“dialog”和aria-modal =“true”
- 明確指向標題的“aria-labelledby”

常被忽略的三大反模式

反模式 1：將點擊事件附加到 <div> 或 <span>
- 問題：無法使用鍵盤（Enter/Space）進行操作，且不顯示為螢幕閱讀器的按鈕。
- 解決方案：使用原生 <button> 標籤和 CSS 樣式。
反模式 2：使用佔位符作為標籤
- 問題：當您開始打字時它就會消失，從而損害可見性和認知負荷。
- 已解決：準備一個始終顯示的<label>，並使用htmlFor將其與輸入的id關聯起來。
反模式3：對比不足
- 問題：對比度小於4.5:1時難以閱讀，例如淺灰色文字。
- 已解決：修復了符合 WCAG 2.1 AA 標準的調色板。

使用 Headless UI 函式庫減少工時

自己從頭開始實現可訪問性非常耗時。現代標準是使用“高度可訪問的無樣式 UI 原語”，例如 Radix UI 和 React Aria，並僅應用 Tailwind CSS 等樣式。

使用 Next.js 和 Hono 建立的全端 WebAPI 簡介

Tue, 22 Sep 2026 00:00:00 +0900

Next.js App Router × Hono 帶來的開發革命

Next.js 的路由處理程序很強大，但隨著端點的增加，樣板檔案和類型共享的複雜性往往成為一個問題。

通过将符合Web标准的超轻量级框架“Hono”纳入API层，您可以轻松创建复杂的端到端、类型安全的RPC（远程过程调用）环境。

第 1 步：使用 Catch-all Route 進行 Hono 初始化

在 App Router 中放置通配符路由，並將所有「/api/*」委託給 Hono。

// app/api/[[...route]]/route.ts
import { Hono } from 'hono';
import { handle } from 'hono/vercel';
import { zValidator } from '@hono/zod-validator';
import { z } from 'zod';

export const runtime = 'edge';
const app = new Hono().basePath('/api');

const routes = app.get('/users/:id',
 zValidator('param', z.object({ id: z.string() })),
 (c) => c.json({ id: c.req.valid('param').id, name: 'Alice' })
);

export type AppType = typeof routes;
export const GET = handle(app);

步驟 2：使用 `hc` 取得類型安全的數據

Hono 的一個主要優勢是伺服器端路由定義（「AppType」）可以作為客戶端上的類型匯入。

// クライアント側コンポーネント
import { hc } from 'hono/client';
import type { AppType } from '@/app/api/[[...route]]/route';

const client = hc<AppType>('http://localhost:3000');

export async function getUser(id: string) {
 const res = await client.api.users[':id'].$get({ param: { id } });
 return await res.json(); // 返り値の型が自動推論される
}

###生產作業三大要點

在 TypeScript 5 系列中練習的類型安全編碼技術

Tue, 15 Sep 2026 00:00:00 +0900

TypeScript 5.x時代所需的型別設計哲學

TypeScript 5 系列引入了許多新功能，可以在不影響開發人員體驗的情況下最大限度地提高類型推斷的準確性。依賴過多類型斷言 (as) 的程式碼是執行時期錯誤的滋生地。有了型系統在您身邊，我們將解釋實用技術，自然地縮小您的型。

1. `const` 類型參數：更聰明的文字類型推斷

以前，如果您想在函數參數中保留文字類型，則必須在呼叫方添加“as const”。 TypeScript 5.0 的 const 類型參數可讓您在函數定義端強制進行文字推理。

// 呼び出し側の as const なしで厳密なリテラル配列として推論
function createRoutes<const T extends readonly string[]>(routes: T): T {
 return routes;
}
const routes = createRoutes(['/home', '/dashboard']);

作為參數傳遞的陣列和物件不會被擴展，並且安全地推斷為精確的元組或文字。

2. `satisfies` 運算子：類型相容性驗證和推理的兼容性

satisfies 解決了新增類型註解會導致屬性的特定類型資訊遺失，而刪除它會導致驗證失敗的困境。

type Palette = Record<string, string | number[]>;
const theme = {
 primary: '#0066cc',
 rgb: [0, 102, 204],
} satisfies Palette;

// 型制約を満たしつつ、個別プロパティの型が完全保持される
theme.primary.toUpperCase(); // string型メソッドが安全に呼出可能

3. 具有範本文字類型的事件中心

type Event = 'click' | 'focus';
type HandlerMap = { [K in `on${Capitalize<Event>}`]?: () => void };

在類型層級強制執行字串連接規則，並在建置時防止事件名稱 100% 出現拼字錯誤。

反模式：應在該領域根除的“任何”

使用“as any”作為解決類型錯誤的快速方法是放棄 TypeScript 優勢的糟糕方法。使用類型保護函數（“is”運算符）和模式驗證器（例如 Zod）在運行時邊界安全地縮小類型範圍。

使用 Next.js 15 建立的超快速 Web 應用程式

Tue, 08 Sep 2026 00:00:00 +0900

「Next.js 15」終於在最近的更新中發布了測試版，並在前端界引起了很大的轟動。我也立即將我的個人專案從 Next.js 14 升級到 15，並嘗試了一些新功能。在這篇文章中，我將回顧我實際接觸後感受到的「驚人的進化」。

Next.js 15 的演變讓我一接觸就感到驚訝

如果非要用一個詞來形容的話，那就是「開發者體驗（DX）和效能的終極提升」。自從 App Router 推出以來，Next.js 一直處於重大範式轉變之中，版本 15 感覺已經接近完成。

1. 使用 React Compiler 將自己從手動記憶中解放出來

就我個人而言，讓我印象最深刻的是官方對 React Compiler 的支援。以前，您必須在各處編寫“useMemo”、“useCallback”和“React.memo”，以防止不必要的重新渲染。但是，在 Next.js 15 中，編譯器將為您進行最佳化。

實際上，我嘗試從程式碼中刪除所有這些掛鉤，它根本沒有減慢速度，反而使我的程式碼庫變得非常乾淨。僅此一點就值得採取行動。

2.預設快取策略修改

在先前的版本中，許多開發人員對「預設快取所有內容」的激進規範感到困惑（我就是其中之一）。在 Next.js 15 中，取得請求（“fetch”）的預設值已修改為“no-store”，並且我們傳回了一種選擇加入方法，您可以在該方法中僅明確指定需要快取的部分。這減少了無意的陳舊數據顯示的數量，並使直觀的開發再次成為可能。

3. Turbopack 穩定性帶來爆炸性的啟動速度

本地開發環境建置的速度也值得注意。 Turbopack 是一個基於 Rust 的捆綁器，現在更加穩定，允許伺服器立即啟動，即使對於大型專案也是如此。熱重載（Fast Refresh）的反應也是壓倒性的，等待時間帶來的壓力幾乎被消除。

整體回顧：您現在應該遷移嗎？

總之，如果它是一個新項目，我們建議毫不猶豫地在 Next.js 15（或 React 19）上建立它。即使您有一個現有項目，如果您已經遷移到 App Router，升級它的障礙也不會那麼高。

「快」不僅僅指瀏覽器的繪製速度。這意味著開發人員編寫、審查和部署程式碼的整個週期更快。我認為 Next.js 15 是能夠實現這種「極快循環」的框架的頂峰。

後端開發中的效能調優介紹

Thu, 03 Sep 2026 00:00:00 +0900

隨著Web服務的用戶數量增加，他們不可避免地會遇到回應時間慢、伺服器崩潰等效能問題。前端優化固然重要，但負責基礎資料處理的後端往往是瓶頸。

本文為首次致力於提升後端效能的工程師提供了實用檢查點清單。

🚨 5 個檢查點需要檢查

如果盲目進行效能調優，效果不會很好。首先檢查是否是以下原因造成的。

**不是出現N+1問題了嗎？ **
- 使用 O/R 映射器 (ORM) 時，N+1 問題經常會在不知不覺中發生。檢索清單資料時，檢查查詢日誌，看看是否發出一條循環遍歷相關資料的 SQL。
**索引是否正確附加？ **
- 索引與資料庫搜尋速度最直接相關。請為搜尋條件或排序條件中經常使用的欄位設定適當的索引（單一索引或複合索引）。
**您是否有效地使用了快取？ **
- 透過使用Redis或Memcached將經常存取但很少更新的資料（例如主資料）緩存在記憶體中，可以顯著減少資料庫的負載。
**您是否在呼叫外部API時等待太久？ **
- 如果與第三方 API 或其他微服務的通訊是同步進程，則該進程將被阻塞。如果可能，請考慮使用非同步處理或背景工作程序的設計。
**是否有記憶體洩漏？ **
- 如果長時間運行的應用程式效能逐漸下降，則可能懷疑存在記憶體洩漏。使用探查器調查是否有任何不必要的物件引用。

🛠️ 沒有測量就沒有改善

調優時最糟糕的事情就是「透過猜測來修復」。我的「我感覺這裡很慢」的直覺常常被證明是錯的。

首先，引入 APM（應用程式效能監控）工具，例如 New Relic 或 Datadog，以數位方式視覺化哪些事務和哪些進程（SQL 執行時間、外部通訊等）正在花費時間。

💡調整心態

最後要記住的是，並不是所有事情都需要最快。從維護成本的角度來看，引入複雜的快取機制來減少每天只執行一次的批次過程幾秒鐘通常是不值得的。

確定與使用者體驗直接相關的關鍵端點，並將資源集中在這些端點上。這是成為優秀後端工程師的第一步。在日常的發展中要注意“衡量”，一點一點地改進。

秋夜學習：最新前端技術趨勢

Sun, 30 Aug 2026 00:00:00 +0900

正是這個季節，窗外隱約能聽到蟲鳴聲。我喜歡夏天，手捧冷飲，在冷氣房裡寫程式碼，但身為工程師，沒有什麼比在漫長的秋夜裡，一邊感受涼爽的夜風，一邊悠閒地看新科技文件的了。

這次我想稍微放鬆一下，以散文的方式回顧今年在前端界掀起波瀾的技術趨勢。

切換回伺服器端

如果讓我選出一個代表今年的關鍵字，那肯定是「React Server Components (RSC)」。在過去的幾年裡，我們全心全意地研究「如何在瀏覽器端（客戶端）創造豐富的體驗」。然而，JavaScript 套件的大小不斷增加，初始載入速度已達到極限。

這就是 RSC 的用武之地。從某種意義上說，這種方法讓人想起 PHP 和 Ruby 的美好時光：「任何可以在伺服器上呈現的東西都應該在伺服器上完成。」這是將客戶端互動性與伺服器穩健性高度融合的新範例。 Next.js 的 App Router 處於領先地位，許多開發人員對其潛力感到興奮，儘管他們很難獲得新的思維模型。

人工智慧與程式設計之間的複雜性

另一個不容忽視的事情是透過生成式人工智慧改變開發體驗。 Copilot 建議更多程式碼，ChatGPT 在幾秒鐘內編寫複雜的正規表示式。人工智慧已經超越了「有用的工具」的範疇，而成為結對程式設計的夥伴。我突然在半夜想到，未來前端工程師的要求將從從頭開始編寫程式碼的能力轉變為審查AI輸出和設計整體架構的能力。

持續學習的樂趣

人們常說前端技術的部署太快了。我能理解那種疲憊不堪並想著「新框架又出來了」的感覺。然而，如果你從不同的角度來看，沒有比這個更無聊的遊樂場了。每年我們都會出現一個新玩具，世界各地的天才都會爭論是否有更好的方法。

以昆蟲的聲音作為背景音樂，我嘗試遵循我以前從未使用過的工具的教程。擁有這樣一個秋夜，豈不是很美好嗎？相信明天的你會變得更好一點。

實作安全性驗證功能：NextAuth.js 簡介

Fri, 28 Aug 2026 00:00:00 +0900

在開發Web應用程式時，不可避免的一件事就是「身份驗證功能」的實現。然而，從頭開始自行實現密碼雜湊、會話管理、CSRF 對策、OAuth 整合等會帶來很高的安全風險，並且需要大量的開發成本。

因此，這次我們將介紹一些使用「NextAuth.js」（目前為 Auth.js）實現安全身份驗證的最佳實踐，它是 Next.js 環境中身份驗證的事實標準。

最佳實務 1：基本上優先考慮 OAuth（社群登入）

管理自己的密碼意味著您面臨資訊外洩的風險。使用 NextAuth.js 時，首先考慮引入社交登入（OAuth 提供者），例如 Google 或 GitHub。設定提供者非常簡單，只需在設定檔中寫入客戶端 ID 和 Secret 並添加幾行程式碼即可建立強大的身份驗證系統。也省去了用戶記住密碼的麻煩，有利於提高註冊率。

最佳實務2：JWT和資料庫會話的區別使用

使用 NextAuth.js，您可以選擇兩種類型的會話保留方法：「JWT（JSON Web 令牌）」和「資料庫會話」。

JWT 的優點： 無需資料庫查詢，從而實現更快的回應時間和更輕鬆的擴充。預設建議這樣做。
資料庫會話的優點： 會話可以輕鬆地立即失效（例如，管理員強制特定使用者登出）。

根據您的要求進行設計，例如需要高安全控制的業務系統的資料庫會話，以及以效能為導向的消費應用程式的 JWT。

最佳實務 3：使用中介軟體確保路由保護

透過將 NextAuth.js 與 Next.js 12 及更高版本中引入的中間件功能結合，您可以堅決阻止對特定頁面（例如「/dashboard/*」）的未經授權的存取。在組件內使用「useSession」進行重定向的傳統方法存在瞬時螢幕閃爍 (FOUC) 的問題，但透過使用在邊緣端運行的中間件，可以在使用者看到登入畫面之前無縫重定向到登入畫面。

最佳實務 4：嚴格管理金鑰

要在生產環境中執行 NextAuth.js，需要設定環境變數「NEXTAUTH_SECRET」。這是用於加密令牌的最重要的金鑰，如果它被洩露，將直接導致重大漏洞。請確保您的團隊在部署環境（例如Vercel）的環境變數設定畫面上安全地管理環境變量，並且永遠不要將它們提交到原始程式碼（Git）。

避免重新發明輪子，並將身分驗證的負擔留給受信任的庫。這是現代安全網路開發的黃金法則。

React Server 元件的工作原理和使用範例

Sat, 22 Aug 2026 00:00:00 +0900

React Server Components (RSC) 正在徹底改變前端架構。您可能聽說過這個名字，但是您是否確切知道它與SSR（伺服器端渲染）有何不同以及幕後進行了什麼樣的處理？在本文中，我們將深入探討其技術機制並考慮其實際使用的範例。

與 SSR 的決定性差異

傳統的SSR是一種在初始載入期間在伺服器端產生HTML並將其傳回給瀏覽器的技術。但隨後瀏覽器必須載入 JavaScript 並重新運行（水合）該元件以使其具有互動性。換句話說，元件程式碼本身最終被下載到瀏覽器。

另一方面，RSC 是一個僅在伺服器上運行且從不傳送到瀏覽器的元件。 RSC經過伺服器處理後，會被序列化為特殊的類似JSON的格式而不是HTML，然後傳送到客戶端。瀏覽器端只是接收這些資料並將其反映在 DOM 中。

捆綁包大小大幅減小

這種機制的最大好處是減少了發送到客戶端的 JavaScript 套件的大小。例如，假設您想要使用重型庫（例如「marked」）將 markdown 轉換為 HTML。如果您使用 RSC 實作此功能，則所有解析都在伺服器上完成，因此不會將繁重的程式庫程式碼下載到使用者的瀏覽器。這是移動環境性能的革命性改進。

客戶端邊界設計是關鍵。

使用 RSC 時最麻煩的事情是設計伺服器和客戶端元件之間的邊界。由於 RSC 在伺服器上運行，因此它不能具有事件處理程序，例如“onClick”或狀態管理（“useState”）。只有需要它們的最終元件（按鈕和輸入表單）才應該成為客戶端元件。

需要一種樹形結構設計理念，其中“數據採集和繁重處理在樹的上層（伺服器）進行，只有需要用戶操作的葉子部分作為客戶端。”

實際使用範例

在實踐中，RSC 在以下用例中表現最為出色：

部落格和媒體文章展示： 與上面提到的Markdown轉換一樣，RSC在渲染靜態內容方面是獨一無二的。
直接資料庫存取： 由於RSC 是伺服器環境，因此您可以安全地將查詢直接傳送到資料庫。由於可以省略一層API，因此可以節省開發工作量。
專注於 SEO 的登陸頁面： 快速初始加載，無需額外的 JS，這會直接提高您的 Core Web Vitals 分數。

RSC 不是要取代現有的 React，而是澄清客戶端和伺服器之間「角色分工」的新武器。正確理解這一機制並將其適當地融入設計中將是未來前端開發的關鍵。

透過 Vercel 進行自動化部署並利用預覽環境

Sun, 16 Aug 2026 00:00:00 +0900

“〇〇先生，現在已經實現完成了，能否將分支拉到您當地的環境中看看是否有效？” 你是否因為這樣的互動而浪費了團隊發展的時間？設定環境的麻煩和本地建置的等待時間大大降低了整個團隊的生產力。

Vercel 的自動化部署和預覽環境完美地解決了這個問題，並引發了前端開發工作流程的典範轉移。

###預覽網址打破審核瓶頸

當您將 Vercel 與 GitHub 等儲存庫整合時，將會有一種神奇的體驗。當開發人員實現新功能並建立拉取請求 (PR) 時，Vercel 會自動為該分支建立程式碼，並發出一個臨時“預覽 URL”，其配置與生產中的配置完全相同。

這消除了審閱者在本機刪除程式碼的需要。只需點擊 PR 中評論的 URL，您就可以立即在瀏覽器中檢查實際行為、動畫、損壞的響應式設計等。

加速與非工程師的協作

工程師並不是唯一從預覽環境中受益的人。即使是沒有開發環境的人，例如設計師和產品經理，也可以透過簡單地分享訊息「請看一下這個 URL」來接收實作回饋。

這極大地加速了敏捷開發過程，讓您能夠在開發的早期階段快速發現並糾正返工，例如「按鈕的顏色有點不同」或「動畫不是您所期望的」。

Vercel 評論的上下文回饋

更強大的是直接在預覽環境中留下評論的能力。審閱者可以點擊預覽畫面上的任何元素（例如，稍微偏離中心的按鈕）並直接在那裡留下評論，說：「請將此處的邊距擴大一點。」這些評論連結到 Slack 和 GitHub，讓開發人員可以透過上下文立即了解「評論指向螢幕的哪個部分」。

創造團隊「節奏」的基礎設施

Vercel 的吸引力不僅僅在於託管速度。真正的價值在於它可以讓團隊適應一種優美、無摩擦的開發節奏：「編寫程式碼」→「發布 PR」→「透過 URL 獲取確認」→「合併到生產（自動部署）」。

如果您的團隊仍然手動將文件上傳到伺服器或在本地進行繁瑣的審核，請考慮立即實施 Vercel。您會注意到溝通品質的變化和團隊士氣的提升。

GraphQL 基礎知識與 REST API 之間的差異

Tue, 11 Aug 2026 00:00:00 +0900

「REST API」作為API設計方法早已成為業界標準。然而，近年來，隨著前端變得越來越複雜，越來越多的公司開始採用 GraphQL。在討論技術細節之前，我們先以在餐廳點餐為例來思考一下兩者之間的差異。

REST API 在餐廳中的局限性

REST API 就像一個“美食廣場”，每個菜單都有不同的櫃檯。例如，假設您要訂購一份漢堡包套餐。您必須先前往漢堡櫃檯（/api/burgers/1），然後前往馬鈴薯櫃檯（/api/sides/potato），最後前往飲料櫃檯（/api/drinks/coke）。

這就需要多次來回櫃檯（多次要求）的麻煩。另外，即使你想把漢堡中的泡菜去掉，櫃檯也會送你有泡菜的成品。這是一個稱為「過度獲取」的問題，即檢索不必要的資料。

名為 GraphQL 的終極定制

另一方面，GraphQL 是「非常能幹的私人服務員」。你遞給服務生一份訂單（查詢），上面寫著「漢堡（不含泡菜）、小份薯條和可樂」。然後服務生去廚房，把你指定的東西端到一個托盤上。

這是GraphQL最大的特色。前端（客戶）可以準確地指定他們想要什麼資料以及以什麼形式，後端將相應地傳回準確的資料量。

GraphQL 的好處和實作障礙

此機制具有以下優點：

減少通訊量： 在智慧型手機等行動環境中，不取得不必要的數據可以顯著提高效能。
靈活的UI變更： 即使您想要在螢幕上新增新的顯示項，也不需要像REST那樣讓後端建立新的端點，只需重寫前端查詢即可完成。

另一方面，它不是一根魔杖。還有諸如「快取難以控制」、「容易出現N+1問題」、「後端實現變得更加困難」等問題。對於簡單的部落格網站，REST API往往更簡單、更合適。

你該選擇哪一個？

GraphQL 是開發在單一畫面上顯示多種類型資源（使用者資訊、貼文、留言、按讚等）的複雜 Web 應用程式的最佳選擇。確定您的“餐廳”收到最多的訂單類型並選擇合適的架構。

Web 效能最佳化的最佳實踐

Wed, 05 Aug 2026 00:00:00 +0900

網站顯示速度是一個非常重要的因素，直接關係到使用者放棄率和SEO。然而，當談到效能優化時，過去的常識「就這樣做」實際上可能在現代瀏覽器環境中產生相反的效果。

在這裡，我們將揭穿常見的性能改進神話並探索真正的最佳實踐。

迷思 1：“所有圖片都應該延遲載入”

很容易誤解，如果你的圖片很重，添加 loading="lazy" 會讓它們變得更快。雖然它對於離螢幕圖像肯定有效，但將延遲加載應用於第一個視圖（打開頁面時看到的第一個區域）中的圖像是一個很大的錯誤。瀏覽器推遲了這個過程，導致 LCP（最大內容繪製）顯著惡化。正確的答案是優先載入第一視圖圖像（考慮fetchpriority =“high”`）。

誤解 2：“只需縮小 CSS 和 JS 就可以了。”

壓縮程式碼當然是必要的，但這還不夠。問題是，「您是否正在加載當前未使用的程式碼？」在現代方法中，「程式碼分割」很重要，它會拆分並僅加載每個螢幕所需的 CSS/JS。簡單地刪除不必要的第三方腳本（例如未使用的聊天工具和追蹤標籤）通常可以帶來顯著的改進。

迷思 3：“Google Lighthouse 得分 100 分就完美了。”

Lighthouse 的分數是一個很好的指標，但它只是您的 PC 和網路環境的模擬結果。真實用戶可能透過舊智慧型手機或不可靠的地鐵線路訪問它。 Core Web Vitals 的真正目的是“衡量實際用戶體驗”，稱為 RUM（真實用戶監控）。重要的是要定期使用 Google Search Console 等工具檢查實際的現場數據，而不是僅依賴 Lighthouse 分數。

持續監控的重要性

效能優化不是「設定好後就忘記」的任務。當您添加更多功能時，您的網站會變得有點重。最終的最佳實踐是將性能測試納入 CI/CD 管道中，並創建一個“防止惡化的系統”，在創建 PR 時檢測分數下降。

讓我們更新舊知識，為使用者提供真正舒適的網路體驗。

使用Supabase建置後端簡介

Fri, 31 Jul 2026 00:00:00 +0900

前端工程師的救星？

“構建後端非常耗時，因此很難製作應用程式原型。” 近年來，「Supabase」迅速獲得了有此類擔憂的開發商的支持。它經常被認為是 Firebase 的替代品，但到底有什麼區別呢？

我們以問答的形式總結了常見問題。

Q1：Supabase 是什麼？

答：它是一個開源的「BaaS（後端即服務）」。基於PostgreSQL，您可以非常輕鬆地將後端所需的全套功能（例如資料庫、認證功能、儲存和即時監聽器）合併到您的專案中。

Q2：與現有服務（Firebase等）有何不同？

A: 最大的差異是我們使用關聯式資料庫（RDB）。 NoSQL（例如 Firebase 的 Firestore）很有用，但如果您想使用 SQL 關聯複雜資料或執行進階聚合，基於 PostgreSQL 的 Supabase 將是一個非常強大的盟友。

Q3：適合什麼樣的項目？

答：個人發展與新創 MVP 發展的理想選擇。特別相容於React、Next.js等現代前端框架，只需載入SDK，幾行程式碼即可完成資料讀寫和使用者認證。

實際實作後我注意到了什麼

我自己在多個專案中使用過 Supabase，儀表板的直覺性給我留下了深刻的印象。您可以直接從瀏覽器建立表格、指定列資料類型，甚至設定稱為行級安全性 (RLS) 的安全性規則。

由於前端可以直接安全地存取資料庫，而無需建立 API 端點，因此開發速度提高了一倍以上。

這裡要小心

然而，這並不能完全消除對後端知識的需求。如果資料庫設計（規範化等）出現錯誤，後期將很難維護資料完整性，而如果RLS設定出現錯誤，則存在資訊外洩的風險。您至少需要學習 SQL 基礎知識和關聯式資料庫的設計理念。

未來展望

Supabase 仍在積極開發中，Edge Functions（無伺服器功能）等新功能正在陸續添加。毫無疑問，它不僅會演變成“資料庫的替代品”，而且會演變成一個全端應用平台。

如果您還沒有嘗試過，請在周末花幾個小時嘗試教學。您一定會愛上它舒適的開發體驗。

如何比較和選擇無頭 CMS

Sat, 25 Jul 2026 00:00:00 +0900

將前端和後端（管理螢幕）分開的「無頭 CMS」架構已在現代 Web 生產中牢固確立。然而，在介紹時，有「Contentful」、「microCMS」、「Strapi」等多種選項，許多人都困惑該選擇哪一個。

在本文中，我們將建議如何根據您的專案的特點和情況選擇最合適的 Headless CMS。

###情況一：如果你看重國貨的安全性和易用性

推薦：microCMS

“如果管理螢幕是英文的，客戶的負責人就無法更新。” MicroCMS 是日本製造的領先無頭 CMS，可以立即解決這個在合約生產中常見的問題。管理介面的UI非常精緻，即使IT素養不高的使用者也能直觀地提交文章。另外，日文官方文件豐富，支援系統完善。如果您有企業網站或中小型媒體網站，您一定應該毫不猶豫地選擇這個。

情境2：在全球企業領域

推薦：內容豐富

對於需要多語言部署、廣泛的內容版本控制和複雜的審批流程的大型項目，Contentful 是您的行業先鋒。它具有高度可擴展性，並具有廣泛的插件，可與各種第三方工具（翻譯工具、DAM 等）連結。但要注意的是，由於其功能豐富，學習成本較高，且定價結構面向大規模使用者。

情況 3：如果您想完全控制您的數據

推薦：斯特拉皮

SaaS類型的CMS無法滿足您的安全需求，或您希望將來新增自己的後端處理。在這種情況下，開源且可以託管在您自己的伺服器（或 AWS 等）上的 Strapi 是一個候選者。它運行在 Node.js 上，並且可以輕鬆自訂 API。儘管管理基礎設施需要時間和精力，但您可以在自由和資料所有權方面獲得巨大的好處。

引入的決定因素是“誰會使用它？”

選擇無頭CMS時最重要的是不僅要有開發人員的視角，還要有實際更新文章的經營者的視角。無論API回應多快，如果提交介面難以使用，內容就不會更新。首先，我們首先使用免費計劃，並讓操作員觸摸實際的管理螢幕，看看它是否適合。

使用 Tailwind CSS 進行高效能 USB 開發

Mon, 20 Jul 2026 00:00:00 +0900

直到幾年前，當涉及前端樣式時，通常的做法是根據 BEM 等命名約定提出唯一的類別名稱，並透過往返 CSS 檔案來建立設計。但現在，「Tailwind CSS」的出現徹底改變了這種情況。為什麼實用優先的概念吸引瞭這麼多的開發商？

這次，對於那些正在考慮實作Tailwind CSS的人，我們將徹底分析它的優點和缺點。

好處1：免去對類別名稱的深切擔憂

“我們應該為這個按鈕的包裝元素命名什麼……‘button-container’？‘action-wrapper’？” 你是否曾經因為這些無用的想法而浪費過時間？ Tailwind 將簡短的預先定義實用程式類別（「flex」、「p-4」、「text-center」等）直接加入 HTML 中，完全消除了命名類別的心理負擔。

好處 2：消除上下文切換

在傳統開發中，不可避免地要在編寫 HTML（或 JSX）、開啟 CSS 檔案和返回 HTML 之間來回切換。 Tailwind 直接在標記中編寫樣式，減少了眼球移動和文件導航，讓您可以在不中斷思考的情況下組裝組件。這比你想像的更快的開發速度。

缺點 1：HTML 看起來“髒”

Tailwind 的一個常見批評是 HTML 類別屬性變得太長，降低了可讀性。確實，一個複雜的組件有幾十個類，乍看之下很難理解發生了什麼。為了避免這種情況，React和Vue等框架需要劃分為元件單元，並進行設計以防止單一檔案變得太大。

缺點2：很難獲得獨特的CSS知識

因為我們過度依賴方便的實用程式類，所以我們往往忽略了對底層原始 CSS（Flexbox 規範、Grid 機制等）的理解。如果您不理解和使用 Tailwind 的類別名稱（它們所對應的 CSS 屬性），您在創建自己的複雜動畫和佈局時可能會陷入困境。

項目適宜性診斷

那麼，Tailwind CSS適合什麼樣的專案呢？總之，任何使用以元件為導向的現代框架（例如 React/Next.js/Vue/Nuxt）的專案幾乎肯定會受益。另一方面，如果您有一個僅使用舊的 HTML 檔案建立的靜態站點，或者一個沒有重複使用元件概念的環境，則結果可能只是更長的程式碼。

了解優勢和劣勢，並在正確的地方使用這個強大的武器。

使用 TypeScript 建立強大的 Web 應用程式

Tue, 14 Jul 2026 00:00:00 +0900

JavaScript 是一種非常靈活且易於編寫的語言，但其靈活性有時會在大規模開發過程中導致意想不到的錯誤。「我將一個數字傳遞給了一個需要字串的函數」或「我從 API 回應中存取了一個不存在的屬性」——每個人都至少經歷過一次這些錯誤。

在本文中，我們將使用問題與解決方案的方法來理解為什麼 TypeScript 對於現代 Web 應用程式開發至關重要。

挑戰：擔心執行前不知道錯誤

用純 JavaScript 編寫的應用程式的最大弱點是程式碼中的錯誤只能在執行時發現。除非您實際單擊瀏覽器中的按鈕或轉到特定螢幕，否則您不會注意到該錯誤。這會導致開發過程風險極高，只有透過 QA 團隊的測試遺漏或使用者的缺陷報告才能發現錯誤。

###解決方案：稱為「類型」的強大裝甲

透過引入 TypeScript，這個問題將會顯著改善。 TypeScript 將「靜態型別」的概念引入了 JavaScript。可以為變數、函數參數和傳回值建立規則（類型），例如「這是一個字串」或「這是一個具有特定結構的物件」。

這允許編輯器警告您，當您編寫程式碼或建立程式碼時，您在此處傳遞的值是不同類型的。這意味著許多錯誤可以在發生之前預防。

###挑戰：介紹學習成本與描述量

然而，有許多職場對於引入它猶豫不決，因為類型定義寫起來麻煩，學習成本高。誠然，一開始您可能會對「介面」、「類型」定義和泛型等不熟悉的概念感到困惑。編寫的程式碼量也會暫時增加。

解決方案：壓倒性的編輯器互補性和中長期生產力

然而，最初的投資可以很快收回。 TypeScript 與 VS Code 等現代編輯器具有很好的相容性。定義類型允許編輯器完美地推斷物件具有哪些屬性，並提供強大的自動完成功能。

一旦您體驗到只需按一個點即可建議下一個條目，而無需特意查看文件或規範，您將永遠不會回頭。即使在團隊開發中，也可以安全地呼叫其他人編寫的函數，從而降低溝通成本並提高開發速度。

而不是摘要

起初，您可能會覺得自己被迫遵守複雜的規則。然而，TypeScript 的類型系統並沒有約束開發人員；它是保護開發者免受 bug 恐懼的「盾牌」。如果您想建立健全且持久的 Web 應用程序，請嘗試使用 TypeScript。

Next.js App Router 基礎與好處介紹

Thu, 09 Jul 2026 00:00:00 +0900

「App Router」在 Next.js 13 中引入，現已成為標準。這個概念與先前的 Pages Router 相比發生了很大的變化，因此有些人可能仍然對遷移猶豫不決。本文提供了一個了解 App Router 基礎知識的逐步指南。

第 1 步：了解目錄結構的差異

在先前的 Pages Router 中，「pages」目錄中的檔案名稱被用作 URL 路由（例如，「pages/about.tsx」→「/about」）。

App Router 使用「app」目錄。 URL 路由由資料夾名稱決定，且規則已變更為始終將名為「page.tsx」的檔案放置在該資料夾中（例如「app/about/page.tsx」→「/about」）。雖然乍看之下這似乎很麻煩，但它有一個很大的優點，可以讓與路由無關的元件和測試檔案共存於同一個資料夾中。

第 2 步：理解佈局概念

App Router 的一個強大功能是「佈局」。建立 app/layout.tsx 可讓您將通用 UI（頁首、頁尾等）套用到該資料夾下的所有頁面。值得注意的是，這個Layout部分在頁面轉換時並沒有重新渲染。這樣可以在保留狀態的同時實現平滑的螢幕轉換，從而大大提高應用程式效能。

步驟 3：在伺服器與客戶端之間劃清界限

這是最重要的改變。 App Router 中的元件預設為 React Server Components（在伺服器端執行的元件）。您無法在伺服器元件內使用瀏覽器 API（例如「window」）或 React hook（例如「useState」和「useEffect」）。

如果需要按鈕點擊事件等，則需要透過在檔案頂部寫入「use client」來明確將其轉換為用戶端元件。 App Router 成功的關鍵是要記住“基本上，伺服器執行一些輕微渲染，只有互動部分留給客戶端。”

步驟 4：簡化資料擷取

先前所需的 Next.js 特定函數（例如「getServerSideProps」和「getStaticProps」）已被棄用。相反，只需在元件中直接透過“await”使用標準“fetch” API。 Next.js 內部擴充了 fetch ，現在您只需使用 fetch 的可選參數即可直觀地控制快取。

如果你一步步理解它，App Router 並不可怕。請向更先進、更快的 Web 應用程式開發邁出第一步。