All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
8668 bites
Page 268
Server Components: Fetch Data Directly
Server Components let you fetch data directly using async/await, simplifying code by removing client-side useEffect hooks. Use this for initial page loads in Next.js to improve SEO and performance. The footgun: don't use client-side hooks or browser APIs.
next.config.js: Your Next.js App's Control Panel
Think of next.config.js as your app's control panel, letting you change Next.js's default behavior. Use it for redirects, environment variables, or image optimization. The biggest footgun: you must restart your dev server after making any changes.
Next.js Route Groups: Invisible Folders for Routes
Route Groups are invisible folders for your Next.js routes, letting you organize files without changing the URL. Use them to apply a specific layout to a set of pages, like a marketing section vs. a user dashboard.
next/link: Fast, Client-Side Navigation
next/link is an enhanced <a> tag for fast, client-side page transitions, preserving the SPA feel. It automatically prefetches linked pages for instant loading.
Next.js: Pages Router vs. App Router
The App Router treats UI as a tree of components, while the older Pages Router treats it as a collection of separate pages. Use App Router for new projects to leverage layouts and Server Components.
cy.intercept: Control Network Traffic in Cypress Tests
cy.intercept acts like a programmable proxy in your Cypress tests, letting you watch, modify, or fake network requests. Use it to test loading states or error handling without a live backend. Footgun: intercepts are cleared before each test, not just once.
MSW: Mock APIs at the Network Layer
Mock Service Worker intercepts API calls at the network level using a Service Worker, so your app makes real requests. Use it for consistent mocking in development, testing, and Storybook.
Cypress for End-to-End Testing in Next.js
Cypress is a framework for end-to-end testing of Next.js applications. It's presented as a primary option in the official docs, alongside tools like Playwright and Vitest, for automating tests that simulate real user interactions in a browser.
Snapshot Testing: Lock In Your UI's Rendered Output
Snapshot testing catches unintended UI changes by comparing a component's rendered output to a saved 'golden' version. Use it to ensure UIs don't break during refactors. The biggest footgun is blindly updating snapshots, which can approve bugs as correct.
Handling Asynchronous UI with Testing Library
Your test shouldn't race your UI. Use async helpers to wait for elements to appear, disappear, or change after an event. This is crucial for testing components that fetch data. The footgun is forgetting await on findBy or waitFor calls.
Jest Mocks: Spies for Your Functions
A Jest mock is a spy that watches a function, recording calls without running the original logic. This lets you isolate code under test, verify interactions like callbacks, and control return values. The footgun is assuming mocks run real logic—they don't.
user-event vs. fireEvent: Testing Real User Interactions
user-event tests how users actually interact with your UI, not just isolated DOM events. It simulates a full action sequence, like a click firing pointerdown, mousedown, and click. Use it to test component behavior from a user's perspective.
Jest Matchers: Asserting Values in Your Tests
Jest matchers are assertion functions that check if a value meets a condition. You use them with expect() to verify function outputs, object properties, or promise states.
React Testing Library Queries: Find Elements Like a User
React Testing Library queries find elements by simulating how users see your UI, not by implementation details. Prioritize user-facing attributes like getByRole or getByLabelText.
Jest: The 'Batteries-Included' JavaScript Test Runner
Jest is a "batteries-included" JavaScript testing framework, bundling a runner, assertions, and mocking tools. It's a default for React apps but works for any JS project. The footgun is thinking it's only for React; it's a general-purpose tool.
Test Like a User: The React Testing Library Philosophy
React Testing Library's philosophy is to test components the way a user interacts with them, not by their internal implementation. This ensures refactors don't break tests. The footgun is querying by implementation details instead of what a user actually sees.
RTK Query: Your Redux Data Fetching Layer
RTK Query treats server data as a cache, not global state, handling fetching and loading states for you. Use it to replace manual fetch logic and keep data fresh across components. Forgetting to call setupListeners disables automatic refetching.
SSR State Hydration: Syncing Server and Client State
SSR hydration syncs server and client state to prevent UI errors. The server renders the page with initial data, then sends that data to the client to "hydrate" its own state store. The footgun is using a global store on the server, which leaks data.
State Normalization: Treat Your Store Like a Database
Treat your Redux state like a database. Instead of nesting related data, flatten it into separate 'tables' keyed by ID. This simplifies updates and prevents unnecessary re-renders. The footgun is storing API data as-is, creating update bugs.
Jotai Derived Atoms: Computed State from Other Atoms
Think of a derived atom like a spreadsheet formula: its value is computed from other atoms. Use it for reactive values like a cart total from item prices. The footgun: the get in your read function is reactive, but the get in your write function.