For an intern role, interviewers check that you understand what React is for, how components, props and state fit together, and how a Next.js app is organised into pages and layouts. Clear explanations and a small project you can talk about matter more than knowing every API.

React is a JavaScript library for building user interfaces out of components. Instead of manually updating the DOM when data changes, you describe what the UI should look like for a given state and React updates the page for you. That makes complex, interactive screens easier to build, reuse and reason about.

Next.js is a React framework. React gives you components; Next.js adds the rest of an application: file-based routing, server rendering and static generation, data fetching on the server, API endpoints (Route Handlers), image and font optimisation, and a production build setup. You write React components, and Next.js decides how and where they render.

JSX is a syntax extension that lets you write HTML-like markup inside JavaScript. It is compiled to function calls that create React elements. You can embed any JavaScript expression in curly braces, and attributes use camelCase names like className and onClick.

A few rules trip up beginners.

A component is a reusable piece of UI written as a JavaScript function that returns JSX. Its name must start with a capital letter so React can tell it apart from HTML tags. Components can be nested inside each other to build a whole page from small, focused parts.

Props are the inputs a parent passes to a child component, like arguments to a function. They are read-only: a component should never change its own props. Any value can be a prop — strings, numbers, objects, functions and even other JSX.

children is a special prop that holds whatever you put between a component's opening and closing tags. It lets you build wrapper components such as cards, layouts and modals that don't need to know what they contain.

State is data that a component remembers between renders and that can change over time, such as form input, whether a menu is open, or a counter. When state changes, React re-renders the component to show the new value. State is private to the component that owns it.

useState returns a pair: the current value and a function to update it. Calling the setter schedules a re-render with the new value. If the next value depends on the previous one, pass a function to the setter so you always work with the latest state.

Props come from the parent and can't be changed by the component that receives them. State is owned and updated by the component itself. A common pattern is for a parent to keep something in state and pass it down to children as props.

React only knows to re-render when you call the setter function. If you change an object or array in place (user.name = "x" or items.push(x)), React may not notice and the screen won't update. Always create a new value — setUser({ ...user, name: "x" }) or setItems([...items, x]).

Pass a function to an event prop such as onClick, onChange or onSubmit. Pass the function itself, not the result of calling it: onClick={handleClick}, not onClick={handleClick()}. To pass arguments, wrap it in an arrow function: onClick={() => remove(id)}.

Use normal JavaScript: an if statement before the return, the ternary operator cond ? <A /> : <B /> inside JSX, or cond && <A /> to render something or nothing. Be careful with && and numbers — {count && <p>...</p>} renders 0 when the count is zero.

Use the array map method to turn each item into JSX, and give each element a unique key prop, usually an id from your data. Keys help React track which item is which when the list changes.

A key is a unique, stable identifier for each item in a list. React uses keys to match items between renders, so it can keep the right state and DOM node for each one when items are added, removed or reordered. Avoid using the array index as a key when the list can change.

A Fragment lets you group several elements without adding an extra <div> to the DOM. You write it as <>...</>, or as <Fragment key={id}> when you need a key in a list. It keeps the HTML clean and avoids breaking layouts such as tables and flex containers.

The Virtual DOM is a lightweight description of the UI that React keeps in memory. When state changes, React renders a new description, compares it with the previous one and applies only the differences to the real DOM. This keeps updates efficient and lets you write code as if the whole UI re-renders every time.

Rendering means React calls your component function to get its JSX. A component re-renders when its state changes, when its parent re-renders, or when a context it uses changes. Re-rendering is normal and usually cheap; React then updates only the parts of the DOM that actually changed.

useEffect runs code after the component has rendered, to synchronise with something outside React: a browser API, a timer, a subscription or a non-React library. The dependency array controls when it runs again, and you can return a cleanup function.

It lists the values the effect uses. With no array the effect runs after every render; with an empty array [] it runs once after the first render; with values it runs again whenever one of them changes. Leaving out a value the effect reads leads to stale data bugs, so include everything the linter asks for.

Hooks must be called at the top level of a component or custom hook — never inside loops, conditions or nested functions — so they run in the same order on every render. And they can only be called from React function components or other hooks, not from regular functions. The eslint-plugin-react-hooks linter checks both rules.

Store the input's value in state, pass it as value, and update the state in onChange. React then always knows the current value, which makes validation and resetting easy.

Data flows down through props, so the parent passes a callback function to the child, and the child calls it with the data. For example, the parent gives onSelect={setSelected} and the child calls onSelect(item) when clicked.

There are several common approaches, and Next.js supports all of them.

Run npx create-next-app@latest (or the pnpm, yarn or bun equivalent) and answer the prompts for TypeScript, ESLint, Tailwind and the App Router. Then npm run dev starts the development server on localhost:3000, using Turbopack by default.

Routes live in the app folder: each folder is a URL segment and a page.tsx inside it makes that segment a page. layout.tsx wraps pages with shared UI, public/ holds static files served from the root, and config lives in next.config.ts. Many projects also keep components and helpers in folders like components/ and lib/.

The folder path inside app becomes the URL. app/page.tsx is /, app/about/page.tsx is /about, and app/blog/[slug]/page.tsx matches /blog/any-post. Only folders containing a page (or route) file are publicly reachable, so you can safely keep other files next to them.

page.tsx is the unique content of one route. layout.tsx wraps all pages in its folder and below with shared UI like a header or sidebar, and it stays mounted while you navigate between those pages, so its state is kept. The root layout in app/layout.tsx is required and must contain the <html> and <body> tags.

Use the <Link> component from next/link instead of a plain <a>. It navigates on the client without a full page reload, keeps shared layouts in place and prefetches linked pages in the background so navigation feels instant.

A dynamic route uses a folder name in square brackets, like app/blog/[slug]/page.tsx, to match many URLs with one page. The matched value arrives in the params prop. In current Next.js, params is a Promise, so you await it in a Server Component.

Files in public/ are served as-is from the site root: public/logo.png is available at /logo.png. Use it for favicons, robots.txt, and images or files that don't need processing. Don't put secrets there — everything in it is publicly downloadable.

next/image automatically serves the image at the right size for each screen, in modern formats like WebP or AVIF, lazy-loads it by default and reserves its space to prevent layout shift. You must give it width and height (or fill), and allow remote image hosts in the config.

In the App Router, components are Server Components by default: they render on the server, can fetch data directly and send no JavaScript of their own to the browser. A Client Component starts with the "use client" directive and runs in the browser too, so it can use state, effects and event handlers. Use client components only where you need interactivity.

Add "use client" at the top of a file when the component needs something only the browser has: useState, useEffect and other hooks, event handlers like onClick, or browser APIs such as window and localStorage. Everything that file imports becomes part of the client bundle, so keep client components small.

Make the component async and await the data directly — from fetch, a database or any server-side library. There's no need for useEffect or loading state for the first render, and secrets such as API keys stay on the server.

Exporting a metadata object from a page or layout sets the page's <title>, description, Open Graph and other <head> tags for SEO and link previews. For values that depend on data, such as a blog post title, export an async generateMetadata function instead.

Create a CSS file such as app/globals.css and import it once in the root layout. Global styles apply to every page; for component-specific styles, use CSS Modules or Tailwind instead so styles don't clash.

A CSS Module is a file named like Button.module.css. When you import it, each class name becomes a unique, locally scoped name, so .title in one component can't collide with .title in another. You use the classes as properties: className={styles.title}.

loading.tsx shows an instant loading UI for a route segment while its content is being fetched — Next.js wraps the page in a Suspense boundary for you. not-found.tsx renders when a route doesn't exist or when you call notFound() from a page, for example when a blog post slug isn't in the database.

error.tsx is an error boundary for a route segment: if something throws while rendering that segment, Next.js shows this file instead of crashing the whole app. It must be a Client Component, and it receives the error and a reset function so the user can try again.

Put them in .env.local (which is not committed to Git) and read them with process.env.NAME. By default variables are only available on the server. To expose one to the browser, its name must start with NEXT_PUBLIC_ — so never give secrets that prefix.

next dev starts a development server with fast refresh and helpful error overlays. next build creates an optimised production build, pre-rendering what it can. next start serves that production build. Always test performance on the production build, not the dev server.

Fast Refresh is the development feature that updates the page instantly when you save a file, while keeping component state where possible. If you edit a file that is not a component, or there's a syntax error, it falls back to a full reload and shows an error overlay.

React DevTools is a browser extension that shows the component tree, with each component's props, state and hooks. You can edit values live to test behaviour, find which component rendered an element, and use the Profiler tab to see which components re-render and how long they take.

Prop drilling is passing a prop through several intermediate components that don't use it, just to reach a deeply nested child. It makes code harder to change. Solutions include restructuring with children (composition), moving state closer to where it's used, or using React Context for truly shared values like the theme or the current user.

Context lets a parent make a value available to every component below it without passing props through each level. You create it with createContext, provide a value with <ThemeContext value={theme}> (or .Provider in older code), and read it anywhere below with use(ThemeContext) or useContext. It's best for values that change rarely.

TypeScript catches mistakes before the code runs: passing the wrong props, misspelling a field or forgetting a case. It also gives great autocomplete and makes refactoring safer. Next.js supports it out of the box — just name files .tsx and it creates the config for you.

Describe the props with a type or interface and annotate the function's parameter. Optional props get a ?, and you can give defaults in the destructuring.

The simplest path is Vercel: connect the Git repository and every push builds and deploys, with a preview URL for each pull request. Next.js also runs on any Node.js server with next build and next start, in a Docker container, on other platforms through adapters, or as a fully static export when no server features are used.

Pick one real project and walk through it briefly: what it does, why you built it, the main components and how data flows, one problem you hit and how you solved it, and what you would improve next. Have the code or a live link ready — a small, finished, well-explained project beats a big unfinished one.

Mid-level interviews expect you to build features end to end without hand-holding. You'll be asked how hooks really behave, how to manage state and data fetching, how the App Router renders and caches, and how you test and debug. Explain the trade-offs behind each choice, not just the API.

State is a snapshot for each render. Calling setCount(count + 1) schedules a re-render; the count variable in the current render keeps its old value. React also batches several updates from one event into a single render. If you need the next value immediately, compute it into a variable first, or use an updater function for consecutive updates.

Since React 18, multiple state updates in the same event, timeout, promise or native handler are grouped into one re-render. It avoids wasted renders and half-updated UI. In the rare case you must read the DOM right after an update, flushSync forces React to apply it immediately.

Use useReducer when state has several related fields, when the next state depends on the previous one in non-trivial ways, or when many event handlers update the same state. The reducer puts all update logic in one pure, testable function and the components just dispatch actions describing what happened.

Derived state is anything you can calculate from props or other state — a filtered list, a total, a full name. Storing it in its own state means you must keep two copies in sync, usually with an effect, which causes bugs and extra renders. Calculate it during render instead, and memoise it only if the calculation is genuinely expensive.

Give the component a key based on that prop: <Profile key={userId} userId={userId} />. When the key changes, React unmounts the old instance and mounts a fresh one with brand-new state. That's simpler and more reliable than an effect that resets each field.

After React commits a render to the screen, it runs the effect. Before running it again because a dependency changed, it first runs the previous effect's cleanup; when the component unmounts it runs the final cleanup. In development Strict Mode, React runs setup, cleanup and setup again once on mount to expose effects that don't clean up properly.

useEffect runs after the browser paints, so it never blocks what the user sees. useLayoutEffect runs after the DOM is updated but before the paint, which lets you measure layout and adjust before anything flickers — for example positioning a tooltip. It blocks painting, so use it only when you must measure the DOM.

When inputs change quickly, an old request can resolve after a new one and overwrite fresh data. Cancel stale requests with an AbortController in the cleanup, or ignore their results with a flag. Better still, use a data library or Server Components, which handle this for you.

A stale closure happens when a function captured during an old render keeps using that render's values — for example an interval callback that always sees count as 0. Fix it by listing the value in the effect's dependencies, using a functional updater (setCount(c => c + 1)), or reading the latest value from a ref.

useRef returns an object whose current property you can attach to a DOM node with the ref prop. In React 19, function components receive ref as a normal prop, so you can simply forward it to an inner element — forwardRef is no longer needed.

It lets a component expose a small, custom API through its ref instead of the raw DOM node — for example open() and close() methods on a dialog component. Use it sparingly: most of the time passing props is clearer than calling methods imperatively.

Write a function whose name starts with use and call other hooks inside it. It returns whatever the component needs. Each component that calls it gets its own state, so a custom hook shares logic, not data.

It's the safe way to subscribe a component to a store that lives outside React — browser APIs like navigator.onLine or matchMedia, or a third-party state library. You give it a subscribe function and a snapshot getter, plus a server snapshot for SSR, and React keeps every component consistent even during concurrent rendering.

useId generates a unique, stable id that is the same on the server and the client, so it is safe with SSR and hydration. Use it to link labels and inputs or ARIA attributes like aria-describedby. Don't use it for list keys.

Every component that reads a context re-renders when the provider's value changes by reference. If the value is a new object on every render, all consumers re-render every time. Memoise the value, split rarely- and often-changing data into separate contexts, and keep fast-changing state local or in a store with selectors.

Composition means building components by passing other components in — through children or named slot props like header and footer — instead of adding boolean props for every variation. It keeps components flexible and small, and it's also a simple fix for prop drilling.

Compound components are a set of components that work together and share state implicitly, usually through context — like <Tabs>, <Tabs.List>, <Tabs.Trigger> and <Tabs.Panel>. The parent manages the state and the parts read it, giving consumers a clean, declarative API with full control over markup.

Controlled inputs give React the value on every keystroke, which is good for live validation, formatting and dependent fields. Uncontrolled inputs leave the value in the DOM and you read it on submit with FormData — less code, fewer renders. With React 19 form Actions, the uncontrolled approach plus server validation covers many forms well.

You can pass an async function to a form's action prop. React calls it with the FormData, tracks the pending state and resets the form when it succeeds. useActionState wraps that action to also keep its last result, such as validation errors, and an isPending flag.

useFormStatus lets a component inside a <form> read whether that form is submitting, plus the submitted data. It's ideal for a reusable submit button that disables itself and shows a spinner without the parent passing a pending prop down.

use reads the value of a promise or a context during render. For a promise, the component suspends until it resolves, and the nearest Suspense boundary shows a fallback. Unlike other hooks, use can be called inside conditions and loops. A common pattern is starting a fetch in a Server Component and passing the promise to a Client Component that uses it.

React.lazy(() => import("./Chart")) splits a component into its own chunk that loads on first render. While it loads, the component suspends and the nearest <Suspense fallback={...}> shows the fallback. In Next.js you can use next/dynamic for the same thing in Client Components, with options like ssr: false.

Error boundaries catch errors thrown while rendering, in lifecycle methods and in the constructors of components below them. They do not catch errors in event handlers, in asynchronous code like setTimeout or promises, during SSR, or inside the boundary itself. Handle those with try/catch and report them to monitoring.

createPortal(children, domNode) renders children into a different DOM node, usually at the end of body, while keeping them in the same React tree for context and events. They're used for modals, tooltips, toasts and dropdowns that must escape parents with overflow: hidden or stacking contexts.

React.memo wraps a component so React skips re-rendering it when its props are shallow-equal to last time. It's worth it for components that render often with the same props and are expensive to render. It does nothing if you pass new object or function props every render — pair it with useMemo/useCallback or, better, let the React Compiler handle it.

The React Compiler is a build-time tool that automatically memoises components and values, so you rarely need useMemo, useCallback or React.memo by hand. It relies on your code following the Rules of React (pure render, no mutating props or state). Next.js supports it with the reactCompiler option in next.config.

React uses position and key to decide whether an element is "the same" as last time. Changing a key forces a fresh instance, which is a clean way to reset a form or restart an animation. Keeping the same key and type preserves state even if surrounding code changes.

Each folder can have its own layout.tsx, and layouts nest: the root layout wraps a section layout, which wraps the page. When you navigate between sibling pages, only the page re-renders — the shared layouts above it stay mounted and keep their state, such as an open sidebar or a playing video.

Both wrap child routes. A layout persists across navigations and keeps its state. A template creates a new instance on every navigation, so state resets and effects run again — useful for enter animations or logging page views per route.

A folder in parentheses, like app/(marketing)/about/page.tsx, organises routes without adding a URL segment — the page is still /about. Route groups let you give different sections different layouts (marketing pages vs the dashboard) or split the app into team-owned areas.

app/docs/[...slug]/page.tsx matches /docs/a, /docs/a/b and so on, giving params.slug as an array. [[...slug]] is optional and also matches /docs itself, where slug is undefined. They're handy for docs sites and CMS-driven pages.

Pages receive params and searchParams as Promises. In a Server Component you await them; in a Client Component you unwrap them with React's use, or read the URL with useParams and useSearchParams. Reading searchParams makes the page dynamic, because it depends on the request.

In a Client Component, use useRouter from next/navigation and call router.push("/path"), router.replace(), router.back() or router.refresh(). On the server — in a Server Component, Server Action or Route Handler — call redirect("/path") from next/navigation instead.

They are Client Component hooks from next/navigation: usePathname returns the current path, useSearchParams a read-only URLSearchParams for the query string, and useParams the dynamic route params. A component using useSearchParams should sit inside a Suspense boundary so the rest of the page can still be pre-rendered.

When a <Link> enters the viewport in production, Next.js prefetches the route in the background so navigation is near-instant. For static routes it prefetches the whole page; for dynamic routes it prefetches up to the nearest loading boundary so the loading UI appears immediately. You can turn it off with prefetch={false} for rarely used links.

Default to Server Components for anything that fetches data, uses secrets or is mostly static, because they send no JavaScript. Switch a component to the client only when it needs state, effects, event handlers or browser APIs. Push the client boundary as far down the tree as possible — make the button interactive, not the whole page.

You can't import a Server Component into a Client Component file — it would become client code. But you can pass a Server Component as children or another prop to a Client Component from a server parent. That's the standard way to wrap server-rendered content in an interactive shell such as a modal or tabs.

Keep database access, secrets and heavy libraries in Server Components, Server Actions and Route Handlers. Add import "server-only" to modules that must never be imported by client code — the build fails if they are. Only NEXT_PUBLIC_ environment variables reach the browser.

Route Handlers are API endpoints in the App Router, defined in a route.ts file that exports functions named after HTTP methods. They use the standard Web Request and Response APIs. Use them for webhooks, public APIs, file downloads and anything called by non-React clients.

Server Actions are async functions marked with "use server" that run on the server but can be called from forms and Client Components. Next.js turns each one into a secure POST endpoint for you. They're ideal for mutations — creating, updating, deleting — followed by revalidating cached data or redirecting.

Use Server Actions for mutations triggered by your own UI — form submissions and button clicks — because they integrate with forms, pending states and revalidation. Use Route Handlers when something outside your React UI calls the endpoint: webhooks, mobile apps, third-party integrations, or responses that aren't UI, like files and feeds.

Start independent requests before awaiting any of them and combine them with Promise.all, so the page waits for the slowest request, not the sum of all of them. For parts of the page that can appear later, put them in their own components inside Suspense so they stream in independently.

A loading.tsx file wraps the route segment in a Suspense boundary, so its UI shows instantly on navigation. Inside a page, wrap slow components in <Suspense fallback>: the server sends the rest of the HTML immediately and streams each slow part in when its data is ready.

Cached data can be refreshed on a timer or on demand. On demand, call revalidatePath("/blog") or revalidateTag("posts", "max") from a Server Action or Route Handler after data changes — revalidateTag serves the stale version while it refreshes in the background. Inside a Server Action, updateTag expires the data immediately so the user sees their own change at once.

Export an async generateMetadata function from the page; it receives the same params and can fetch data (requests are deduplicated with the page's own fetch). For social images, add an opengraph-image.tsx file that returns an ImageResponse, and Next.js generates the image and the meta tags.

next/font downloads Google or local fonts at build time and serves them from your own domain, so there are no requests to third parties at runtime. It also sets fallback font metrics to avoid layout shift and exposes the font as a class name or CSS variable.

List the allowed hosts in images.remotePatterns in next.config.ts so the image optimiser only processes images from sources you trust. Then pass the full URL with width and height, or use fill inside a positioned container with a sensible sizes value.

Use a test runner like Vitest or Jest with React Testing Library. Render the component, find elements the way a user would (getByRole, getByLabelText), interact with @testing-library/user-event and assert on what's visible. Mock network calls with MSW instead of mocking your own modules.

Unit- and integration-test Client Components and pure logic with Vitest or Jest and React Testing Library. Async Server Components are not well supported by these tools yet, so cover pages, Server Actions and routing with end-to-end tests in Playwright against a running app. Test business logic in plain functions you can call directly.

Hydration fails when the server-rendered HTML doesn't match the first client render: using Date.now(), Math.random(), window or localStorage during render, locale-dependent formatting, invalid HTML nesting, or browser extensions changing the DOM. Read the diff in the error overlay, make the first render identical on both sides, and move browser-only values into an effect.

Senior React and Next.js interviews focus on how things work underneath and how you'd design for real traffic: reconciliation and concurrent rendering, the Server Components model, Next.js caching and Partial Prerendering, performance, security and the architecture of large codebases. Strong answers explain the mechanism, the trade-off and how you'd verify it.

React compares the new element tree with the previous one using two heuristics that make it linear time: elements of different types produce entirely new subtrees, and children in a list are matched by key. For the same type, React keeps the DOM node or component instance and updates only changed props. The cost is that changing a component's type or key throws away its state.

Fiber is React's internal architecture since React 16. Each component is represented by a fiber — a unit of work — so rendering can be split into small pieces, paused, resumed, prioritised or thrown away. That is what makes concurrent features like transitions, Suspense and selective hydration possible.

In the render phase React calls your components and computes what changed; this work must be pure because it can be interrupted, repeated or discarded. In the commit phase React applies the changes to the DOM, sets refs and runs layout effects synchronously, then runs passive effects (useEffect) after the browser paints.

Rendering is no longer one blocking task. React can prepare a new UI in the background, interrupt it for an urgent update like typing, and show it only when ready. You opt in per update with startTransition, useDeferredValue and Suspense; urgent updates still render synchronously as before.

Use useTransition when you own the state update: wrap the slow update in startTransition and use isPending to show feedback. Use useDeferredValue when you only receive a fast-changing value, such as a prop or search text, and want a heavy child to render with a lagging copy of it. Both keep inputs responsive and improve INP.

When a component reads data that isn't ready — through use(promise), a lazy component or a Suspense-enabled library — it suspends instead of returning JSX. React shows the closest Suspense fallback and retries that subtree when the data resolves. Already-visible content isn't replaced by a fallback during a transition; React keeps the old UI until the new one is ready.

Render on the server with data fetched there, pass only serialisable values to Client Components as props, and let client-side libraries hydrate from that initial data — for example TanStack Query with a dehydrated cache. Never create a module-level store that is shared across requests on the server; create stores per request to avoid leaking one user's data to another.

Server Components don't send their code to the browser. Instead the server streams a serialised description of the rendered tree — the RSC payload — with HTML elements, props for Client Components and references to their JavaScript chunks. On the client React merges this payload into the tree, which is how navigations update server-rendered parts without a full reload.

"use client" marks a boundary in the module graph, not a single component: that file and everything it imports become part of the client bundle. Client Components still render on the server for the initial HTML, then hydrate in the browser. Because the boundary pulls in all imports, put it on small leaf components.

Every Server Action is a public HTTP endpoint, even if no button calls it. So inside every action you must authenticate the user, authorise the specific operation and validate all input — for example with Zod. Never trust IDs or prices sent from the client, avoid returning sensitive data, and remember that closures and arguments are encrypted but not hidden from a determined attacker.

With cacheComponents enabled, nothing is cached implicitly: data fetching runs at request time unless you opt in. You mark functions, components or whole pages with the "use cache" directive, set their lifetime with cacheLife (for example "hours" or "days") and label them with cacheTag so you can invalidate them later. It makes caching explicit and predictable compared with the older implicit fetch cache.

Partial Prerendering serves a static shell of a route instantly from the edge and streams the dynamic parts into the same response. Everything outside Suspense boundaries that doesn't read request data is prerendered; components that read cookies, headers or uncached data render per request inside their boundaries. You get static speed and dynamic content on one page; with Cache Components it is the default model.

Each invalidates cache differently.

A route can be prerendered at build time unless it reads something only known at request time: cookies(), headers(), searchParams, connection() or uncached data. Since these APIs are async, Next.js can tell exactly where dynamic data is needed. With Cache Components, those dynamic parts must sit inside Suspense so the rest of the page stays static.

Exported from a dynamic route such as app/blog/[slug]/page.tsx, generateStaticParams returns the list of params to prerender at build time. Params not in the list can still be rendered on demand and cached, or you can return a 404 for them with dynamicParams = false. It's how you statically build thousands of product or blog pages.

Parallel routes render several pages in the same layout at once using named slots — folders starting with @, like @analytics and @team. The layout receives each slot as a prop. Each slot can have its own loading and error states and navigate independently, which suits dashboards and split views. A default.tsx in a slot defines what to show when it has no match.

Intercepting routes load a route inside the current layout instead of navigating away, using folder prefixes like (.)photo/[id]. The classic case is a photo feed: clicking a photo opens it in a modal over the feed, but sharing or refreshing the URL shows the full photo page. Combined with a parallel @modal slot, it gives shareable, back-button-friendly modals.

proxy.ts (formerly middleware.ts) runs before a request is matched to a route. It can redirect, rewrite, set headers and cookies or return a response early — useful for locale detection, A/B routing and quick auth checks. It should stay fast and light: do the real authorisation next to the data, because proxy is a network boundary, not a security boundary on its own.

Store the session in an HttpOnly, Secure, SameSite cookie, either as an encrypted stateless token or as an id pointing to a database session. Create a data-access layer with a cached verifySession() function and call it in every page, Server Action and Route Handler that touches protected data. Use proxy only for fast redirects, and never rely on a layout alone to protect a page, since layouts don't re-run on every navigation.

after() schedules work to run after the response has been sent to the user — logging, analytics, sending emails or cache warming. The user gets their page without waiting for those side effects, and the platform keeps the function alive until they finish.

Use error.tsx boundaries per route segment so a failure only takes down that part of the page, plus global-error.tsx for the root layout. Use notFound() for missing data so users get a real 404. In Server Actions, return expected errors such as validation failures as values, throw only for unexpected ones, and report everything to monitoring through instrumentation.ts.

instrumentation.ts at the project root exports a register function that runs once when a server instance starts — the place to set up OpenTelemetry, error tracking or other observability tools. Its onRequestError hook reports server errors with context like the route and request, which you can forward to Sentry or a similar service.

Run the bundle analyser to see what each route ships, then attack the biggest wins: move components back to the server, push "use client" boundaries down, lazy-load heavy client widgets with next/dynamic, replace large libraries, and use optimizePackageImports for icon and utility libraries. Set a bundle budget per route in CI so it doesn't creep back.

Measure first with the React DevTools Profiler and "highlight updates" to see which components render and why. Common causes are context values recreated every render, new object or function props, state kept too high in the tree, and unstable keys. Fix by moving state down, splitting components or contexts, memoising where it matters — or enabling the React Compiler.

Find slow interactions with real-user data and the Performance panel, then shorten the work between input and paint: wrap non-urgent updates in transitions, virtualise long lists, avoid re-rendering large trees on every keystroke, move heavy computation off the main thread, and cut hydration cost by shipping less client JavaScript. Third-party scripts loaded with next/script and strategy="lazyOnload" also help.

Make the LCP element render from the server HTML, not from client fetching. Use next/image with priority (or preload) and a correct sizes for the hero image, serve fonts with next/font, keep render-blocking CSS small, and prerender or cache the page so the HTML arrives fast from the CDN. Check the LCP breakdown to see whether time goes to the server, loading or rendering.

Hydration has to download, parse and run the JavaScript for every Client Component, then attach handlers, so large client trees delay interactivity. React 18+ hydrates Suspense boundaries independently and prioritises the part the user is interacting with (selective hydration). The real fix is less client code: Server Components for static parts and small client islands for interactive ones.

Separate state by owner. Server data lives in Server Components or a client query cache; URL state (filters, pagination, tabs) lives in searchParams; form state lives in forms and Actions; only genuinely shared client state — a cart, an editor, a multi-step wizard — goes into a store like Zustand or Redux Toolkit, created per request when used on the server. Keep each piece as local as possible.

Server Components cover the initial data for most pages. A client query cache still earns its place for highly interactive data: infinite scrolling, polling, optimistic updates across many components, offline support and background refetching. A common pattern is to prefetch on the server and hydrate the client cache so there is no loading flash.

Build on accessible headless primitives (Radix, React Aria, Base UI) and style them with design tokens. Prefer composition and compound components to long prop lists, forward refs and native attributes, support controlled and uncontrolled use, and mark only interactive pieces as Client Components so the library works well with Server Components. Document in Storybook and test visually and for accessibility.

Use native elements first, then follow the WAI-ARIA Authoring Practices for widgets like comboboxes, tabs, menus and dialogs: correct roles, aria-* states, roving focus with arrow keys, focus trapping in modals and returning focus on close. Headless libraries implement these patterns well. Test with a keyboard and a real screen reader, not only automated checks.

Put the locale in the URL (/en/..., /my/...) with a [locale] segment, detect the preferred locale in proxy.ts and redirect, and load message catalogues on the server so translations don't bloat the client bundle. Libraries like next-intl handle formatting and plurals. Set lang on <html>, add hreflang alternates for SEO and use Intl APIs for dates and numbers.

Render real content on the server, set unique titles and descriptions with the Metadata API, add canonical URLs and alternates for translations, and generate sitemap.ts, robots.ts and Open Graph images with the file conventions. Add JSON-LD structured data in the page, keep Core Web Vitals green, and make sure every important page is reachable through real links.

React escapes text, so the main XSS risks are dangerouslySetInnerHTML with unsanitised HTML, javascript: URLs in href, and spreading untrusted props onto elements. Also watch for secrets leaking through NEXT_PUBLIC_ variables or props passed to Client Components, and for Server Actions without authorisation. Use the taint APIs to stop sensitive objects reaching the client by mistake.

Generate a fresh nonce per request in proxy.ts, set the Content-Security-Policy header with script-src 'nonce-…' 'strict-dynamic', and pass the nonce on the request headers. Next.js applies it to its own scripts automatically, and you read it with headers() for third-party Script tags. Nonces require dynamic rendering, so for fully static pages use hashes or a looser policy.

Keep business logic in plain functions or a data-access layer and unit-test it directly. Server Actions can be called like normal async functions in tests if you mock their dependencies (auth, database). For async Server Components and full flows — routing, streaming, caching — rely on Playwright end-to-end tests against a production build.

Run Playwright against next build && next start, not the dev server. Use role- and label-based locators, rely on auto-waiting assertions, seed a test database and reset it per test or worker, and mock only external services. Cover critical journeys — sign-up, checkout, publishing — and run them on every pull request against preview deployments.

Vercel supports every feature with zero configuration. Self-hosting with next start on Node or in Docker also supports nearly everything, but you then own caching across instances (a custom cache handler for multiple servers), image optimisation resources and scaling. Static export suits sites with no server features. Choose based on traffic patterns, compliance, cost and the team's operations skills.

Each instance has its own in-memory cache, so configure a shared cache handler (for example Redis) for ISR and "use cache" data, and make revalidation reach all instances. Set the same build ID and encryption key for Server Actions on every instance, serve static assets from a CDN, and give the image optimiser enough CPU and memory.

Report Core Web Vitals from real users with useReportWebVitals or an RUM tool, send client and server errors to a tracker like Sentry with source maps and release tags, and use OpenTelemetry through instrumentation.ts to trace slow server renders and data calls. Alert on error spikes, vitals regressions and cache hit-rate changes after each deploy.

Incrementally — both routers can run in the same app. Move the root layout and shared providers first, then migrate routes one at a time, starting with simple, mostly static pages. Replace getServerSideProps and getStaticProps with Server Components that fetch directly, API routes with Route Handlers or Server Actions, and next/router with next/navigation, testing each route as it moves.

Many mistakes repeat across teams.

A waterfall happens when a parent awaits data, then renders a child that awaits more data, one after another. Start independent fetches early and await them together, move fetching into the components that need it and wrap them in Suspense so they load in parallel, and use React's cache() so several components can ask for the same data with only one request.

cache(fn) memoises a function for the duration of one server request. If several Server Components call getUser(id) while rendering the same page, the work runs once. It's ideal for database or auth calls that aren't plain fetch, and it is scoped to the request, so data never leaks between users.

Call useOptimistic in a Client Component to apply the expected change immediately, then call the Server Action inside a transition or form action. When the action finishes, React swaps the optimistic state for the real data returned or revalidated by the server; if it throws, the optimistic change disappears and you show an error.

Serverless functions don't hold long-lived connections well, so real-time usually goes through a dedicated service: a WebSocket server, a hosted service like Pusher, Ably or Supabase Realtime, or Server-Sent Events from a long-running server. The client component subscribes, merges updates into its state or query cache, and reconnects with backoff.

When several apps — say a marketing site, a dashboard and an admin — share a design system, types and utilities. Tools like Turborepo or Nx give cached, affected-only builds, and shared packages can be transpiled with transpilePackages. Keep clear ownership and module boundaries, or the shared packages become a bottleneck.

Upgrade often in small steps rather than skipping majors. Read the upgrade guide, run the official codemods (npx @next/codemod), fix deprecation warnings early — such as renaming middleware to proxy or making params async — and rely on type checks and end-to-end tests to catch regressions. Try canary releases in a branch to see breaking changes coming.

Prerender the product shell — images, description, reviews summary — with "use cache" and tags per product, so it's served from the CDN. Stream user-specific parts (price for the user's region, stock, cart state) inside Suspense. Add to cart with a Server Action plus optimistic UI, revalidate the product tag when inventory changes, and measure LCP and INP on real devices.

Start from real-user Core Web Vitals per route and device. Then check what each route ships to the client and where "use client" sits, whether pages are static, cached or fully dynamic and why, server timings and data waterfalls, image and font handling, third-party scripts, and cache hit rates on the CDN. Fix the biggest measured problems first and re-measure.

At tech lead level the questions are about decisions and people: which architecture the team should adopt, how to keep a large React and Next.js codebase healthy, how to ship safely and how to grow engineers. Interviewers want structured reasoning, honest trade-offs and examples of you making the team better, not just yourself.

Start from requirements. Content and commerce sites that need SEO, fast first loads and server data suit Next.js. An internal dashboard behind a login, with no SEO needs, can be a simple Vite single-page app. Remix/React Router, Astro or TanStack Start fit other shapes. Weigh hosting, team experience, ecosystem and lock-in, prototype the hardest feature, and record the decision in an ADR.

Write a short, shared rule set: server by default; client only for interactivity, kept in leaf components; data access through one server-only layer; Server Actions validate and authorise every input; and clear naming such as a *.client.tsx convention if helpful. Back it up with lint rules, server-only imports, examples in the codebase and review checklists.

Keep app/ thin — routes, layouts and wiring — and put real code in feature modules (features/checkout, features/search) each with its components, server actions, data access and tests. Shared UI goes in a design-system package, and cross-cutting code in lib/. Enforce boundaries with lint rules so features don't import each other's internals.

Document one approach: where data is fetched (Server Components through a data-access layer), what is cached with "use cache", the standard cacheLife profiles, a tag-naming convention, and which mutations call updateTag or revalidateTag. Without a written strategy each developer invents their own and nobody can predict when a page shows stale data.

Treat it as a programme, not a ticket. Audit routes by traffic and complexity, build the shared root layout and providers first, then migrate in slices — low-risk static pages, then data-heavy ones — with both routers live. Track progress on a dashboard, give the team examples and codemods, protect feature delivery, and set a date to delete the old router.

Read the upgrade guide and test it in a spike branch first, then run codemods and fix deprecations. Upgrade the shared packages and one pilot app, monitor it in production, and write a migration note for the rest. Keep dependency versions aligned across the monorepo so apps can't drift several majors apart.

Agree on a decision tree rather than a single library: server data stays on the server or in a query cache, URL state in the URL, form state in forms and Actions, local UI state in components, and only genuinely shared client state in one approved store such as Zustand or Redux Toolkit. One sanctioned option per category keeps the codebase consistent.

A short checklist keeps reviews consistent.

Strict TypeScript, ESLint with the React Hooks, Next.js and jsx-a11y plugins, Prettier, import-boundary rules and the React Compiler's lint rules. Run them in pre-commit hooks for speed and in CI as a gate, together with type checks, tests and bundle-size limits. Explain each rule and auto-fix wherever possible.

Tie budgets to user outcomes: LCP under 2.5 s and INP under 200 ms at the 75th percentile, plus a client JavaScript limit per route. Measure in CI with Lighthouse and bundle analysis, and in production with real-user monitoring split by route and device. Make a failed budget block the merge or open a ticket with an owner.

Make it a product with an owner team: design tokens shared between Figma and code, accessible primitives, documentation in Storybook, visual and accessibility tests, semantic versioning and changelogs. Run a contribution process so product teams can add components, track adoption, and publish codemods for breaking changes.

Buy the hard, generic parts — accessible primitives such as dialogs, menus and comboboxes — from a headless library, and build the brand layer on top. Building fully from scratch is only worth it when you have unusual needs and the capacity to maintain accessibility and browser support for years. Evaluate bundle size, Server Component compatibility, maintenance activity and licence.

Make the design system accessible by default, include accessibility in the definition of done, add jsx-a11y linting and axe checks in tests, and audit key flows with keyboard and screen readers each quarter. Train designers and engineers, and assign an accessibility champion per team so it doesn't depend on one person.

Static checks as the base, many integration tests of components and features with Testing Library and MSW, unit tests for complex logic, and Playwright end-to-end tests for critical journeys against production builds. Add visual regression for the design system. Agree on what must be tested before merge, and keep the suite fast and flake-free so people trust it.

Use Turborepo or Nx remote caching so unchanged packages aren't rebuilt or retested, run only affected projects on pull requests, shard Playwright across machines and cache dependencies. Set a target time for the pipeline, track it, and quarantine flaky tests quickly instead of letting retries hide them.

Every pull request gets a preview deployment for review. Merges to main deploy automatically, unfinished work hides behind feature flags, and risky changes roll out gradually while you watch errors and Core Web Vitals. Keep instant rollback to the previous deployment, and remember that Server Action IDs and assets change between builds, so plan for clients running an old version.

Stabilise first — roll back or disable the flag rather than debugging live — and communicate status, impact and the next update time in one channel. Once users are safe, find the root cause with traces and error reports, fix it with a test, and run a blameless post-mortem with owners and dates for the follow-up actions.

Keep a visible debt list linked to real costs — slow features, bugs, outdated patterns like class components or Pages Router code — and prioritise debt in the parts of the code that change most. Reserve a regular share of each sprint for it, pay it down when touching nearby code, and explain it to product in terms of delivery speed and risk.

Start with the problem it solves. Prototype it on one real feature, write a short proposal or ADR with alternatives and costs, and invite feedback. If adopted, add an example to the codebase, a lint rule or codemod if relevant, and a short session to explain it — and agree how the old pattern will be retired.

One-command local setup with seeded data, an architecture overview that explains the routing, data and caching model, and a guided first ticket that touches a real feature end to end. Pair them with a buddy, point them to good example features to copy, and ask them to improve the onboarding docs as they go.

Find the specific gaps — often state, effects or the render cycle — through pairing rather than assumptions. Give focused exercises and small real tasks, review their code with explanations of why, point them to the official React docs, and check progress in regular one-to-ones. Celebrate improvements and increase scope gradually.

Use a structured format with a rubric shared by all interviewers: a practical exercise such as building or fixing a small component, a discussion of a past project, and a design question scaled to the level — for seniors, how they'd architect data and caching for a page. Look for reasoning and communication, not memorised APIs, and give every candidate the same chance.

Make upgrades routine and small so they never become a big project: a regular slot each sprint or month, automated dependency updates and codemods. Explain to product that staying current keeps security patches flowing and prevents a costly forced migration later. Bundle bigger upgrades with features that benefit from the new capabilities.

Break it into vertical slices by user value, estimate each in ranges, and add explicit buffers for unknowns like integrations and design changes. Spike the riskiest parts first, deliver a thin end-to-end version early, and re-forecast regularly based on actual progress rather than defending the original number.

Involve engineers early to flag feasibility, performance and accessibility concerns, share one set of tokens and components between the design tool and code, and agree how responsive, loading, empty and error states are specified. Review work in progress together and use preview deployments so designers check the real thing, not screenshots.

Design the API around what the screens need, write the contract first as OpenAPI or a GraphQL schema, generate TypeScript types and mocks from it, and add contract tests in CI. If the front end needs a different shape, consider a backend-for-frontend layer — in Next.js, Route Handlers or a server-only data layer can play that role.

Talk about outcomes: pages load faster because less code is sent to phones, search engines see the full content, and sensitive logic stays on the server. Back it with numbers from a pilot — for example JavaScript per page down by a third and LCP improved — and the cost in time and risk of adopting it.

Move from opinions to criteria: what are we optimising for — performance, simplicity, speed of delivery? Let each side present, run a short spike if evidence can settle it, and then make or facilitate a decision with the reasoning written down. Ask everyone to commit, and agree when the decision will be reviewed.

Use mature ecosystem tools for solved problems — authentication, forms, data fetching, headless UI, internationalisation — and build what differentiates your product. Judge each dependency by maintenance health, bundle size, compatibility with Server Components, licence and the cost of replacing it later.

Keep the dependency list short, automate updates with Renovate or Dependabot, audit packages in CI, and pin versions with a lock file. Review new dependencies before adding them, watch for supply-chain attacks and typosquatting, and keep Next.js and React on supported versions so security fixes arrive quickly.

Lean on static and cached rendering so most requests are served by the CDN, cache data with clear tags and lifetimes, and protect data sources with rate limits and request deduplication. Load-test the dynamic routes, watch cache hit rates and server latency, and make sure self-hosted setups share their cache between instances.

Product and user metrics — Core Web Vitals, error rates, conversion on key flows — alongside delivery metrics like deployment frequency, lead time, change failure rate and time to restore. Add developer-experience signals such as CI time and survey results. Use them to find bottlenecks, never to rank individual engineers.

Measure where time goes, then remove friction: fast local dev with Turbopack, quick and reliable CI, generators for new routes and components, clear examples, good error messages, typed environment variables and preview deployments for every pull request. Small improvements save time for every engineer every day.

Align teams with product domains and give each one route groups and feature packages it owns, enforced with CODEOWNERS and import boundaries. A platform team owns the design system, shared tooling and the root layout. If teams truly need independent deployments, consider multi-zones before reaching for micro-frontends.

Only when many independent teams must release parts of one product on separate schedules and the organisational pain is real. The costs are significant — duplicated dependencies, inconsistent UX, shared state and routing complexity. In the Next.js world, multi-zones (separate apps under one domain) are often a simpler middle ground.

Compare total cost and capability. A managed platform gives every feature, previews and scaling with little operations work. Self-hosting gives control over cost, region and compliance but you own caching across instances, image optimisation, scaling and monitoring. Choose based on traffic, budget, regulations and the operations skills your team really has.

Agree on the requirements up front — URLs, metadata, structured data, page speed — and build them into the platform: the Metadata API with sensible defaults, generated sitemaps and Open Graph images, canonical and hreflang tags, and server-rendered content. Give marketing a CMS for titles and descriptions, and monitor Search Console and Core Web Vitals.

Decide early on the URL structure and locale detection, keep messages in a translation system with ICU plurals, load them on the server, and format dates, numbers and currencies per locale. Plan the layout for longer text and different scripts — Burmese needs taller line height, Arabic needs right-to-left — and include translators and native speakers in reviews.

Collect only necessary data, document it, and respect consent before loading analytics or marketing scripts — next/script lets you load them conditionally. Keep personal data out of logs, client bundles and error reports, choose hosting regions that meet data-residency rules, and review third-party scripts regularly.

State the problem, goals and non-goals, then the proposed design: routes, component boundaries, data flow, caching and revalidation, error states and accessibility. List the alternatives considered, risks, the rollout plan and how success is measured. Share it early as a draft and keep it short enough that people actually read it.

Rotate people through critical areas, pair on complex changes, require reviews from more than one person, and keep runbooks and architecture docs up to date. Make sure at least two people can deploy, debug and roll back each app — and notice when you yourself have become the only person who understands something.

Talk privately and early, with specific examples and curiosity about the cause — unclear expectations, skills, workload or personal issues. Agree on clear goals and support, such as pairing or smaller well-defined tasks, check in regularly and document progress. Involve your manager if things don't improve within the agreed time.

Stay hands-on in a focused way: review pull requests, build prototypes and spikes, take non-critical tickets, and read release notes and RFCs. Try new features in side projects before proposing them to the team. Being current lets you make credible decisions without being on the critical path.

Your main output is the team's output, so prioritise unblocking people, clarifying direction and reviewing work. Keep enough coding to stay sharp, but avoid owning critical-path tasks because your time is interrupted. Protect focus time for deep work like design documents and prototypes.

Make learning part of normal work: lunch-and-learn sessions, reading groups on new React features, rotating ownership of a "what's new" summary, and time-boxed spikes on real problems. Encourage people to write short internal posts, celebrate experiments even when they fail, and model it by sharing what you are learning yourself.

Almost always refactor incrementally. A rewrite throws away years of bug fixes and stalls feature work, and often fails. Consider it only when the platform is truly unsupported or can't meet requirements; even then, use the strangler approach — new routes in the new stack behind the same domain — so value ships continuously and risk stays small.

Use the STAR structure: the situation and constraints, the options you weighed, the decision and why, and the outcome with numbers if possible. Include what you would do differently. Interviewers look for structured reasoning, communication with stakeholders and learning, not a perfect result.

Listen before changing things: hold one-to-ones, read the code and the history behind decisions, and ask what frustrates people. Deliver a few small improvements the team asked for, keep your promises, give credit generously and be open about your own mistakes. Trust comes from consistency more than from big announcements.

The direction is more work on the server and less JavaScript on the client — Server Components, streaming, Partial Prerendering and explicit caching — plus compilers that remove manual optimisation. Prepare the team by building fundamentals over APIs, keeping the codebase upgrade-friendly, trying new features in low-risk areas and adopting them when they solve real problems.

First month: meet everyone, learn the product, map the architecture, the delivery pipeline and the pain points. Second month: deliver a few quick, visible improvements — a faster CI, a fixed performance hotspot, clearer conventions. Third month: share a written technical vision and roadmap agreed with the team and stakeholders, covering architecture, quality and people growth.

Intern role အတွက် interviewer တွေက React က ဘာအတွက်လဲ၊ component၊ props နဲ့ state တွေ ဘယ်လိုချိတ်ဆက်အလုပ်လုပ်လဲ၊ Next.js app တစ်ခုကို page နဲ့ layout တွေအဖြစ် ဘယ်လို စီစဉ်ထားလဲ ဆိုတာကို နားလည်လား စစ်ပါတယ်။ API တိုင်းကို သိထားတာထက် ရှင်းလင်းတဲ့ ရှင်းပြချက်နဲ့ ပြောပြနိုင်တဲ့ project အသေးလေးတစ်ခုက ပိုအရေးကြီးပါတယ်။

React ဆိုတာ component တွေနဲ့ user interface တည်ဆောက်ဖို့ JavaScript library ပါ။ Data ပြောင်းတိုင်း DOM ကို ကိုယ်တိုင် update လုပ်မယ့်အစား state တစ်ခုအတွက် UI က ဘယ်လိုပုံစံ ဖြစ်ရမလဲ ဖော်ပြလိုက်ရုံနဲ့ React က page ကို update လုပ်ပေးပါတယ်။ ဒါကြောင့် ရှုပ်ထွေးပြီး interactive ဖြစ်တဲ့ screen တွေကို တည်ဆောက်ရ၊ ပြန်သုံးရ၊ နားလည်ရ ပိုလွယ်ပါတယ်။

Next.js ဆိုတာ React framework ပါ။ React က component တွေပေးပြီး Next.js က application ရဲ့ ကျန်တဲ့အပိုင်းတွေ ထပ်ပေးပါတယ် — file-based routing၊ server rendering နဲ့ static generation၊ server ပေါ်မှာ data fetching၊ API endpoint (Route Handlers)၊ image နဲ့ font optimisation နဲ့ production build setup။ ကိုယ်က React component တွေရေးပြီး Next.js က ဘယ်လို၊ ဘယ်မှာ render လုပ်မလဲ ဆုံးဖြတ်ပေးပါတယ်။

JSX ဆိုတာ JavaScript ထဲမှာ HTML နဲ့ဆင်တဲ့ markup ကို ရေးခွင့်ပေးတဲ့ syntax extension ပါ။ React element တွေ ဖန်တီးတဲ့ function call တွေအဖြစ် compile ဖြစ်သွားပါတယ်။ JavaScript expression မှန်သမျှကို curly brace ထဲ ထည့်လို့ရပြီး attribute တွေမှာ className၊ onClick လို camelCase နာမည်တွေ သုံးပါတယ်။

Rule တချို့က အစပိုင်းသူတွေကို မကြာခဏ ချော်လဲစေပါတယ်။

Component ဆိုတာ JSX ပြန်ပေးတဲ့ JavaScript function အဖြစ်ရေးထားတဲ့ ပြန်သုံးလို့ရတဲ့ UI အစိတ်အပိုင်းပါ။ React က HTML tag တွေနဲ့ ခွဲခြားနိုင်အောင် နာမည်ကို စာလုံးအကြီးနဲ့ စရပါမယ်။ Component တွေကို တစ်ခုထဲမှာ တစ်ခု nest လုပ်ပြီး အာရုံစိုက်ထားတဲ့ အစိတ်အပိုင်းသေးသေးလေးတွေကနေ page တစ်ခုလုံး တည်ဆောက်လို့ရပါတယ်။

Props ဆိုတာ parent က child component ကို ပေးတဲ့ input တွေပါ — function ရဲ့ argument တွေလိုပါပဲ။ Read-only ဖြစ်တာမို့ component က ကိုယ့် props ကို ဘယ်တော့မှ မပြောင်းသင့်ပါဘူး။ String၊ number၊ object၊ function နဲ့ တခြား JSX တောင် prop အဖြစ် ပေးလို့ရပါတယ်။

children ဆိုတာ component ရဲ့ အဖွင့်နဲ့ အပိတ် tag ကြားမှာ ထည့်ထားတာ မှန်သမျှကို ကိုင်ထားတဲ့ special prop ပါ။ Card၊ layout၊ modal လို အထဲမှာ ဘာပါလဲ သိဖို့မလိုတဲ့ wrapper component တွေကို တည်ဆောက်ခွင့်ပေးပါတယ်။

State ဆိုတာ component က render တစ်ခုနဲ့တစ်ခုကြား မှတ်ထားပြီး အချိန်နဲ့အမျှ ပြောင်းလဲနိုင်တဲ့ data ပါ — form input၊ menu ပွင့်နေလား၊ counter လိုမျိုး။ State ပြောင်းတဲ့အခါ React က value အသစ်ကို ပြဖို့ component ကို re-render လုပ်ပါတယ်။ State က ပိုင်ဆိုင်တဲ့ component အတွက်ပဲ private ဖြစ်ပါတယ်။

useState က အတွဲတစ်ခု ပြန်ပေးပါတယ် — လက်ရှိ value နဲ့ update လုပ်ဖို့ function။ Setter ကို ခေါ်လိုက်ရင် value အသစ်နဲ့ re-render တစ်ခု schedule ဖြစ်ပါတယ်။ နောက် value က အရင် value ပေါ်မူတည်ရင် setter ထဲကို function ပေးပါ၊ ဒါဆို နောက်ဆုံး state နဲ့ အမြဲ အလုပ်လုပ်ပါတယ်။

Props က parent ဆီကလာပြီး လက်ခံတဲ့ component က ပြောင်းလို့မရပါဘူး။ State ကတော့ component ကိုယ်တိုင် ပိုင်ဆိုင်ပြီး update လုပ်ပါတယ်။ အဖြစ်များတဲ့ pattern က parent က တစ်ခုခုကို state ထဲမှာ ထားပြီး child တွေကို props အဖြစ် ပေးတာပါ။

React က setter function ကို ခေါ်မှပဲ re-render လုပ်ရမယ်ဆိုတာ သိပါတယ်။ Object ဒါမှမဟုတ် array ကို နေရာမှာတင် ပြောင်းရင် (user.name = "x" ဒါမှမဟုတ် items.push(x)) React က သတိမထားမိဘဲ screen က update မဖြစ်နိုင်ပါဘူး။ Value အသစ်ကို အမြဲဖန်တီးပါ — setUser({ ...user, name: "x" }) ဒါမှမဟုတ် setItems([...items, x])။

onClick၊ onChange၊ onSubmit လို event prop ကို function ပေးပါ။ Function ကို ခေါ်လိုက်တဲ့ ရလဒ်ကို မဟုတ်ဘဲ function ကိုယ်တိုင်ကို ပေးရပါမယ် — onClick={handleClick()} မဟုတ်ဘဲ onClick={handleClick}။ Argument တွေပေးချင်ရင် arrow function နဲ့ ထုပ်ပါ — onClick={() => remove(id)}။

ပုံမှန် JavaScript ကို သုံးပါ — return မတိုင်ခင် if statement၊ JSX ထဲမှာ ternary operator cond ? <A /> : <B />၊ ဒါမှမဟုတ် တစ်ခုခု render လုပ်ဖို့ ဒါမှမဟုတ် ဘာမှမလုပ်ဖို့ cond && <A />။ && ကို number နဲ့ သုံးရင် သတိထားပါ — count က သုည ဖြစ်ရင် {count && <p>...</p>} က 0 ကို render လုပ်ပါတယ်။

Item တစ်ခုချင်းကို JSX အဖြစ် ပြောင်းဖို့ array ရဲ့ map method ကို သုံးပြီး element တိုင်းကို unique ဖြစ်တဲ့ key prop ပေးပါ၊ များသောအားဖြင့် data ထဲက id ပါ။ List ပြောင်းတဲ့အခါ item ဘယ်ဟာက ဘယ်ဟာလဲ React က ခြေရာခံနိုင်အောင် key တွေက ကူညီပါတယ်။

Key ဆိုတာ list ထဲက item တစ်ခုချင်းအတွက် unique ဖြစ်ပြီး တည်ငြိမ်တဲ့ identifier ပါ။ React က render တွေကြားမှာ item တွေကို တွဲဖို့ key ကို သုံးတာမို့ item တွေ ထည့်တာ၊ ဖယ်တာ၊ ပြန်စီတာ လုပ်တဲ့အခါ item တစ်ခုချင်းအတွက် မှန်ကန်တဲ့ state နဲ့ DOM node ကို ထိန်းထားနိုင်ပါတယ်။ List ပြောင်းလဲနိုင်ရင် array index ကို key အဖြစ် မသုံးပါနဲ့။

Fragment က DOM ထဲကို <div> အပို မထည့်ဘဲ element အများကြီးကို အုပ်စုဖွဲ့ခွင့်ပေးပါတယ်။ <>...</> လို့ရေးပြီး list ထဲမှာ key လိုရင် <Fragment key={id}> လို့ ရေးပါတယ်။ HTML ကို သန့်ရှင်းစေပြီး table နဲ့ flex container လို layout တွေ မပျက်အောင် ကာကွယ်ပေးပါတယ်။

Virtual DOM ဆိုတာ React က memory ထဲမှာ ထိန်းထားတဲ့ UI ရဲ့ ပေါ့ပါးတဲ့ ဖော်ပြချက်ပါ။ State ပြောင်းတဲ့အခါ React က ဖော်ပြချက်အသစ် render လုပ်ပြီး အရင်ဟာနဲ့ နှိုင်းယှဉ်ကာ ကွာခြားချက်တွေကိုပဲ DOM အစစ်မှာ apply လုပ်ပါတယ်။ ဒါကြောင့် update တွေ efficient ဖြစ်ပြီး UI တစ်ခုလုံး အမြဲ re-render ဖြစ်သလို code ရေးလို့ရပါတယ်။

Render လုပ်တယ်ဆိုတာ React က JSX ရဖို့ ကိုယ့် component function ကို ခေါ်တာပါ။ Component က သူ့ state ပြောင်းတဲ့အခါ၊ parent re-render ဖြစ်တဲ့အခါ ဒါမှမဟုတ် သုံးနေတဲ့ context ပြောင်းတဲ့အခါ re-render ဖြစ်ပါတယ်။ Re-render က ပုံမှန်ဖြစ်ပြီး များသောအားဖြင့် စျေးမကြီးပါဘူး၊ ပြီးမှ React က DOM ထဲမှာ တကယ်ပြောင်းသွားတဲ့ အပိုင်းတွေကိုပဲ update လုပ်ပါတယ်။

useEffect က component render ပြီးမှ React ပြင်ပက တစ်ခုခု — browser API၊ timer၊ subscription ဒါမှမဟုတ် React မဟုတ်တဲ့ library — နဲ့ sync ဖြစ်ဖို့ code ကို run ပါတယ်။ Dependency array က ဘယ်အချိန် ထပ် run မလဲ ထိန်းပြီး cleanup function ကို return ပြန်လို့ရပါတယ်။

Effect က သုံးတဲ့ value တွေကို စာရင်းပြုစုထားတာပါ။ Array မပါရင် render တိုင်းပြီးနောက် run တယ်၊ array အလွတ် [] ဆိုရင် ပထမ render ပြီးနောက် တစ်ကြိမ်ပဲ run တယ်၊ value တွေပါရင် အဲ့ထဲက တစ်ခုခု ပြောင်းတိုင်း ထပ် run ပါတယ်။ Effect ဖတ်တဲ့ value ကို ချန်ထားရင် data ဟောင်း bug တွေ ဖြစ်တာမို့ linter တောင်းသမျှ ထည့်ပါ။

Hook တွေကို render တိုင်းမှာ order အတူတူ run အောင် component ဒါမှမဟုတ် custom hook ရဲ့ top level မှာပဲ ခေါ်ရပါမယ် — loop၊ condition ဒါမှမဟုတ် nested function ထဲမှာ ဘယ်တော့မှ မခေါ်ပါနဲ့။ ပြီးတော့ React function component ဒါမှမဟုတ် တခြား hook တွေထဲကပဲ ခေါ်လို့ရပြီး ပုံမှန် function တွေထဲက မခေါ်ရပါဘူး။ eslint-plugin-react-hooks linter က rule နှစ်ခုစလုံးကို စစ်ပေးပါတယ်။

Input ရဲ့ value ကို state ထဲမှာ သိမ်းပြီး value အဖြစ်ပေးကာ onChange မှာ state ကို update လုပ်ပါ။ ဒါဆို React က လက်ရှိ value ကို အမြဲသိနေလို့ validation နဲ့ reset လုပ်တာ လွယ်ပါတယ်။

Data က props ကနေ အောက်ကို စီးဆင်းတာမို့ parent က child ကို callback function ပေးပြီး child က data နဲ့ အဲ့ဒါကို ခေါ်ပါတယ်။ ဥပမာ parent က onSelect={setSelected} ပေးပြီး child က click လုပ်တဲ့အခါ onSelect(item) ကို ခေါ်ပါတယ်။

အသုံးများတဲ့ နည်းလမ်း အများအပြား ရှိပြီး Next.js က အားလုံးကို support လုပ်ပါတယ်။

npx create-next-app@latest (ဒါမှမဟုတ် pnpm၊ yarn၊ bun နဲ့ ညီမျှတာ) ကို run ပြီး TypeScript၊ ESLint၊ Tailwind နဲ့ App Router အတွက် မေးခွန်းတွေ ဖြေပါ။ ပြီးရင် npm run dev က default အနေနဲ့ Turbopack သုံးပြီး localhost:3000 မှာ development server ကို စတင်ပါတယ်။

Route တွေက app folder ထဲမှာ ရှိပါတယ် — folder တစ်ခုချင်းက URL segment ဖြစ်ပြီး အထဲက page.tsx က အဲ့ segment ကို page ဖြစ်စေပါတယ်။ layout.tsx က page တွေကို shared UI နဲ့ ထုပ်ပေးတယ်၊ public/ မှာ root ကနေ serve လုပ်တဲ့ static file တွေ ရှိပြီး config က next.config.ts မှာ ရှိပါတယ်။ Project အများစုက component နဲ့ helper တွေကို components/၊ lib/ လို folder တွေမှာလည်း ထားကြပါတယ်။

app ထဲက folder path က URL ဖြစ်လာပါတယ်။ app/page.tsx က /၊ app/about/page.tsx က /about ဖြစ်ပြီး app/blog/[slug]/page.tsx က /blog/any-post နဲ့ ကိုက်ညီပါတယ်။ page (ဒါမှမဟုတ် route) file ပါတဲ့ folder တွေကိုပဲ public အနေနဲ့ ရောက်လို့ရတာမို့ တခြား file တွေကို သူတို့ဘေးမှာ လုံလုံခြုံခြုံ ထားလို့ရပါတယ်။

page.tsx က route တစ်ခုရဲ့ သီးသန့် content ပါ။ layout.tsx က သူ့ folder နဲ့ အောက်က page အားလုံးကို header ဒါမှမဟုတ် sidebar လို shared UI နဲ့ ထုပ်ပေးပြီး အဲ့ page တွေကြား သွားလာနေစဉ် mount ဖြစ်နေဆဲမို့ state ကို ထိန်းထားပါတယ်။ app/layout.tsx ထဲက root layout က မဖြစ်မနေလိုပြီး <html> နဲ့ <body> tag တွေ ပါရပါမယ်။

ရိုးရိုး <a> အစား next/link က <Link> component ကို သုံးပါ။ Page တစ်ခုလုံး reload မလုပ်ဘဲ client ပေါ်မှာ navigate လုပ်ပေးတယ်၊ shared layout တွေကို နေရာမှာ ထားပေးတယ်၊ navigation က ချက်ချင်းလို ခံစားရအောင် link လုပ်ထားတဲ့ page တွေကို background မှာ prefetch လုပ်ပေးပါတယ်။

Dynamic route က page တစ်ခုတည်းနဲ့ URL အများကြီးကို ကိုက်ညီအောင် app/blog/[slug]/page.tsx လို square bracket ထဲက folder နာမည်ကို သုံးပါတယ်။ ကိုက်ညီတဲ့ value က params prop ထဲ ရောက်လာပါတယ်။ လက်ရှိ Next.js မှာ params က Promise ဖြစ်တာမို့ Server Component ထဲမှာ await လုပ်ရပါတယ်။

public/ ထဲက file တွေကို site root ကနေ ဒီအတိုင်း serve လုပ်ပါတယ် — public/logo.png က /logo.png မှာ ရနိုင်ပါတယ်။ Favicon၊ robots.txt နဲ့ process လုပ်စရာမလိုတဲ့ image ဒါမှမဟုတ် file တွေအတွက် သုံးပါ။ အထဲက အရာအားလုံး public download လုပ်လို့ရတာမို့ secret တွေ မထည့်ပါနဲ့။

next/image က screen တစ်ခုချင်းအတွက် မှန်ကန်တဲ့ size နဲ့၊ WebP ဒါမှမဟုတ် AVIF လို modern format နဲ့ image ကို အလိုအလျောက် serve လုပ်ပေးတယ်၊ default အနေနဲ့ lazy-load လုပ်ပြီး layout shift မဖြစ်အောင် နေရာကြိုယူထားပေးပါတယ်။ width နဲ့ height (ဒါမှမဟုတ် fill) ပေးရပြီး remote image host တွေကို config ထဲမှာ ခွင့်ပြုထားရပါမယ်။

App Router မှာ component တွေက default အနေနဲ့ Server Components ဖြစ်ပါတယ် — server ပေါ်မှာ render လုပ်တယ်၊ data ကို တိုက်ရိုက် fetch လုပ်နိုင်တယ်၊ browser ကို ကိုယ်ပိုင် JavaScript မပို့ပါဘူး။ Client Component က "use client" directive နဲ့ စပြီး browser ထဲမှာလည်း run တာမို့ state၊ effect နဲ့ event handler တွေ သုံးနိုင်ပါတယ်။ Interactivity လိုတဲ့ နေရာမှာပဲ client component တွေကို သုံးပါ။

Component က browser မှာပဲ ရှိတဲ့ အရာတစ်ခုခု လိုတဲ့အခါ file ရဲ့ ထိပ်ဆုံးမှာ "use client" ထည့်ပါ — useState၊ useEffect နဲ့ တခြား hook တွေ၊ onClick လို event handler တွေ ဒါမှမဟုတ် window၊ localStorage လို browser API တွေ။ အဲ့ file က import လုပ်တာမှန်သမျှ client bundle ထဲ ပါသွားတာမို့ client component တွေကို သေးသေးထားပါ။

Component ကို async လုပ်ပြီး data ကို တိုက်ရိုက် await လုပ်ပါ — fetch၊ database ဒါမှမဟုတ် server-side library မှန်သမျှကနေ။ ပထမ render အတွက် useEffect ဒါမှမဟုတ် loading state မလိုပါဘူး၊ API key လို secret တွေကလည်း server ပေါ်မှာပဲ ရှိနေပါတယ်။

Page ဒါမှမဟုတ် layout ကနေ metadata object ကို export လုပ်လိုက်ရင် SEO နဲ့ link preview အတွက် page ရဲ့ <title>၊ description၊ Open Graph နဲ့ တခြား <head> tag တွေကို သတ်မှတ်ပေးပါတယ်။ Blog post title လို data ပေါ်မူတည်တဲ့ value တွေအတွက်တော့ async generateMetadata function ကို export လုပ်ပါ။

app/globals.css လို CSS file တစ်ခု ဖန်တီးပြီး root layout မှာ တစ်ကြိမ် import လုပ်ပါ။ Global style တွေက page တိုင်းကို သက်ရောက်တာမို့ component သီးသန့် style တွေအတွက် style တွေ မတိုက်ဆိုင်အောင် CSS Modules ဒါမှမဟုတ် Tailwind ကို သုံးပါ။

CSS Module ဆိုတာ Button.module.css လို နာမည်ပေးထားတဲ့ file ပါ။ Import လုပ်လိုက်တဲ့အခါ class နာမည်တစ်ခုချင်းက unique ဖြစ်ပြီး local scope ပါတဲ့ နာမည်ဖြစ်သွားလို့ component တစ်ခုထဲက .title က တခြား component ထဲက .title နဲ့ မတိုက်ဆိုင်နိုင်ပါဘူး။ Class တွေကို property အဖြစ် သုံးပါတယ် — className={styles.title}။

loading.tsx က route segment ရဲ့ content ကို fetch လုပ်နေစဉ် loading UI ကို ချက်ချင်းပြပေးပါတယ် — Next.js က page ကို Suspense boundary နဲ့ ထုပ်ပေးပါတယ်။ not-found.tsx က route မရှိတဲ့အခါ ဒါမှမဟုတ် page ကနေ notFound() ကို ခေါ်တဲ့အခါ render ဖြစ်ပါတယ်၊ ဥပမာ blog post slug က database ထဲမှာ မရှိတဲ့အခါပါ။

error.tsx က route segment အတွက် error boundary ပါ — အဲ့ segment ကို render လုပ်နေစဉ် တစ်ခုခု throw ဖြစ်ရင် Next.js က app တစ်ခုလုံး crash မဖြစ်စေဘဲ ဒီ file ကို ပြပါတယ်။ Client Component ဖြစ်ရပြီး error နဲ့ user ပြန်ကြိုးစားနိုင်ဖို့ reset function ကို လက်ခံရပါတယ်။

သူတို့ကို .env.local (Git ထဲ commit မလုပ်တဲ့ file) ထဲမှာ ထည့်ပြီး process.env.NAME နဲ့ ဖတ်ပါ။ Default အနေနဲ့ variable တွေက server ပေါ်မှာပဲ ရနိုင်ပါတယ်။ Browser ကို ထုတ်ပြချင်ရင် နာမည်က NEXT_PUBLIC_ နဲ့ စရပါမယ် — ဒါကြောင့် secret တွေကို ဒီ prefix ဘယ်တော့မှ မပေးပါနဲ့။

next dev က fast refresh နဲ့ အသုံးဝင်တဲ့ error overlay တွေပါတဲ့ development server ကို စတင်ပါတယ်။ next build က ဖြစ်နိုင်သမျှ pre-render လုပ်ပြီး optimise လုပ်ထားတဲ့ production build ကို ဖန်တီးပါတယ်။ next start က အဲ့ production build ကို serve လုပ်ပါတယ်။ Performance ကို dev server မှာ မဟုတ်ဘဲ production build မှာ အမြဲ စစ်ပါ။

Fast Refresh ဆိုတာ file ကို save လုပ်တာနဲ့ ဖြစ်နိုင်သမျှ component state ကို ထိန်းထားရင်း page ကို ချက်ချင်း update လုပ်ပေးတဲ့ development feature ပါ။ Component မဟုတ်တဲ့ file ကို ပြင်တာ ဒါမှမဟုတ် syntax error ရှိရင် page အပြည့် reload လုပ်ပြီး error overlay ပြပါတယ်။

React DevTools ဆိုတာ component တစ်ခုချင်းရဲ့ props၊ state နဲ့ hook တွေပါတဲ့ component tree ကို ပြပေးတဲ့ browser extension ပါ။ Behaviour ကို စမ်းဖို့ value တွေကို live ပြင်လို့ရတယ်၊ element တစ်ခုကို ဘယ် component က render လုပ်လဲ ရှာလို့ရပြီး ဘယ် component တွေ re-render ဖြစ်လဲ၊ ဘယ်လောက်ကြာလဲ ကြည့်ဖို့ Profiler tab ကို သုံးလို့ရပါတယ်။

Prop drilling ဆိုတာ အနက်ကြီးထဲက child ဆီ ရောက်ဖို့သက်သက် prop ကို မသုံးတဲ့ ကြားခံ component အများကြီးကို ဖြတ်ပို့တာပါ။ Code ကို ပြောင်းရ ခက်စေပါတယ်။ ဖြေရှင်းနည်းတွေက children နဲ့ ပြန်ဖွဲ့စည်းတာ (composition)၊ state ကို သုံးတဲ့နေရာနဲ့ နီးအောင် ရွှေ့တာ ဒါမှမဟုတ် theme၊ လက်ရှိ user လို တကယ်မျှသုံးရတဲ့ value တွေအတွက် React Context ကို သုံးတာပါ။

Context က level တစ်ခုချင်းကို props ဖြတ်ပို့စရာမလိုဘဲ parent က value တစ်ခုကို သူ့အောက်က component တိုင်း ရနိုင်အောင် လုပ်ပေးပါတယ်။ createContext နဲ့ ဖန်တီး၊ <ThemeContext value={theme}> (ဟောင်းတဲ့ code မှာ .Provider) နဲ့ value ပေးပြီး အောက်က ဘယ်နေရာမဆို use(ThemeContext) ဒါမှမဟုတ် useContext နဲ့ ဖတ်ပါတယ်။ ရှားရှားပါးပါး ပြောင်းတဲ့ value တွေအတွက် အကောင်းဆုံးပါ။

TypeScript က code မ run ခင်မှာ အမှားတွေကို ဖမ်းပေးပါတယ် — props မှားပေးတာ၊ field နာမည် စာလုံးပေါင်းမှားတာ ဒါမှမဟုတ် case တစ်ခု မေ့တာ။ Autocomplete ကောင်းကောင်း ပေးပြီး refactor လုပ်တာကို ပိုလုံခြုံစေပါတယ်။ Next.js က အလိုအလျောက် support လုပ်ပါတယ် — file တွေကို .tsx လို့ နာမည်ပေးလိုက်ရုံနဲ့ config ကို ဖန်တီးပေးပါတယ်။

Props ကို type ဒါမှမဟုတ် interface နဲ့ ဖော်ပြပြီး function ရဲ့ parameter ကို annotate လုပ်ပါ။ Optional props တွေမှာ ? ထည့်ပြီး destructuring ထဲမှာ default value တွေ ပေးလို့ရပါတယ်။

အလွယ်ဆုံးလမ်းက Vercel ပါ — Git repository ကို ချိတ်လိုက်ရင် push တိုင်း build လုပ်ပြီး deploy လုပ်ပေးကာ pull request တိုင်းအတွက် preview URL ပေးပါတယ်။ Next.js ကို next build နဲ့ next start သုံးပြီး Node.js server မှန်သမျှမှာ၊ Docker container ထဲမှာ၊ adapter တွေနဲ့ တခြား platform တွေမှာ ဒါမှမဟုတ် server feature မသုံးရင် static export အပြည့်အဖြစ်လည်း run လို့ရပါတယ်။

Project အစစ်တစ်ခုကို ရွေးပြီး အတိုချုပ် ရှင်းပြပါ — ဘာလုပ်လဲ၊ ဘာကြောင့် တည်ဆောက်ခဲ့လဲ၊ အဓိက component တွေနဲ့ data ဘယ်လိုစီးဆင်းလဲ၊ ကြုံခဲ့တဲ့ ပြဿနာတစ်ခုနဲ့ ဘယ်လိုဖြေရှင်းခဲ့လဲ၊ နောက်ထပ် ဘာကို တိုးတက်အောင် လုပ်မလဲ။ Code ဒါမှမဟုတ် live link ကို အသင့်ထားပါ — ပြီးဆုံးပြီး ကောင်းကောင်းရှင်းပြနိုင်တဲ့ project အသေးလေးက မပြီးသေးတဲ့ project ကြီးထက် သာပါတယ်။

Mid-level interview တွေမှာ feature တွေကို အစအဆုံး ကိုယ်တိုင်တည်ဆောက်နိုင်ဖို့ မျှော်လင့်ပါတယ်။ Hook တွေ တကယ်ဘယ်လို အလုပ်လုပ်လဲ၊ state နဲ့ data fetching ကို ဘယ်လို manage လုပ်လဲ၊ App Router က ဘယ်လို render လုပ်ပြီး cache လုပ်လဲ၊ ဘယ်လို test နဲ့ debug လုပ်လဲ မေးပါလိမ့်မယ်။ API တစ်ခုတည်း မဟုတ်ဘဲ ရွေးချယ်မှုတိုင်းရဲ့ နောက်က trade-off တွေကို ရှင်းပြပါ။

State က render တစ်ခုချင်းအတွက် snapshot ပါ။ setCount(count + 1) ကို ခေါ်လိုက်ရင် re-render တစ်ခု schedule ဖြစ်ပေမဲ့ လက်ရှိ render ထဲက count variable က value ဟောင်းအတိုင်း ရှိနေပါတယ်။ React က event တစ်ခုထဲက update အများကြီးကို render တစ်ခုတည်းအဖြစ် batch လုပ်ပါသေးတယ်။ နောက် value ကို ချက်ချင်းလိုရင် variable ထဲ အရင်တွက်ထားပါ၊ ဒါမှမဟုတ် ဆက်တိုက် update တွေအတွက် updater function ကို သုံးပါ။

React 18 ကစပြီး event၊ timeout၊ promise ဒါမှမဟုတ် native handler တစ်ခုထဲက state update အများကြီးကို re-render တစ်ခုတည်းအဖြစ် အုပ်စုဖွဲ့ပါတယ်။ အလကား render တွေနဲ့ တစ်ဝက်တစ်ပျက် update ဖြစ်နေတဲ့ UI ကို ရှောင်ပေးပါတယ်။ Update ပြီးချင်း DOM ကို ဖတ်ဖို့ မဖြစ်မနေလိုတဲ့ ရှားပါးတဲ့ case မှာ flushSync က React ကို ချက်ချင်း apply လုပ်ခိုင်းပါတယ်။

State မှာ ဆက်စပ်တဲ့ field အများကြီး ရှိတဲ့အခါ၊ နောက် state က အရင် state ပေါ် ရှုပ်ထွေးတဲ့ပုံစံနဲ့ မူတည်တဲ့အခါ ဒါမှမဟုတ် event handler အများကြီးက state တစ်ခုတည်းကို update လုပ်တဲ့အခါ useReducer ကို သုံးပါ။ Reducer က update logic အားလုံးကို pure ဖြစ်ပြီး test လုပ်လို့ရတဲ့ function တစ်ခုထဲ ထည့်ထားပြီး component တွေက ဘာဖြစ်ခဲ့လဲ ဖော်ပြတဲ့ action တွေကိုပဲ dispatch လုပ်ပါတယ်။

Derived state ဆိုတာ props ဒါမှမဟုတ် တခြား state ကနေ တွက်လို့ရတဲ့ အရာမှန်သမျှပါ — filter လုပ်ထားတဲ့ list၊ စုစုပေါင်း၊ နာမည်အပြည့်။ သူ့ကို ကိုယ်ပိုင် state ထဲ သိမ်းရင် copy နှစ်ခုကို များသောအားဖြင့် effect နဲ့ sync ဖြစ်အောင် ထိန်းရလို့ bug တွေနဲ့ render အပိုတွေ ဖြစ်စေပါတယ်။ Render လုပ်ချိန်မှာ တွက်ပြီး တွက်ချက်မှုက တကယ်လေးမှပဲ memoise လုပ်ပါ။

Component ကို အဲ့ prop အပေါ်အခြေခံတဲ့ key ပေးပါ — <Profile key={userId} userId={userId} />။ Key ပြောင်းတဲ့အခါ React က instance ဟောင်းကို unmount လုပ်ပြီး state အသစ်စက်စက်နဲ့ instance အသစ်ကို mount လုပ်ပါတယ်။ Field တစ်ခုချင်းကို reset လုပ်တဲ့ effect ထက် ပိုရိုးရှင်းပြီး ပိုယုံကြည်ရပါတယ်။

React က render ကို screen ပေါ် commit လုပ်ပြီးနောက် effect ကို run ပါတယ်။ Dependency ပြောင်းလို့ ထပ် run မယ့်အခါ မတိုင်ခင် အရင် effect ရဲ့ cleanup ကို အရင် run ပြီး component unmount ဖြစ်တဲ့အခါ နောက်ဆုံး cleanup ကို run ပါတယ်။ Development ရဲ့ Strict Mode မှာ React က cleanup မှန်မှန်ကန်ကန် မလုပ်တဲ့ effect တွေကို ဖော်ထုတ်ဖို့ mount ချိန်မှာ setup၊ cleanup၊ setup ကို တစ်ကြိမ် ထပ် run ပါတယ်။

useEffect က browser paint လုပ်ပြီးမှ run တာမို့ user မြင်ရတာကို ဘယ်တော့မှ မပိတ်ဆို့ပါဘူး။ useLayoutEffect က DOM update ပြီးနောက် paint မလုပ်ခင် run တာမို့ ဘာမှ မလင်းလက်ခင် layout တိုင်းတာပြီး ချိန်ညှိလို့ရပါတယ် — tooltip နေရာချတာလိုမျိုး။ Painting ကို ပိတ်ဆို့တာမို့ DOM ကို မဖြစ်မနေ တိုင်းတာရမှပဲ သုံးပါ။

Input တွေ မြန်မြန်ပြောင်းတဲ့အခါ request ဟောင်းက အသစ်ပြီးမှ resolve ဖြစ်ပြီး data အသစ်ကို ထပ်ရေးသွားနိုင်ပါတယ်။ Cleanup ထဲမှာ AbortController နဲ့ request ဟောင်းတွေကို cancel လုပ်ပါ၊ ဒါမှမဟုတ် flag နဲ့ ရလဒ်တွေကို လျစ်လျူရှုပါ။ ပိုကောင်းတာက ဒါကို ကိုင်တွယ်ပေးတဲ့ data library ဒါမှမဟုတ် Server Components ကို သုံးတာပါ။

Stale closure ဆိုတာ render ဟောင်းတစ်ခုမှာ ဖမ်းယူထားတဲ့ function က အဲ့ render ရဲ့ value တွေကို ဆက်သုံးနေတာပါ — ဥပမာ count ကို အမြဲ 0 လို့ မြင်နေတဲ့ interval callback။ Value ကို effect ရဲ့ dependency ထဲ ထည့်တာ၊ functional updater (setCount(c => c + 1)) သုံးတာ ဒါမှမဟုတ် နောက်ဆုံး value ကို ref ကနေ ဖတ်တာနဲ့ ပြင်ပါ။

useRef က ref prop နဲ့ DOM node ကို ချိတ်လို့ရတဲ့ current property ပါ object တစ်ခု ပြန်ပေးပါတယ်။ React 19 မှာ function component တွေက ref ကို ပုံမှန် prop အဖြစ် လက်ခံရတာမို့ အထဲက element ဆီ ရိုးရိုးလေး forward လုပ်လို့ရပါတယ် — forwardRef မလိုတော့ပါဘူး။

Component က DOM node အကြမ်းအစား ref ကနေတစ်ဆင့် custom API သေးသေးလေး ထုတ်ပြခွင့်ပေးပါတယ် — ဥပမာ dialog component ပေါ်က open() နဲ့ close() method တွေ။ ချင့်ချင့်ချိန်ချိန် သုံးပါ — များသောအားဖြင့် method တွေကို imperative ခေါ်တာထက် props ပေးတာက ပိုရှင်းပါတယ်။

နာမည်က use နဲ့ စတဲ့ function တစ်ခုရေးပြီး အထဲမှာ တခြား hook တွေကို ခေါ်ပါ။ Component လိုတာမှန်သမျှကို return ပြန်ပါတယ်။ ခေါ်တဲ့ component တိုင်းက ကိုယ်ပိုင် state ရတာမို့ custom hook က data ကို မဟုတ်ဘဲ logic ကို မျှဝေပါတယ်။

React ပြင်ပမှာ ရှိတဲ့ store — navigator.onLine ဒါမှမဟုတ် matchMedia လို browser API တွေ၊ ဒါမှမဟုတ် third-party state library — ကို component က လုံလုံခြုံခြုံ subscribe လုပ်တဲ့ နည်းလမ်းပါ။ Subscribe function၊ snapshot getter နဲ့ SSR အတွက် server snapshot ကို ပေးလိုက်ရင် React က concurrent rendering လုပ်နေစဉ်မှာတောင် component တိုင်းကို တသမတ်တည်း ထိန်းထားပေးပါတယ်။

useId က server နဲ့ client မှာ အတူတူဖြစ်တဲ့ unique ပြီး တည်ငြိမ်တဲ့ id ကို ထုတ်ပေးတာမို့ SSR နဲ့ hydration မှာ လုံခြုံပါတယ်။ Label နဲ့ input တွေ ဒါမှမဟုတ် aria-describedby လို ARIA attribute တွေကို ချိတ်ဖို့ သုံးပါ။ List key အတွက်တော့ မသုံးပါနဲ့။

Context ကို ဖတ်တဲ့ component တိုင်းက provider ရဲ့ value က reference အရ ပြောင်းတိုင်း re-render ဖြစ်ပါတယ်။ Value က render တိုင်း object အသစ်ဖြစ်နေရင် consumer အားလုံး အမြဲ re-render ဖြစ်ပါတယ်။ Value ကို memoise လုပ်ပါ၊ ရှားရှားပါးပါးပြောင်းတဲ့ data နဲ့ မကြာခဏပြောင်းတဲ့ data ကို context သီးခြားခွဲပါ၊ မြန်မြန်ပြောင်းတဲ့ state ကို local ဒါမှမဟုတ် selector ပါတဲ့ store ထဲမှာ ထားပါ။

Composition ဆိုတာ ပုံစံကွဲတိုင်းအတွက် boolean prop ထပ်ထည့်မယ့်အစား children ဒါမှမဟုတ် header၊ footer လို နာမည်ပေးထားတဲ့ slot prop တွေကနေ တခြား component တွေကို ထည့်ပေးပြီး component တည်ဆောက်တာပါ။ Component တွေကို flexible ဖြစ်ပြီး သေးငယ်စေကာ prop drilling အတွက်လည်း ရိုးရှင်းတဲ့ ဖြေရှင်းနည်းပါ။

Compound components ဆိုတာ အတူတကွ အလုပ်လုပ်ပြီး state ကို များသောအားဖြင့် context ကနေတစ်ဆင့် သွယ်ဝိုက်မျှသုံးတဲ့ component အစုပါ — <Tabs>၊ <Tabs.List>၊ <Tabs.Trigger>၊ <Tabs.Panel> လိုမျိုး။ Parent က state ကို manage လုပ်ပြီး အစိတ်အပိုင်းတွေက ဖတ်တာမို့ သုံးသူတွေကို markup အပေါ် ထိန်းချုပ်မှုအပြည့်ပါတဲ့ သန့်ရှင်းတဲ့ declarative API ပေးပါတယ်။

Controlled input တွေက keystroke တိုင်းမှာ value ကို React ကို ပေးတာမို့ live validation၊ formatting နဲ့ မှီခိုတဲ့ field တွေအတွက် ကောင်းပါတယ်။ Uncontrolled input တွေက value ကို DOM ထဲမှာ ထားပြီး submit လုပ်ချိန်မှာ FormData နဲ့ ဖတ်တာမို့ code နည်းပြီး render နည်းပါတယ်။ React 19 form Actions နဲ့ဆိုရင် uncontrolled နည်းပေါင်း server validation က form အများစုကို ကောင်းကောင်း ဖြေရှင်းပေးပါတယ်။

Form ရဲ့ action prop ကို async function ပေးလို့ရပါတယ်။ React က FormData နဲ့ ခေါ်ပြီး pending state ကို ခြေရာခံကာ အောင်မြင်တဲ့အခါ form ကို reset လုပ်ပါတယ်။ useActionState က အဲ့ action ကို ထုပ်ပြီး validation error လို နောက်ဆုံးရလဒ်နဲ့ isPending flag ကိုပါ ထိန်းထားပေးပါတယ်။

useFormStatus က <form> ထဲက component ကို အဲ့ form submit လုပ်နေလား နဲ့ submit လုပ်လိုက်တဲ့ data ကို ဖတ်ခွင့်ပေးပါတယ်။ Parent က pending prop ကို ချပေးစရာမလိုဘဲ ကိုယ့်ဘာသာ disable ဖြစ်ပြီး spinner ပြတဲ့ ပြန်သုံးလို့ရတဲ့ submit button အတွက် အကောင်းဆုံးပါ။

use က render လုပ်နေစဉ် promise ဒါမှမဟုတ် context ရဲ့ value ကို ဖတ်ပါတယ်။ Promise အတွက်ဆို resolve မဖြစ်မချင်း component က suspend ဖြစ်ပြီး အနီးဆုံး Suspense boundary က fallback ပြပါတယ်။ တခြား hook တွေနဲ့မတူဘဲ use ကို condition နဲ့ loop တွေထဲမှာ ခေါ်လို့ရပါတယ်။ အဖြစ်များတဲ့ pattern က Server Component ထဲမှာ fetch ကို စပြီး promise ကို use လုပ်မယ့် Client Component ဆီ ပေးတာပါ။

React.lazy(() => import("./Chart")) က component ကို ပထမ render မှာ load ဖြစ်တဲ့ ကိုယ်ပိုင် chunk အဖြစ် ခွဲပါတယ်။ Load လုပ်နေစဉ် component က suspend ဖြစ်ပြီး အနီးဆုံး <Suspense fallback={...}> က fallback ကို ပြပါတယ်။ Next.js မှာ Client Components အတွက် ssr: false လို option တွေနဲ့ အတူတူလုပ်ဖို့ next/dynamic ကို သုံးလို့ရပါတယ်။

Error boundary တွေက သူ့အောက်က component တွေ render လုပ်နေစဉ်၊ lifecycle method တွေနဲ့ constructor တွေထဲမှာ throw ဖြစ်တဲ့ error တွေကို ဖမ်းပါတယ်။ Event handler တွေ၊ setTimeout ဒါမှမဟုတ် promise လို asynchronous code၊ SSR ကာလ ဒါမှမဟုတ် boundary ကိုယ်တိုင်ထဲက error တွေကိုတော့ မဖမ်းပါဘူး။ ဒါတွေကို try/catch နဲ့ ကိုင်တွယ်ပြီး monitoring ကို report လုပ်ပါ။

createPortal(children, domNode) က children တွေကို context နဲ့ event အတွက် React tree တစ်ခုတည်းထဲမှာ ထားရင်း DOM node တစ်ခုခု — များသောအားဖြင့် body ရဲ့ အဆုံး — ထဲကို render လုပ်ပါတယ်။ overflow: hidden ဒါမှမဟုတ် stacking context ရှိတဲ့ parent တွေကနေ လွတ်ရမယ့် modal၊ tooltip၊ toast နဲ့ dropdown တွေအတွက် သုံးပါတယ်။

React.memo က component ကို ထုပ်ပြီး props တွေက အရင်တစ်ခါနဲ့ shallow-equal ဖြစ်ရင် React ကို re-render ကျော်ခိုင်းပါတယ်။ Props အတူတူနဲ့ မကြာခဏ render ဖြစ်ပြီး render လုပ်ရ စျေးကြီးတဲ့ component တွေအတွက် တန်ပါတယ်။ Render တိုင်း object ဒါမှမဟုတ် function prop အသစ်ပေးနေရင် ဘာမှမလုပ်ပေးနိုင်ပါဘူး — useMemo/useCallback နဲ့ တွဲပါ၊ ဒါမှမဟုတ် ပိုကောင်းတာက React Compiler ကို ကိုင်တွယ်ခိုင်းပါ။

React Compiler ဆိုတာ component တွေနဲ့ value တွေကို အလိုအလျောက် memoise လုပ်ပေးတဲ့ build-time tool ဖြစ်လို့ useMemo၊ useCallback ဒါမှမဟုတ် React.memo ကို လက်နဲ့ရေးဖို့ ရှားရှားပါးပါးပဲ လိုပါတော့တယ်။ ကိုယ့် code က Rules of React (pure render၊ props ဒါမှမဟုတ် state ကို mutate မလုပ်တာ) ကို လိုက်နာဖို့ အားကိုးပါတယ်။ Next.js က next.config ထဲက reactCompiler option နဲ့ support လုပ်ပါတယ်။

React က element တစ်ခုက အရင်တစ်ခါကအတိုင်း "တူ" လား ဆုံးဖြတ်ဖို့ position နဲ့ key ကို သုံးပါတယ်။ Key ပြောင်းလိုက်ရင် instance အသစ်ကို အတင်းဖြစ်စေတာမို့ form ကို reset လုပ်ဖို့ ဒါမှမဟုတ် animation ကို ပြန်စဖို့ သန့်ရှင်းတဲ့ နည်းလမ်းပါ။ Key နဲ့ type အတူတူထားရင် ဘေးက code ပြောင်းလည်း state ကို ထိန်းထားပါတယ်။

Folder တစ်ခုချင်းမှာ ကိုယ်ပိုင် layout.tsx ရှိနိုင်ပြီး layout တွေက nest ဖြစ်ပါတယ် — root layout က section layout ကို ထုပ်ပြီး အဲ့ဒါက page ကို ထုပ်ပါတယ်။ Sibling page တွေကြား navigate လုပ်တဲ့အခါ page ပဲ re-render ဖြစ်ပါတယ် — အပေါ်က shared layout တွေက mount ဖြစ်နေဆဲဖြစ်ပြီး ပွင့်နေတဲ့ sidebar ဒါမှမဟုတ် ဖွင့်ထားတဲ့ video လို state တွေကို ထိန်းထားပါတယ်။

နှစ်ခုစလုံး child route တွေကို ထုပ်ပါတယ်။ Layout က navigation တွေကြားမှာ ဆက်ရှိနေပြီး state ကို ထိန်းထားပါတယ်။ Template ကတော့ navigation တိုင်းမှာ instance အသစ် ဖန်တီးတာမို့ state reset ဖြစ်ပြီး effect တွေ ထပ် run ပါတယ် — enter animation ဒါမှမဟုတ် route တစ်ခုချင်း page view မှတ်တမ်းတင်တာအတွက် အသုံးဝင်ပါတယ်။

app/(marketing)/about/page.tsx လို ကွင်းထဲက folder က URL segment မထည့်ဘဲ route တွေကို စီစဉ်ပေးပါတယ် — page က /about ပဲ ဖြစ်နေဆဲပါ။ Route group တွေက section အမျိုးမျိုးကို layout မတူအောင် (marketing page နဲ့ dashboard) ပေးနိုင်ပြီး app ကို team ပိုင် area တွေအဖြစ် ခွဲနိုင်ပါတယ်။

app/docs/[...slug]/page.tsx က /docs/a၊ /docs/a/b စတာတွေနဲ့ ကိုက်ညီပြီး params.slug ကို array အဖြစ် ပေးပါတယ်။ [[...slug]] က optional ဖြစ်ပြီး slug က undefined ဖြစ်တဲ့ /docs ကိုယ်တိုင်နဲ့လည်း ကိုက်ညီပါတယ်။ Docs site တွေနဲ့ CMS ကနေ ထိန်းတဲ့ page တွေအတွက် အသုံးဝင်ပါတယ်။

Page တွေက params နဲ့ searchParams ကို Promise အဖြစ် လက်ခံရပါတယ်။ Server Component မှာ await လုပ်ပြီး Client Component မှာ React ရဲ့ use နဲ့ ဖွင့်ပါ၊ ဒါမှမဟုတ် URL ကို useParams နဲ့ useSearchParams နဲ့ ဖတ်ပါ။ searchParams ကို ဖတ်တာက page ကို request ပေါ်မူတည်တာမို့ dynamic ဖြစ်စေပါတယ်။

Client Component ထဲမှာ next/navigation က useRouter ကို သုံးပြီး router.push("/path")၊ router.replace()၊ router.back() ဒါမှမဟုတ် router.refresh() ကို ခေါ်ပါ။ Server ပေါ်မှာ — Server Component၊ Server Action ဒါမှမဟုတ် Route Handler ထဲမှာ — next/navigation က redirect("/path") ကို ခေါ်ပါ။

သူတို့က next/navigation က Client Component hook တွေပါ — usePathname က လက်ရှိ path ကို၊ useSearchParams က query string အတွက် read-only URLSearchParams ကို၊ useParams က dynamic route params ကို ပြန်ပေးပါတယ်။ useSearchParams သုံးတဲ့ component ကို page ရဲ့ ကျန်အပိုင်းတွေ pre-render ဆက်ဖြစ်နိုင်အောင် Suspense boundary ထဲမှာ ထားသင့်ပါတယ်။

Production မှာ <Link> က viewport ထဲ ရောက်လာတဲ့အခါ Next.js က navigation ချက်ချင်းနီးပါးဖြစ်အောင် route ကို background မှာ prefetch လုပ်ပါတယ်။ Static route တွေအတွက် page တစ်ခုလုံးကို prefetch လုပ်ပြီး dynamic route တွေအတွက် loading UI ချက်ချင်းပေါ်အောင် အနီးဆုံး loading boundary အထိ prefetch လုပ်ပါတယ်။ ရှားရှားပါးပါးသုံးတဲ့ link တွေအတွက် prefetch={false} နဲ့ ပိတ်လို့ရပါတယ်။

Data fetch လုပ်တဲ့၊ secret သုံးတဲ့ ဒါမှမဟုတ် အများစု static ဖြစ်တဲ့ အရာမှန်သမျှအတွက် JavaScript မပို့တာမို့ Server Components ကို default ထားပါ။ State၊ effect၊ event handler ဒါမှမဟုတ် browser API လိုမှပဲ component ကို client ဆီ ပြောင်းပါ။ Client boundary ကို tree ရဲ့ အောက်ဆုံးအထိ ချပါ — page တစ်ခုလုံး မဟုတ်ဘဲ button ကိုပဲ interactive ဖြစ်အောင်လုပ်ပါ။

Server Component ကို Client Component file ထဲ import လုပ်လို့မရပါဘူး — client code ဖြစ်သွားမှာမို့ပါ။ ဒါပေမဲ့ server parent ကနေ Client Component ကို Server Component ကို children ဒါမှမဟုတ် တခြား prop အဖြစ် ပေးလို့ရပါတယ်။ Server က render လုပ်ထားတဲ့ content ကို modal ဒါမှမဟုတ် tab လို interactive shell ထဲ ထုပ်ဖို့ standard နည်းလမ်းပါ။

Database access၊ secret နဲ့ လေးတဲ့ library တွေကို Server Components၊ Server Actions နဲ့ Route Handlers ထဲမှာ ထားပါ။ Client code က ဘယ်တော့မှ import မလုပ်ရမယ့် module တွေမှာ import "server-only" ထည့်ပါ — import လုပ်မိရင် build fail ဖြစ်ပါတယ်။ NEXT_PUBLIC_ environment variable တွေကပဲ browser ဆီ ရောက်ပါတယ်။

Route Handlers ဆိုတာ HTTP method နာမည်အတိုင်း function တွေ export လုပ်တဲ့ route.ts file ထဲမှာ သတ်မှတ်ထားတဲ့ App Router ရဲ့ API endpoint တွေပါ။ Standard Web Request နဲ့ Response API တွေကို သုံးပါတယ်။ Webhook၊ public API၊ file download နဲ့ React မဟုတ်တဲ့ client တွေ ခေါ်တဲ့ အရာမှန်သမျှအတွက် သုံးပါ။

Server Actions ဆိုတာ "use server" နဲ့ မှတ်ထားပြီး server ပေါ်မှာ run ပေမဲ့ form တွေနဲ့ Client Components ကနေ ခေါ်လို့ရတဲ့ async function တွေပါ။ Next.js က တစ်ခုချင်းကို လုံခြုံတဲ့ POST endpoint အဖြစ် ပြောင်းပေးပါတယ်။ Mutation တွေ — ဖန်တီးတာ၊ update လုပ်တာ၊ ဖျက်တာ — ပြီးနောက် cache လုပ်ထားတဲ့ data ကို revalidate လုပ်တာ ဒါမှမဟုတ် redirect လုပ်တာအတွက် အကောင်းဆုံးပါ။

ကိုယ့် UI ကနေ trigger လုပ်တဲ့ mutation တွေ — form submit နဲ့ button click — အတွက် form၊ pending state နဲ့ revalidation တွေနဲ့ ပေါင်းစပ်ထားတာမို့ Server Actions ကို သုံးပါ။ React UI ပြင်ပက တစ်ခုခုက endpoint ကို ခေါ်တဲ့အခါ Route Handlers ကို သုံးပါ — webhook၊ mobile app၊ third-party integration ဒါမှမဟုတ် file နဲ့ feed လို UI မဟုတ်တဲ့ response တွေ။

မဆိုင်တဲ့ request တွေကို ဘယ်ဟာကိုမှ await မလုပ်ခင် စလိုက်ပြီး Promise.all နဲ့ ပေါင်းပါ၊ ဒါဆို page က အားလုံးရဲ့ ပေါင်းလဒ် မဟုတ်ဘဲ အနှေးဆုံး request ကိုပဲ စောင့်ရပါတယ်။ နောက်မှပေါ်လို့ရတဲ့ page အစိတ်အပိုင်းတွေကို ကိုယ်ပိုင် component တွေအဖြစ် Suspense ထဲ ထည့်ပြီး သီးခြား stream ဝင်လာစေပါ။

loading.tsx file က route segment ကို Suspense boundary နဲ့ ထုပ်ပေးတာမို့ navigate လုပ်တာနဲ့ သူ့ UI ချက်ချင်း ပေါ်လာပါတယ်။ Page ထဲမှာ နှေးတဲ့ component တွေကို <Suspense fallback> နဲ့ ထုပ်ပါ — server က ကျန်တဲ့ HTML ကို ချက်ချင်းပို့ပြီး နှေးတဲ့ အပိုင်းတစ်ခုချင်းကို data အဆင်သင့်ဖြစ်တာနဲ့ stream လုပ်ပေးပါတယ်။

Cache လုပ်ထားတဲ့ data ကို timer နဲ့ ဒါမှမဟုတ် တောင်းဆိုတဲ့အခါ refresh လုပ်လို့ရပါတယ်။ တောင်းဆိုတဲ့အခါအတွက် data ပြောင်းပြီးနောက် Server Action ဒါမှမဟုတ် Route Handler ကနေ revalidatePath("/blog") ဒါမှမဟုတ် revalidateTag("posts", "max") ကို ခေါ်ပါ — revalidateTag က background မှာ refresh လုပ်နေစဉ် version ဟောင်းကို serve လုပ်ပါတယ်။ Server Action ထဲမှာ updateTag က data ကို ချက်ချင်း expire လုပ်တာမို့ user က ကိုယ့်ပြောင်းလဲမှုကို ချက်ချင်း မြင်ရပါတယ်။

Page ကနေ async generateMetadata function ကို export လုပ်ပါ — params အတူတူကို လက်ခံပြီး data fetch လုပ်နိုင်ပါတယ် (page ရဲ့ကိုယ်ပိုင် fetch နဲ့ request တွေကို dedupe လုပ်ပါတယ်)။ Social image တွေအတွက် ImageResponse ပြန်ပေးတဲ့ opengraph-image.tsx file ထည့်လိုက်ရင် Next.js က image နဲ့ meta tag တွေကို ထုတ်ပေးပါတယ်။

next/font က Google ဒါမှမဟုတ် local font တွေကို build time မှာ download လုပ်ပြီး ကိုယ့် domain ကနေ serve လုပ်တာမို့ runtime မှာ third party ဆီ request မရှိပါဘူး။ Layout shift ရှောင်ဖို့ fallback font metric တွေကိုလည်း သတ်မှတ်ပေးပြီး font ကို class name ဒါမှမဟုတ် CSS variable အဖြစ် ထုတ်ပေးပါတယ်။

Image optimiser က ယုံကြည်ရတဲ့ source တွေက image တွေကိုပဲ process လုပ်အောင် next.config.ts ထဲက images.remotePatterns မှာ ခွင့်ပြုထားတဲ့ host တွေကို စာရင်းလုပ်ပါ။ ပြီးရင် URL အပြည့်ကို width နဲ့ height နဲ့ ပေးပါ၊ ဒါမှမဟုတ် positioned container ထဲမှာ အဓိပ္ပာယ်ရှိတဲ့ sizes value နဲ့ fill ကို သုံးပါ။

Vitest ဒါမှမဟုတ် Jest လို test runner ကို React Testing Library နဲ့ တွဲသုံးပါ။ Component ကို render လုပ်၊ user ရှာသလို element တွေကို ရှာပါ (getByRole၊ getByLabelText)၊ @testing-library/user-event နဲ့ interact လုပ်ပြီး မြင်ရတာကို assert လုပ်ပါ။ ကိုယ့် module တွေကို mock လုပ်မယ့်အစား network call တွေကို MSW နဲ့ mock လုပ်ပါ။

Client Components နဲ့ pure logic ကို Vitest ဒါမှမဟုတ် Jest နဲ့ React Testing Library သုံးပြီး unit နဲ့ integration test လုပ်ပါ။ Async Server Components ကို ဒီ tool တွေက ကောင်းကောင်း support မလုပ်သေးတာမို့ page၊ Server Actions နဲ့ routing ကို run နေတဲ့ app ပေါ်မှာ Playwright နဲ့ end-to-end test တွေနဲ့ ဖုံးပါ။ Business logic ကို တိုက်ရိုက်ခေါ်လို့ရတဲ့ plain function တွေထဲမှာ test လုပ်ပါ။

Server က render လုပ်တဲ့ HTML နဲ့ client ရဲ့ ပထမ render မကိုက်တဲ့အခါ hydration fail ဖြစ်ပါတယ် — render လုပ်ချိန်မှာ Date.now()၊ Math.random()၊ window ဒါမှမဟုတ် localStorage သုံးတာ၊ locale ပေါ်မူတည်တဲ့ formatting၊ မှားတဲ့ HTML nesting ဒါမှမဟုတ် browser extension တွေက DOM ကို ပြောင်းတာ။ Error overlay ထဲက diff ကို ဖတ်ပါ၊ ပထမ render ကို နှစ်ဘက်လုံးမှာ တူအောင်လုပ်ပြီး browser-only value တွေကို effect ထဲ ရွှေ့ပါ။

Senior React နဲ့ Next.js interview တွေက နောက်ကွယ်မှာ အရာတွေ ဘယ်လိုအလုပ်လုပ်လဲ နဲ့ traffic အစစ်အတွက် ဘယ်လို design လုပ်မလဲ ဆိုတာကို အာရုံစိုက်ပါတယ် — reconciliation နဲ့ concurrent rendering၊ Server Components model၊ Next.js caching နဲ့ Partial Prerendering၊ performance၊ security နဲ့ codebase ကြီးတွေရဲ့ architecture။ အဖြေကောင်းတွေက mechanism၊ trade-off နဲ့ ဘယ်လို စစ်ဆေးအတည်ပြုမလဲ ဆိုတာကို ရှင်းပြပါတယ်။

React က element tree အသစ်ကို အရင်ဟာနဲ့ linear time ဖြစ်စေတဲ့ heuristic နှစ်ခုနဲ့ နှိုင်းယှဉ်ပါတယ် — type မတူတဲ့ element တွေက subtree အသစ်လုံးလုံး ဖြစ်စေပြီး list ထဲက children တွေကို key နဲ့ တွဲပါတယ်။ Type တူရင် React က DOM node ဒါမှမဟုတ် component instance ကို ထိန်းထားပြီး ပြောင်းသွားတဲ့ props တွေကိုပဲ update လုပ်ပါတယ်။ ပေးဆပ်ရတာက component ရဲ့ type ဒါမှမဟုတ် key ကို ပြောင်းရင် သူ့ state ပျောက်သွားတာပါ။

Fiber ဆိုတာ React 16 ကစပြီး React ရဲ့ internal architecture ပါ။ Component တစ်ခုချင်းကို fiber — အလုပ်ယူနစ်တစ်ခု — နဲ့ ကိုယ်စားပြုတာမို့ rendering ကို အပိုင်းသေးသေးလေးတွေ ခွဲတာ၊ ခဏရပ်တာ၊ ပြန်ဆက်တာ၊ ဦးစားပေးတာ ဒါမှမဟုတ် လွှင့်ပစ်တာ လုပ်နိုင်ပါတယ်။ Transition၊ Suspense နဲ့ selective hydration လို concurrent feature တွေ ဖြစ်နိုင်တာ ဒါကြောင့်ပါ။

Render phase မှာ React က component တွေကိုခေါ်ပြီး ဘာပြောင်းလဲ တွက်ပါတယ်၊ ကြားဖြတ်ခံရတာ၊ ထပ်လုပ်တာ ဒါမှမဟုတ် လွှင့်ပစ်ခံရတာ ဖြစ်နိုင်လို့ ဒီအလုပ်က pure ဖြစ်ရပါမယ်။ Commit phase မှာ React က ပြောင်းလဲမှုတွေကို DOM မှာ apply လုပ်၊ ref တွေ သတ်မှတ်ပြီး layout effect တွေကို synchronous run ကာ browser paint ပြီးမှ passive effect (useEffect) တွေကို run ပါတယ်။

Rendering က ပိတ်ဆို့တဲ့ task တစ်ခုတည်း မဟုတ်တော့ပါဘူး။ React က UI အသစ်ကို background မှာ ပြင်ဆင်နိုင်တယ်၊ typing လို အရေးပေါ် update အတွက် ကြားဖြတ်နိုင်ပြီး အဆင်သင့်ဖြစ်မှပဲ ပြပါတယ်။ startTransition၊ useDeferredValue နဲ့ Suspense နဲ့ update တစ်ခုချင်းအလိုက် opt in လုပ်ရပါတယ်၊ အရေးပေါ် update တွေကတော့ အရင်လိုပဲ synchronous render ဖြစ်ပါတယ်။

State update ကို ကိုယ်ပိုင်တဲ့အခါ useTransition ကို သုံးပါ — နှေးတဲ့ update ကို startTransition ထဲ ထုပ်ပြီး feedback ပြဖို့ isPending ကို သုံးပါ။ Prop ဒါမှမဟုတ် search text လို မြန်မြန်ပြောင်းတဲ့ value ကိုပဲ လက်ခံရပြီး လေးတဲ့ child ကို နောက်ကျနေတဲ့ copy နဲ့ render လုပ်စေချင်တဲ့အခါ useDeferredValue ကို သုံးပါ။ နှစ်ခုစလုံး input တွေကို responsive ဖြစ်စေပြီး INP ကို တိုးတက်စေပါတယ်။

Component က အဆင်သင့်မဖြစ်သေးတဲ့ data ကို ဖတ်တဲ့အခါ — use(promise)၊ lazy component ဒါမှမဟုတ် Suspense ကို support လုပ်တဲ့ library ကနေ — JSX ပြန်မပေးဘဲ suspend ဖြစ်ပါတယ်။ React က အနီးဆုံး Suspense fallback ကို ပြပြီး data resolve ဖြစ်တဲ့အခါ အဲ့ subtree ကို ပြန်ကြိုးစားပါတယ်။ Transition လုပ်နေစဉ် မြင်ရပြီးသား content ကို fallback နဲ့ အစားမထိုးပါဘူး — UI အသစ် အဆင်သင့်ဖြစ်တဲ့အထိ React က UI ဟောင်းကို ထားပါတယ်။

Server ပေါ်မှာ fetch လုပ်တဲ့ data နဲ့ render လုပ်ပါ၊ Client Components ကို serialisable value တွေကိုပဲ props အဖြစ်ပေးပြီး client-side library တွေကို အဲ့ initial data ကနေ hydrate ဖြစ်စေပါ — ဥပမာ dehydrated cache ပါတဲ့ TanStack Query။ Server ပေါ်မှာ request တွေကြား မျှသုံးတဲ့ module-level store ကို ဘယ်တော့မှ မဖန်တီးပါနဲ့ — user တစ်ယောက်ရဲ့ data တခြားသူဆီ မပေါက်ကြားအောင် request တစ်ခုချင်းအလိုက် store တွေ ဖန်တီးပါ။

Server Components တွေက သူတို့ code ကို browser ဆီ မပို့ပါဘူး။ အဲ့အစား server က render လုပ်ပြီးသား tree ရဲ့ serialise လုပ်ထားတဲ့ ဖော်ပြချက် — RSC payload — ကို HTML element တွေ၊ Client Components အတွက် props တွေနဲ့ သူတို့ JavaScript chunk တွေရဲ့ reference တွေနဲ့အတူ stream လုပ်ပါတယ်။ Client မှာ React က ဒီ payload ကို tree ထဲ ပေါင်းထည့်တာမို့ navigation တွေက page အပြည့် reload မလုပ်ဘဲ server-rendered အပိုင်းတွေကို update လုပ်နိုင်ပါတယ်။

"use client" က component တစ်ခုတည်းကို မဟုတ်ဘဲ module graph ထဲမှာ boundary တစ်ခုကို မှတ်တာပါ — အဲ့ file နဲ့ သူ import လုပ်တာမှန်သမျှ client bundle ရဲ့ အစိတ်အပိုင်း ဖြစ်သွားပါတယ်။ Client Components တွေလည်း initial HTML အတွက် server ပေါ်မှာ render လုပ်ပြီးမှ browser ထဲမှာ hydrate ဖြစ်ပါတယ်။ Boundary က import အားလုံးကို ဆွဲယူလာတာမို့ အရွက်ဖြစ်တဲ့ component သေးသေးလေးတွေပေါ်မှာ ထားပါ။

Button တစ်ခုမှ မခေါ်ရင်တောင် Server Action တိုင်းက public HTTP endpoint ပါ။ ဒါကြောင့် action တိုင်းထဲမှာ user ကို authenticate လုပ်၊ သတ်မှတ်ထားတဲ့ operation ကို authorise လုပ်ပြီး input အားလုံးကို validate လုပ်ရပါမယ် — ဥပမာ Zod နဲ့။ Client ကပို့တဲ့ ID ဒါမှမဟုတ် စျေးနှုန်းတွေကို ဘယ်တော့မှ မယုံပါနဲ့၊ sensitive data ပြန်ပေးတာ ရှောင်ပါ၊ closure နဲ့ argument တွေက encrypt လုပ်ထားပေမဲ့ ဇွဲရှိတဲ့ attacker ကနေ လျှို့ဝှက်ထားတာ မဟုတ်ဘူးဆိုတာ မှတ်ထားပါ။

cacheComponents ကို ဖွင့်ထားရင် ဘာမှ သွယ်ဝိုက် cache မလုပ်ပါဘူး — opt in မလုပ်ရင် data fetching က request time မှာ run ပါတယ်။ Function၊ component ဒါမှမဟုတ် page တစ်ခုလုံးကို "use cache" directive နဲ့ မှတ်ပြီး cacheLife (ဥပမာ "hours" ဒါမှမဟုတ် "days") နဲ့ သက်တမ်းသတ်မှတ်ကာ နောက်မှ invalidate လုပ်နိုင်အောင် cacheTag နဲ့ label တပ်ပါတယ်။ ဟောင်းတဲ့ implicit fetch cache နဲ့ယှဉ်ရင် caching ကို ရှင်းလင်းပြီး ခန့်မှန်းရလွယ်စေပါတယ်။

Partial Prerendering က route ရဲ့ static shell ကို edge ကနေ ချက်ချင်း serve လုပ်ပြီး dynamic အပိုင်းတွေကို response တစ်ခုတည်းထဲ stream လုပ်ပေးပါတယ်။ Suspense boundary တွေ ပြင်ပမှာရှိပြီး request data ကို မဖတ်တဲ့ အရာမှန်သမျှကို prerender လုပ်ပါတယ်၊ cookie၊ header ဒါမှမဟုတ် cache မလုပ်ထားတဲ့ data ကို ဖတ်တဲ့ component တွေက သူတို့ boundary ထဲမှာ request တစ်ခုချင်း render ဖြစ်ပါတယ်။ Page တစ်ခုတည်းမှာ static speed ရော dynamic content ပါ ရပြီး Cache Components နဲ့ဆို ဒါက default model ပါ။

တစ်ခုချင်းက cache ကို မတူတဲ့ပုံစံနဲ့ invalidate လုပ်ပါတယ်။

Request time မှာမှ သိရတဲ့ အရာတစ်ခုခု — cookies()၊ headers()၊ searchParams၊ connection() ဒါမှမဟုတ် cache မလုပ်ထားတဲ့ data — ကို မဖတ်ရင် route ကို build time မှာ prerender လုပ်လို့ရပါတယ်။ ဒီ API တွေက async ဖြစ်တာမို့ Next.js က dynamic data ဘယ်မှာ လိုလဲ အတိအကျ သိနိုင်ပါတယ်။ Cache Components နဲ့ဆို page ရဲ့ ကျန်အပိုင်းတွေ static ဆက်ဖြစ်နေအောင် dynamic အပိုင်းတွေက Suspense ထဲမှာ ရှိရပါမယ်။

app/blog/[slug]/page.tsx လို dynamic route ကနေ export လုပ်တဲ့ generateStaticParams က build time မှာ prerender လုပ်ရမယ့် params စာရင်းကို ပြန်ပေးပါတယ်။ စာရင်းထဲမပါတဲ့ params တွေကို တောင်းဆိုတဲ့အခါ render လုပ်ပြီး cache လုပ်လို့ရသေးပါတယ်၊ ဒါမှမဟုတ် dynamicParams = false နဲ့ 404 ပြန်ပေးလို့ရပါတယ်။ ထောင်ချီတဲ့ product ဒါမှမဟုတ် blog page တွေကို static build လုပ်ပုံ ဒါပါပဲ။

Parallel routes က @analytics၊ @team လို @ နဲ့စတဲ့ folder — နာမည်ပေးထားတဲ့ slot — တွေ သုံးပြီး layout တစ်ခုတည်းထဲမှာ page အများကြီးကို တစ်ပြိုင်နက် render လုပ်ပါတယ်။ Layout က slot တစ်ခုချင်းကို prop အဖြစ် လက်ခံရပါတယ်။ Slot တစ်ခုချင်းမှာ ကိုယ်ပိုင် loading နဲ့ error state ရှိနိုင်ပြီး သီးခြား navigate လုပ်နိုင်တာမို့ dashboard နဲ့ split view တွေနဲ့ သင့်တော်ပါတယ်။ Slot ထဲက default.tsx က ကိုက်ညီတာ မရှိတဲ့အခါ ဘာပြမလဲ သတ်မှတ်ပါတယ်။

Intercepting routes က (.)photo/[id] လို folder prefix တွေသုံးပြီး ထွက်မသွားဘဲ လက်ရှိ layout ထဲမှာပဲ route ကို load လုပ်ပါတယ်။ ထင်ရှားတဲ့ case က photo feed ပါ — photo ကို click လုပ်ရင် feed ပေါ်မှာ modal နဲ့ ပွင့်ပေမဲ့ URL ကို share လုပ်တာ ဒါမှမဟုတ် refresh လုပ်တာက photo page အပြည့်ကို ပြပါတယ်။ Parallel @modal slot နဲ့ တွဲလိုက်ရင် share လုပ်လို့ရပြီး back button နဲ့ အဆင်ပြေတဲ့ modal တွေ ရပါတယ်။

proxy.ts (အရင် middleware.ts) က request ကို route နဲ့ မတွဲခင် run ပါတယ်။ Redirect၊ rewrite လုပ်တာ၊ header နဲ့ cookie သတ်မှတ်တာ ဒါမှမဟုတ် response ကို စောစော ပြန်ပေးတာ လုပ်နိုင်လို့ locale detection၊ A/B routing နဲ့ အမြန် auth check တွေအတွက် အသုံးဝင်ပါတယ်။ မြန်ပြီး ပေါ့ပါးနေရပါမယ် — proxy က network boundary သာဖြစ်ပြီး သူ့ဘာသာ security boundary မဟုတ်တာမို့ authorisation အစစ်ကို data နားမှာ လုပ်ပါ။

Session ကို HttpOnly၊ Secure၊ SameSite cookie ထဲမှာ encrypt လုပ်ထားတဲ့ stateless token အဖြစ် ဒါမှမဟုတ် database session ကို ညွှန်တဲ့ id အဖြစ် သိမ်းပါ။ Cache လုပ်ထားတဲ့ verifySession() function ပါတဲ့ data-access layer ဖန်တီးပြီး protected data ကို ထိတဲ့ page၊ Server Action နဲ့ Route Handler တိုင်းမှာ ခေါ်ပါ။ Proxy ကို အမြန် redirect အတွက်ပဲ သုံးပြီး layout တွေက navigation တိုင်းမှာ ပြန်မ run တာမို့ page ကို ကာကွယ်ဖို့ layout တစ်ခုတည်းကို ဘယ်တော့မှ အားမကိုးပါနဲ့။

after() က response ကို user ဆီ ပို့ပြီးမှ run မယ့် အလုပ်တွေကို schedule လုပ်ပါတယ် — logging၊ analytics၊ email ပို့တာ ဒါမှမဟုတ် cache warming။ User က side effect တွေကို မစောင့်ဘဲ page ကို ရပြီး platform က အဲ့ဒါတွေ ပြီးတဲ့အထိ function ကို ဆက် run ထားပေးပါတယ်။

Failure တစ်ခုက page ရဲ့ အဲ့အပိုင်းကိုပဲ ကျဆင်းစေအောင် route segment တစ်ခုချင်းမှာ error.tsx boundary တွေ သုံးပြီး root layout အတွက် global-error.tsx ထားပါ။ မရှိတဲ့ data အတွက် user တွေ 404 အစစ်ရအောင် notFound() ကို သုံးပါ။ Server Actions မှာ validation failure လို မျှော်လင့်ထားတဲ့ error တွေကို value အဖြစ် ပြန်ပေးပြီး မမျှော်လင့်တာတွေအတွက်ပဲ throw လုပ်ကာ အားလုံးကို instrumentation.ts ကနေ monitoring ဆီ report လုပ်ပါ။

Project root က instrumentation.ts က server instance စတင်တဲ့အခါ တစ်ကြိမ် run တဲ့ register function ကို export လုပ်ပါတယ် — OpenTelemetry၊ error tracking ဒါမှမဟုတ် တခြား observability tool တွေ setup လုပ်တဲ့ နေရာပါ။ သူ့ရဲ့ onRequestError hook က server error တွေကို route နဲ့ request လို context နဲ့အတူ report လုပ်ပေးလို့ Sentry ဒါမှမဟုတ် ဆင်တူ service ဆီ ပို့လို့ရပါတယ်။

Route တစ်ခုချင်း ဘာ ship လုပ်လဲ ကြည့်ဖို့ bundle analyser ကို run ပြီး အကြီးဆုံး အကျိုးအမြတ်တွေကို ဖြေရှင်းပါ — component တွေကို server ဆီ ပြန်ရွှေ့တာ၊ "use client" boundary တွေကို အောက်ချတာ၊ လေးတဲ့ client widget တွေကို next/dynamic နဲ့ lazy-load လုပ်တာ၊ library ကြီးတွေကို အစားထိုးတာနဲ့ icon နဲ့ utility library တွေအတွက် optimizePackageImports ကို သုံးတာ။ ပြန်မတိုးလာအောင် CI မှာ route တစ်ခုချင်းအတွက် bundle budget သတ်မှတ်ပါ။

ဘယ် component တွေ render ဖြစ်လဲ၊ ဘာကြောင့်လဲ ကြည့်ဖို့ React DevTools Profiler နဲ့ "highlight updates" နဲ့ အရင်တိုင်းတာပါ။ အဖြစ်များတဲ့ အကြောင်းရင်းတွေက render တိုင်း ပြန်ဖန်တီးတဲ့ context value၊ object ဒါမှမဟုတ် function prop အသစ်တွေ၊ tree ထဲမှာ အမြင့်ကြီးထားတဲ့ state နဲ့ မတည်ငြိမ်တဲ့ key တွေပါ။ State ကို အောက်ချတာ၊ component ဒါမှမဟုတ် context တွေ ခွဲတာ၊ အရေးကြီးတဲ့နေရာမှာ memoise လုပ်တာ — ဒါမှမဟုတ် React Compiler ကို ဖွင့်တာနဲ့ ပြင်ပါ။

Real-user data နဲ့ Performance panel နဲ့ နှေးတဲ့ interaction တွေကို ရှာပြီး input နဲ့ paint ကြားက အလုပ်ကို တိုစေပါ — အရေးမကြီးတဲ့ update တွေကို transition ထဲ ထုပ်ပါ၊ list အရှည်ကြီးတွေကို virtualise လုပ်ပါ၊ keystroke တိုင်းမှာ tree ကြီးတွေ re-render မဖြစ်အောင် ရှောင်ပါ၊ လေးတဲ့ တွက်ချက်မှုကို main thread ကနေ ရွှေ့ပါ၊ client JavaScript နည်းနည်းပဲ ship လုပ်ပြီး hydration cost ကို လျှော့ပါ။ next/script နဲ့ strategy="lazyOnload" နဲ့ load လုပ်တဲ့ third-party script တွေလည်း ကူညီပါတယ်။

LCP element ကို client fetching ကနေ မဟုတ်ဘဲ server HTML ကနေ render ဖြစ်အောင်လုပ်ပါ။ Hero image အတွက် priority (ဒါမှမဟုတ် preload) နဲ့ မှန်ကန်တဲ့ sizes ပါတဲ့ next/image ကို သုံးပါ၊ font တွေကို next/font နဲ့ serve လုပ်ပါ၊ render-blocking CSS ကို သေးသေးထားပြီး HTML က CDN ကနေ မြန်မြန်ရောက်အောင် page ကို prerender ဒါမှမဟုတ် cache လုပ်ပါ။ အချိန်က server၊ loading ဒါမှမဟုတ် rendering ဘယ်ဟာမှာ ကုန်လဲ သိဖို့ LCP breakdown ကို စစ်ပါ။

Hydration က Client Component တိုင်းအတွက် JavaScript ကို download၊ parse၊ run လုပ်ပြီးမှ handler တွေ ချိတ်ရတာမို့ client tree ကြီးတွေက interactivity ကို နှောင့်နှေးစေပါတယ်။ React 18+ က Suspense boundary တွေကို သီးခြား hydrate လုပ်ပြီး user interact လုပ်နေတဲ့ အပိုင်းကို ဦးစားပေးပါတယ် (selective hydration)။ တကယ့်ဖြေရှင်းနည်းက client code နည်းဖို့ပါ — static အပိုင်းတွေအတွက် Server Components၊ interactive အပိုင်းတွေအတွက် client island သေးသေးလေးတွေ။

State ကို ပိုင်ရှင်အလိုက် ခွဲပါ။ Server data က Server Components ဒါမှမဟုတ် client query cache ထဲမှာ၊ URL state (filter၊ pagination၊ tab) က searchParams ထဲမှာ၊ form state က form နဲ့ Actions ထဲမှာ ရှိပြီး တကယ်မျှသုံးရတဲ့ client state — cart၊ editor၊ multi-step wizard — ကိုပဲ Zustand ဒါမှမဟုတ် Redux Toolkit လို store ထဲ ထည့်ကာ server ပေါ်မှာ သုံးရင် request တစ်ခုချင်းအလိုက် ဖန်တီးပါ။ အပိုင်းတစ်ခုချင်းကို ဖြစ်နိုင်သမျှ local ထားပါ။

Server Components က page အများစုအတွက် initial data ကို ဖုံးပေးပါတယ်။ Client query cache ကတော့ interactive အလွန်ဖြစ်တဲ့ data အတွက် နေရာရနေသေးပါတယ် — infinite scrolling၊ polling၊ component အများကြီးကြား optimistic update တွေ၊ offline support နဲ့ background refetching။ အဖြစ်များတဲ့ pattern က loading flash မရှိအောင် server ပေါ်မှာ prefetch လုပ်ပြီး client cache ကို hydrate လုပ်တာပါ။

Accessible ဖြစ်တဲ့ headless primitive (Radix၊ React Aria၊ Base UI) တွေပေါ်မှာ တည်ဆောက်ပြီး design token တွေနဲ့ style လုပ်ပါ။ Prop list အရှည်ကြီးထက် composition နဲ့ compound components ကို ဦးစားပေးပါ၊ ref နဲ့ native attribute တွေကို forward လုပ်ပါ၊ controlled ရော uncontrolled ပါ support လုပ်ပြီး library က Server Components နဲ့ ကောင်းကောင်း အလုပ်လုပ်အောင် interactive အပိုင်းတွေကိုပဲ Client Components အဖြစ် မှတ်ပါ။ Storybook မှာ document လုပ်ပြီး visual နဲ့ accessibility test လုပ်ပါ။

Native element တွေကို အရင်သုံးပြီး combobox၊ tab၊ menu၊ dialog လို widget တွေအတွက် WAI-ARIA Authoring Practices ကို လိုက်နာပါ — မှန်ကန်တဲ့ role၊ aria-* state တွေ၊ arrow key နဲ့ roving focus၊ modal ထဲမှာ focus ပိတ်ထားတာနဲ့ ပိတ်တဲ့အခါ focus ပြန်ပို့တာ။ Headless library တွေက ဒီ pattern တွေကို ကောင်းကောင်း implement လုပ်ထားပါတယ်။ Automated check တွေတင်မဟုတ်ဘဲ keyboard နဲ့ screen reader အစစ်နဲ့ စစ်ပါ။

[locale] segment နဲ့ locale ကို URL (/en/...၊ /my/...) ထဲ ထည့်ပါ၊ proxy.ts ထဲမှာ ကြိုက်တဲ့ locale ကို detect လုပ်ပြီး redirect လုပ်ပါ၊ translation တွေက client bundle ကို မဖောင်းစေအောင် message catalogue တွေကို server ပေါ်မှာ load လုပ်ပါ။ next-intl လို library တွေက formatting နဲ့ plural တွေကို ကိုင်တွယ်ပေးပါတယ်။ <html> မှာ lang သတ်မှတ်ပါ၊ SEO အတွက် hreflang alternate တွေ ထည့်ပြီး date နဲ့ number တွေအတွက် Intl API တွေ သုံးပါ။

Content အစစ်ကို server ပေါ်မှာ render လုပ်ပါ၊ Metadata API နဲ့ unique title နဲ့ description တွေ သတ်မှတ်ပါ၊ canonical URL နဲ့ ဘာသာပြန်တွေအတွက် alternates ထည့်ပြီး sitemap.ts၊ robots.ts နဲ့ Open Graph image တွေကို file convention တွေနဲ့ ထုတ်ပါ။ Page ထဲမှာ JSON-LD structured data ထည့်ပါ၊ Core Web Vitals ကို စိမ်းနေအောင်ထားပြီး အရေးကြီးတဲ့ page တိုင်းကို link အစစ်တွေကနေ ရောက်နိုင်အောင် သေချာလုပ်ပါ။

React က text ကို escape လုပ်တာမို့ အဓိက XSS risk တွေက sanitise မလုပ်ထားတဲ့ HTML နဲ့ dangerouslySetInnerHTML၊ href ထဲက javascript: URL တွေနဲ့ ယုံကြည်ရမယ့် props မဟုတ်တာတွေကို element ပေါ် spread လုပ်တာပါ။ NEXT_PUBLIC_ variable တွေ ဒါမှမဟုတ် Client Components ကို ပေးတဲ့ props တွေကနေ secret ပေါက်ကြားတာနဲ့ authorisation မပါတဲ့ Server Actions တွေကိုလည်း သတိထားပါ။ Sensitive object တွေ client ဆီ မတော်တဆ မရောက်အောင် taint API တွေ သုံးပါ။

proxy.ts ထဲမှာ request တစ်ခုချင်းအတွက် nonce အသစ်ထုတ်ပြီး script-src 'nonce-…' 'strict-dynamic' ပါတဲ့ Content-Security-Policy header ကို သတ်မှတ်ကာ nonce ကို request header တွေမှာ ထည့်ပေးပါ။ Next.js က ကိုယ်ပိုင် script တွေမှာ အလိုအလျောက် apply လုပ်ပေးပြီး third-party Script tag တွေအတွက် headers() နဲ့ ဖတ်ရပါတယ်။ Nonce တွေက dynamic rendering လိုတာမို့ static အပြည့် page တွေအတွက် hash တွေ ဒါမှမဟုတ် ပိုလျော့တဲ့ policy ကို သုံးပါ။

Business logic ကို plain function တွေ ဒါမှမဟုတ် data-access layer ထဲမှာ ထားပြီး တိုက်ရိုက် unit test လုပ်ပါ။ Server Actions ကို သူတို့ dependency (auth၊ database) တွေကို mock လုပ်ရင် test ထဲမှာ ပုံမှန် async function တွေလို ခေါ်လို့ရပါတယ်။ Async Server Components နဲ့ flow အပြည့် — routing၊ streaming၊ caching — အတွက် production build ပေါ်မှာ Playwright end-to-end test တွေကို အားကိုးပါ။

Playwright ကို dev server ပေါ်မှာ မဟုတ်ဘဲ next build && next start ပေါ်မှာ run ပါ။ Role နဲ့ label အခြေခံ locator တွေ သုံးပါ၊ auto-waiting assertion တွေကို အားကိုးပါ၊ test database ကို seed လုပ်ပြီး test ဒါမှမဟုတ် worker တစ်ခုချင်းအလိုက် reset လုပ်ကာ ပြင်ပ service တွေကိုပဲ mock လုပ်ပါ။ အရေးကြီးတဲ့ ခရီးစဉ်တွေ — sign-up၊ checkout၊ publishing — ကို ဖုံးပြီး pull request တိုင်းမှာ preview deployment တွေပေါ် run ပါ။

Vercel က configuration မလိုဘဲ feature တိုင်းကို support လုပ်ပါတယ်။ Node ဒါမှမဟုတ် Docker ထဲမှာ next start နဲ့ self-host လုပ်တာကလည်း အားလုံးနီးပါး support လုပ်ပေမဲ့ instance တွေကြား caching (server အများအတွက် custom cache handler)၊ image optimisation resource နဲ့ scaling ကို ကိုယ်တိုင် ပိုင်ရပါတယ်။ Server feature မရှိတဲ့ site တွေအတွက် static export သင့်တော်ပါတယ်။ Traffic pattern၊ compliance၊ cost နဲ့ team ရဲ့ operations skill ပေါ်မူတည်ပြီး ရွေးပါ။

Instance တစ်ခုချင်းမှာ ကိုယ်ပိုင် in-memory cache ရှိတာမို့ ISR နဲ့ "use cache" data အတွက် shared cache handler (ဥပမာ Redis) ကို configure လုပ်ပြီး revalidation က instance အားလုံးဆီ ရောက်အောင်လုပ်ပါ။ Instance တိုင်းမှာ build ID နဲ့ Server Actions အတွက် encryption key ကို တူအောင် သတ်မှတ်ပါ၊ static asset တွေကို CDN ကနေ serve လုပ်ပြီး image optimiser ကို CPU နဲ့ memory လုံလောက်အောင် ပေးပါ။

useReportWebVitals ဒါမှမဟုတ် RUM tool နဲ့ user အစစ်တွေဆီက Core Web Vitals ကို report လုပ်ပါ၊ client နဲ့ server error တွေကို source map နဲ့ release tag တွေနဲ့အတူ Sentry လို tracker ဆီ ပို့ပါ၊ နှေးတဲ့ server render နဲ့ data call တွေကို trace လုပ်ဖို့ instrumentation.ts ကနေ OpenTelemetry ကို သုံးပါ။ Deploy တိုင်းပြီးနောက် error spike၊ vitals regression နဲ့ cache hit-rate ပြောင်းလဲမှုတွေအပေါ် alert ထားပါ။

တဖြည်းဖြည်းပါ — router နှစ်ခုစလုံး app တစ်ခုတည်းမှာ run နိုင်ပါတယ်။ Root layout နဲ့ shared provider တွေကို အရင်ရွှေ့ပြီး ရိုးရှင်းကာ အများစု static ဖြစ်တဲ့ page တွေကနေစကာ route တွေကို တစ်ခုချင်း migrate လုပ်ပါ။ getServerSideProps နဲ့ getStaticProps ကို တိုက်ရိုက် fetch လုပ်တဲ့ Server Components နဲ့၊ API route တွေကို Route Handlers ဒါမှမဟုတ် Server Actions နဲ့၊ next/router ကို next/navigation နဲ့ အစားထိုးပြီး route တစ်ခုရွှေ့တိုင်း test လုပ်ပါ။

Team အများကြီးမှာ အမှားတွေ ထပ်ခါထပ်ခါ ဖြစ်တတ်ပါတယ်။

Waterfall ဆိုတာ parent က data ကို await လုပ်ပြီးမှ data ထပ် await လုပ်တဲ့ child ကို render လုပ်တာ — တစ်ခုပြီးတစ်ခု ဖြစ်တာပါ။ မဆိုင်တဲ့ fetch တွေကို စောစောစပြီး အတူ await လုပ်ပါ၊ fetching ကို လိုတဲ့ component တွေထဲ ရွှေ့ပြီး parallel load ဖြစ်အောင် Suspense နဲ့ ထုပ်ပါ၊ component အများကြီးက data အတူတူကို request တစ်ခုတည်းနဲ့ တောင်းနိုင်အောင် React ရဲ့ cache() ကို သုံးပါ။

cache(fn) က function တစ်ခုကို server request တစ်ခုရဲ့ ကြာချိန်အတွင်း memoise လုပ်ပါတယ်။ Page တစ်ခုတည်းကို render လုပ်နေစဉ် Server Component အများကြီးက getUser(id) ကို ခေါ်ရင် အလုပ်က တစ်ကြိမ်ပဲ run ပါတယ်။ Plain fetch မဟုတ်တဲ့ database ဒါမှမဟုတ် auth call တွေအတွက် အကောင်းဆုံးဖြစ်ပြီး request အတွင်းမှာပဲ scope ရှိတာမို့ data က user တွေကြား ဘယ်တော့မှ မပေါက်ကြားပါဘူး။

Client Component ထဲမှာ မျှော်လင့်ထားတဲ့ ပြောင်းလဲမှုကို ချက်ချင်း apply လုပ်ဖို့ useOptimistic ကို ခေါ်ပြီး Server Action ကို transition ဒါမှမဟုတ် form action ထဲမှာ ခေါ်ပါ။ Action ပြီးတဲ့အခါ React က optimistic state ကို server ပြန်ပေးတဲ့ ဒါမှမဟုတ် revalidate လုပ်ထားတဲ့ data အစစ်နဲ့ အစားထိုးပါတယ်၊ throw ဖြစ်ရင် optimistic ပြောင်းလဲမှု ပျောက်သွားပြီး error ပြပါတယ်။

Serverless function တွေက ကြာကြာရှိတဲ့ connection တွေကို ကောင်းကောင်း မကိုင်နိုင်တာမို့ real-time က များသောအားဖြင့် သီးသန့် service ကနေ သွားပါတယ် — WebSocket server၊ Pusher၊ Ably ဒါမှမဟုတ် Supabase Realtime လို hosted service ဒါမှမဟုတ် ကြာကြာ run တဲ့ server ကနေ Server-Sent Events။ Client component က subscribe လုပ်ပြီး update တွေကို သူ့ state ဒါမှမဟုတ် query cache ထဲ ပေါင်းကာ backoff နဲ့ reconnect လုပ်ပါတယ်။

App အများအပြား — marketing site၊ dashboard နဲ့ admin ဆိုပါစို့ — က design system၊ type နဲ့ utility တွေကို မျှသုံးတဲ့အခါပါ။ Turborepo ဒါမှမဟုတ် Nx လို tool တွေက cache လုပ်ထားပြီး ထိခိုက်တာကိုပဲ build လုပ်ပေးပြီး shared package တွေကို transpilePackages နဲ့ transpile လုပ်လို့ရပါတယ်။ Ownership နဲ့ module boundary တွေကို ရှင်းလင်းအောင်ထားပါ၊ မဟုတ်ရင် shared package တွေက bottleneck ဖြစ်လာပါမယ်။

Major version တွေကို ကျော်မယ့်အစား ခြေလှမ်းသေးသေးလေးတွေနဲ့ မကြာခဏ upgrade လုပ်ပါ။ Upgrade guide ကိုဖတ်ပါ၊ official codemod (npx @next/codemod) တွေ run ပါ၊ deprecation warning တွေကို စောစောပြင်ပါ — middleware ကို proxy လို့ နာမည်ပြောင်းတာ ဒါမှမဟုတ် params ကို async လုပ်တာလို — ပြီး regression တွေ ဖမ်းဖို့ type check နဲ့ end-to-end test တွေကို အားကိုးပါ။ လာမယ့် breaking change တွေကို မြင်ရအောင် canary release တွေကို branch တစ်ခုမှာ စမ်းကြည့်ပါ။

Product shell — image၊ description၊ review အကျဉ်းချုပ် — ကို "use cache" နဲ့ product တစ်ခုချင်းအတွက် tag တွေနဲ့ prerender လုပ်လို့ CDN ကနေ serve ဖြစ်ပါတယ်။ User သီးသန့်အပိုင်းတွေ (user ရဲ့ region အတွက် စျေးနှုန်း၊ stock၊ cart state) ကို Suspense ထဲမှာ stream လုပ်ပါ။ Cart ထဲ ထည့်တာကို Server Action နဲ့ optimistic UI နဲ့လုပ်ပါ၊ inventory ပြောင်းတဲ့အခါ product tag ကို revalidate လုပ်ပြီး LCP နဲ့ INP ကို device အစစ်တွေပေါ်မှာ တိုင်းတာပါ။

Route နဲ့ device အလိုက် real-user Core Web Vitals ကနေ စပါ။ ပြီးရင် route တစ်ခုချင်း client ဆီ ဘာ ship လုပ်လဲ၊ "use client" ဘယ်မှာ ရှိလဲ၊ page တွေ static၊ cache လုပ်ထား ဒါမှမဟုတ် dynamic အပြည့်လား၊ ဘာကြောင့်လဲ၊ server timing နဲ့ data waterfall တွေ၊ image နဲ့ font ကိုင်တွယ်ပုံ၊ third-party script တွေနဲ့ CDN ပေါ်က cache hit rate တွေကို စစ်ပါ။ တိုင်းတာထားတဲ့ အကြီးဆုံး ပြဿနာတွေကို အရင်ပြင်ပြီး ပြန်တိုင်းပါ။

Tech lead အဆင့်မှာ မေးခွန်းတွေက ဆုံးဖြတ်ချက်နဲ့ လူတွေအကြောင်းပါ — team က ဘယ် architecture ကို ကျင့်သုံးသင့်လဲ၊ React နဲ့ Next.js codebase ကြီးတစ်ခုကို ဘယ်လို ကျန်းမာအောင် ထိန်းမလဲ၊ ဘယ်လို လုံလုံခြုံခြုံ ship လုပ်မလဲ၊ engineer တွေကို ဘယ်လို ကြီးထွားစေမလဲ။ Interviewer တွေက စနစ်ကျတဲ့ ကျိုးကြောင်းဆင်ခြင်မှု၊ ရိုးသားတဲ့ trade-off တွေနဲ့ ကိုယ့်ကိုယ်ကိုတင် မဟုတ်ဘဲ team ကို ပိုကောင်းအောင် လုပ်ခဲ့တဲ့ ဥပမာတွေကို လိုချင်ပါတယ်။

လိုအပ်ချက်ကနေ စပါ။ SEO၊ မြန်တဲ့ first load နဲ့ server data လိုတဲ့ content နဲ့ commerce site တွေက Next.js နဲ့ သင့်တော်ပါတယ်။ Login နောက်ကွယ်က SEO မလိုတဲ့ internal dashboard တစ်ခုကတော့ ရိုးရှင်းတဲ့ Vite single-page app ဖြစ်နိုင်ပါတယ်။ Remix/React Router၊ Astro ဒါမှမဟုတ် TanStack Start က တခြားပုံစံတွေနဲ့ ကိုက်ညီပါတယ်။ Hosting၊ team အတွေ့အကြုံ၊ ecosystem နဲ့ lock-in ကို ချိန်ဆပါ၊ အခက်ဆုံး feature ကို prototype လုပ်ပြီး ဆုံးဖြတ်ချက်ကို ADR မှာ မှတ်တမ်းတင်ပါ။

တိုတိုနဲ့ မျှသုံးတဲ့ rule set တစ်ခု ရေးပါ — default က server၊ client က interactivity အတွက်ပဲ ဖြစ်ပြီး အရွက် component တွေမှာ ထားတာ၊ data access က server-only layer တစ်ခုကနေ၊ Server Actions က input တိုင်းကို validate နဲ့ authorise လုပ်တာ၊ အသုံးဝင်ရင် *.client.tsx convention လို ရှင်းလင်းတဲ့ နာမည်ပေးပုံ။ Lint rule တွေ၊ server-only import တွေ၊ codebase ထဲက ဥပမာတွေနဲ့ review checklist တွေနဲ့ ထောက်ခံပါ။

app/ ကို ပါးပါးထားပါ — route၊ layout နဲ့ ချိတ်ဆက်မှုတွေ — ပြီး code အစစ်ကို feature module (features/checkout၊ features/search) တွေထဲ ထည့်ကာ တစ်ခုချင်းမှာ component၊ server action၊ data access နဲ့ test တွေ ပါပါစေ။ Shared UI ကို design-system package ထဲ၊ အားလုံးကို ဖြတ်ကျော်တဲ့ code ကို lib/ ထဲ ထည့်ပါ။ Feature တွေက တစ်ခုနဲ့တစ်ခုရဲ့ internal တွေကို import မလုပ်အောင် lint rule တွေနဲ့ boundary တွေကို အကောင်အထည်ဖော်ပါ။

နည်းလမ်းတစ်ခုတည်းကို document လုပ်ပါ — data ကို ဘယ်မှာ fetch လုပ်လဲ (data-access layer ကနေ Server Components)၊ "use cache" နဲ့ ဘာကို cache လုပ်လဲ၊ standard cacheLife profile တွေ၊ tag နာမည်ပေး convention နဲ့ ဘယ် mutation တွေက updateTag ဒါမှမဟုတ် revalidateTag ကို ခေါ်လဲ။ ရေးထားတဲ့ strategy မရှိရင် developer တစ်ယောက်ချင်း ကိုယ့်နည်းကိုယ် တီထွင်ပြီး page က ဘယ်အချိန် data ဟောင်း ပြမလဲ ဘယ်သူမှ ခန့်မှန်းလို့ မရပါဘူး။

Ticket တစ်ခုအဖြစ် မဟုတ်ဘဲ program တစ်ခုအဖြစ် ဆက်ဆံပါ။ Route တွေကို traffic နဲ့ ရှုပ်ထွေးမှုအလိုက် audit လုပ်ပါ၊ shared root layout နဲ့ provider တွေကို အရင်တည်ဆောက်ပြီး router နှစ်ခုစလုံး live ဖြစ်နေစဉ် အပိုင်းလိုက် migrate လုပ်ပါ — risk နည်းတဲ့ static page တွေ၊ ပြီးမှ data များတဲ့ page တွေ။ တိုးတက်မှုကို dashboard မှာ ခြေရာခံပါ၊ team ကို ဥပမာနဲ့ codemod တွေပေးပါ၊ feature delivery ကို ကာကွယ်ပြီး router ဟောင်းကို ဖျက်မယ့် ရက်စွဲ သတ်မှတ်ပါ။

Upgrade guide ကိုဖတ်ပြီး spike branch မှာ အရင်စမ်းပါ၊ ပြီးမှ codemod တွေ run ပြီး deprecation တွေကို ပြင်ပါ။ Shared package တွေနဲ့ pilot app တစ်ခုကို upgrade လုပ်ပြီး production မှာ monitor လုပ်ကာ ကျန်တာတွေအတွက် migration မှတ်စု ရေးပါ။ App တွေ major version အများကြီး ကွာမသွားအောင် monorepo တစ်ခုလုံးမှာ dependency version တွေကို ညီအောင် ထားပါ။

Library တစ်ခုတည်းထက် ဆုံးဖြတ်ချက် tree တစ်ခုကို သဘောတူပါ — server data က server ပေါ်မှာ ဒါမှမဟုတ် query cache ထဲမှာ၊ URL state က URL ထဲမှာ၊ form state က form နဲ့ Actions ထဲမှာ၊ local UI state က component ထဲမှာ ရှိပြီး တကယ်မျှသုံးရတဲ့ client state ကိုပဲ Zustand ဒါမှမဟုတ် Redux Toolkit လို ခွင့်ပြုထားတဲ့ store တစ်ခုထဲ ထည့်ပါ။ Category တစ်ခုချင်းအတွက် ခွင့်ပြုထားတဲ့ option တစ်ခုစီက codebase ကို တသမတ်တည်း ဖြစ်စေပါတယ်။

Checklist တိုလေးက review တွေကို တသမတ်တည်း ဖြစ်စေပါတယ်။

Strict TypeScript၊ React Hooks၊ Next.js နဲ့ jsx-a11y plugin တွေပါတဲ့ ESLint၊ Prettier၊ import-boundary rule တွေနဲ့ React Compiler ရဲ့ lint rule တွေ။ မြန်ဖို့ pre-commit hook တွေထဲမှာ run ပြီး CI မှာ type check၊ test နဲ့ bundle-size limit တွေနဲ့အတူ gate အဖြစ် run ပါ။ Rule တစ်ခုချင်းကို ရှင်းပြပြီး ဖြစ်နိုင်သမျှ auto-fix လုပ်ပါ။

Budget တွေကို user ရလဒ်တွေနဲ့ ချိတ်ပါ — 75th percentile မှာ LCP 2.5 s အောက်နဲ့ INP 200 ms အောက်၊ route တစ်ခုချင်းအတွက် client JavaScript ကန့်သတ်ချက်။ CI မှာ Lighthouse နဲ့ bundle analysis နဲ့၊ production မှာ route နဲ့ device အလိုက် ခွဲထားတဲ့ real-user monitoring နဲ့ တိုင်းတာပါ။ Budget fail ဖြစ်ရင် merge ကို ပိတ်တာ ဒါမှမဟုတ် owner ပါတဲ့ ticket ဖွင့်တာ ဖြစ်ပါစေ။

Owner team ပါတဲ့ product တစ်ခုအဖြစ် လုပ်ပါ — Figma နဲ့ code ကြား မျှသုံးတဲ့ design token တွေ၊ accessible primitive တွေ၊ Storybook ထဲက documentation၊ visual နဲ့ accessibility test တွေ၊ semantic versioning နဲ့ changelog တွေ။ Product team တွေ component ထည့်နိုင်အောင် contribution process ကို run ပါ၊ adoption ကို ခြေရာခံပြီး breaking change တွေအတွက် codemod တွေ publish လုပ်ပါ။

ခက်ပြီး generic ဖြစ်တဲ့ အပိုင်းတွေ — dialog၊ menu၊ combobox လို accessible primitive တွေ — ကို headless library ကနေ ယူပြီး အပေါ်မှာ brand layer ကို တည်ဆောက်ပါ။ အစကနေ အပြည့်တည်ဆောက်တာက ထူးခြားတဲ့ လိုအပ်ချက်ရှိပြီး accessibility နဲ့ browser support ကို နှစ်ပေါင်းများစွာ maintain လုပ်နိုင်တဲ့ capacity ရှိမှပဲ တန်ပါတယ်။ Bundle size၊ Server Component နဲ့ ကိုက်ညီမှု၊ maintenance လှုပ်ရှားမှုနဲ့ licence ကို အကဲဖြတ်ပါ။

Design system ကို default အနေနဲ့ accessible ဖြစ်အောင်လုပ်ပါ၊ accessibility ကို definition of done ထဲ ထည့်ပါ၊ jsx-a11y linting နဲ့ test ထဲမှာ axe check တွေ ထည့်ပြီး quarter တိုင်း အဓိက flow တွေကို keyboard နဲ့ screen reader နဲ့ audit လုပ်ပါ။ Designer နဲ့ engineer တွေကို လေ့ကျင့်ပေးပြီး လူတစ်ယောက်တည်းအပေါ် မမှီခိုအောင် team တစ်ခုချင်းမှာ accessibility champion တစ်ယောက် ခန့်ပါ။

အခြေခံအဖြစ် static check တွေ၊ Testing Library နဲ့ MSW နဲ့ component နဲ့ feature တွေရဲ့ integration test အများကြီး၊ ရှုပ်ထွေးတဲ့ logic အတွက် unit test တွေနဲ့ production build တွေပေါ်မှာ အရေးကြီးတဲ့ ခရီးစဉ်တွေအတွက် Playwright end-to-end test တွေ။ Design system အတွက် visual regression ထည့်ပါ။ Merge မလုပ်ခင် ဘာကို test လုပ်ရမလဲ သဘောတူပြီး လူတွေ ယုံကြည်အောင် suite ကို မြန်ပြီး flake မရှိအောင် ထားပါ။

မပြောင်းတဲ့ package တွေကို ပြန် build ဒါမှမဟုတ် ပြန် test မလုပ်အောင် Turborepo ဒါမှမဟုတ် Nx remote caching ကို သုံးပါ၊ pull request တွေမှာ ထိခိုက်တဲ့ project တွေကိုပဲ run ပါ၊ Playwright ကို machine တွေကြား shard လုပ်ပြီး dependency တွေကို cache လုပ်ပါ။ Pipeline အတွက် target time သတ်မှတ်ပြီး ခြေရာခံပါ၊ retry တွေက ဖုံးကွယ်ထားမယ့်အစား flaky test တွေကို မြန်မြန် quarantine လုပ်ပါ။

Pull request တိုင်း review အတွက် preview deployment ရပါတယ်။ Main ဆီ merge လုပ်တာတွေ အလိုအလျောက် deploy ဖြစ်ပြီး မပြီးသေးတဲ့ အလုပ်က feature flag နောက်ကွယ်မှာ ပုန်းနေကာ risk ရှိတဲ့ ပြောင်းလဲမှုတွေကို error နဲ့ Core Web Vitals ကို စောင့်ကြည့်ရင်း တဖြည်းဖြည်း rollout လုပ်ပါ။ အရင် deployment ဆီ ချက်ချင်း rollback လုပ်နိုင်အောင်ထားပါ၊ build တွေကြား Server Action ID နဲ့ asset တွေ ပြောင်းတာမို့ version ဟောင်း run နေတဲ့ client တွေအတွက် ကြိုစီစဉ်ပါ။

အရင်ဆုံး တည်ငြိမ်အောင်လုပ်ပါ — live debug မလုပ်ဘဲ rollback လုပ်ပါ ဒါမှမဟုတ် flag ကို ပိတ်ပါ — ပြီး status၊ သက်ရောက်မှုနဲ့ နောက် update အချိန်ကို channel တစ်ခုတည်းမှာ ဆက်သွယ်ပါ။ User တွေ လုံခြုံသွားတာနဲ့ trace နဲ့ error report တွေနဲ့ root cause ကိုရှာ၊ test နဲ့ ပြင်ပြီး နောက်ဆက်တွဲ action တွေအတွက် owner နဲ့ ရက်စွဲပါတဲ့ blameless post-mortem ကို run ပါ။

တကယ့်ကုန်ကျစရိတ်တွေနဲ့ ချိတ်ထားတဲ့ မြင်သာတဲ့ debt စာရင်း ထားပါ — နှေးတဲ့ feature တွေ၊ bug တွေ၊ class component ဒါမှမဟုတ် Pages Router code လို pattern ဟောင်းတွေ — ပြီး အပြောင်းအလဲ အများဆုံးဖြစ်တဲ့ code အပိုင်းက debt ကို ဦးစားပေးပါ။ Sprint တိုင်းရဲ့ ပုံမှန်ရာခိုင်နှုန်းကို ချန်ထားပါ၊ အနီးက code ကို ထိတဲ့အခါ ဆပ်ပါ၊ product ကို delivery speed နဲ့ risk အရ ရှင်းပြပါ။

သူဖြေရှင်းတဲ့ ပြဿနာကနေ စပါ။ Feature အစစ်တစ်ခုပေါ်မှာ prototype လုပ်ပါ၊ alternative တွေနဲ့ ကုန်ကျစရိတ်ပါတဲ့ proposal တိုလေး ဒါမှမဟုတ် ADR ရေးပြီး feedback ဖိတ်ပါ။ ကျင့်သုံးဖို့ ဆုံးဖြတ်ရင် codebase ထဲ ဥပမာတစ်ခု၊ ဆီလျော်ရင် lint rule ဒါမှမဟုတ် codemod နဲ့ ရှင်းပြဖို့ session တိုလေး ထည့်ပါ — ပြီး pattern ဟောင်းကို ဘယ်လို အနားပေးမလဲ သဘောတူပါ။

Seed လုပ်ထားတဲ့ data နဲ့ command တစ်ခုတည်းနဲ့ local setup၊ routing၊ data နဲ့ caching model ကို ရှင်းပြတဲ့ architecture overview နဲ့ feature အစစ်တစ်ခုကို အစအဆုံး ထိတဲ့ လမ်းပြထားတဲ့ ပထမ ticket။ Buddy တစ်ယောက်နဲ့ တွဲပေးပါ၊ လိုက်ကူးလို့ရတဲ့ feature ဥပမာကောင်းတွေကို ညွှန်ပြပြီး လုပ်ရင်းနဲ့ onboarding docs ကို တိုးတက်အောင် လုပ်ခိုင်းပါ။

ယူဆချက်နဲ့ မဟုတ်ဘဲ pairing ကနေ တိကျတဲ့ ကွက်လပ်တွေကို ရှာပါ — များသောအားဖြင့် state၊ effect ဒါမှမဟုတ် render cycle။ အာရုံစိုက်တဲ့ exercise တွေနဲ့ task အစစ်အသေးလေးတွေ ပေးပါ၊ သူတို့ code ကို ဘာကြောင့်လဲ ရှင်းပြချက်နဲ့ review လုပ်ပါ၊ official React docs ကို ညွှန်ပြပြီး ပုံမှန် one-to-one တွေမှာ တိုးတက်မှုကို စစ်ပါ။ တိုးတက်မှုတွေကို ဂုဏ်ပြုပြီး scope ကို တဖြည်းဖြည်း တိုးပေးပါ။

Interviewer အားလုံး မျှသုံးတဲ့ rubric ပါ structured format ကို သုံးပါ — component အသေးလေး တည်ဆောက်တာ ဒါမှမဟုတ် ပြင်တာလို လက်တွေ့ exercise၊ အရင် project တစ်ခုအကြောင်း ဆွေးနွေးမှုနဲ့ level နဲ့ ကိုက်တဲ့ design question — senior တွေအတွက် page တစ်ခုရဲ့ data နဲ့ caching ကို ဘယ်လို architect လုပ်မလဲ။ အလွတ်ကျက်ထားတဲ့ API တွေ မဟုတ်ဘဲ ကျိုးကြောင်းဆင်ခြင်မှုနဲ့ communication ကို ရှာပါ၊ candidate တိုင်းကို အခွင့်အရေး တူတူပေးပါ။

Upgrade တွေကို project ကြီး ဘယ်တော့မှ မဖြစ်အောင် ပုံမှန်နဲ့ သေးသေးလေး လုပ်ပါ — sprint ဒါမှမဟုတ် လတိုင်း ပုံမှန်အချိန်၊ အလိုအလျောက် dependency update တွေနဲ့ codemod တွေ။ ခေတ်မီနေတာက security patch တွေ ဆက်ရနေစေပြီး နောက်မှ စျေးကြီးတဲ့ အတင်း migration ကို ကာကွယ်ပေးကြောင်း product ကို ရှင်းပြပါ။ Upgrade ကြီးတွေကို စွမ်းရည်အသစ်တွေကနေ အကျိုးရမယ့် feature တွေနဲ့ တွဲလုပ်ပါ။

User value အလိုက် vertical slice တွေ ခွဲပါ၊ တစ်ခုချင်းကို range နဲ့ estimate လုပ်ပြီး integration နဲ့ design ပြောင်းလဲမှုလို မသိတာတွေအတွက် ရှင်းလင်းတဲ့ buffer တွေ ထည့်ပါ။ အန္တရာယ်အများဆုံး အပိုင်းတွေကို အရင် spike လုပ်ပါ၊ ပါးပါးလေး end-to-end version ကို စောစော deliver လုပ်ပြီး မူလနံပါတ်ကို ခုခံကာကွယ်မယ့်အစား အမှန်တကယ်တိုးတက်မှုအပေါ် အခြေခံပြီး ပုံမှန် ပြန်ခန့်မှန်းပါ။

Feasibility၊ performance နဲ့ accessibility စိုးရိမ်ချက်တွေကို ပြနိုင်အောင် engineer တွေကို စောစော ပါဝင်စေပါ၊ design tool နဲ့ code ကြား token နဲ့ component တစ်စုံတည်းကို မျှသုံးပြီး responsive၊ loading၊ empty နဲ့ error state တွေကို ဘယ်လို သတ်မှတ်မလဲ သဘောတူပါ။ လုပ်နေဆဲ အလုပ်ကို အတူ review လုပ်ပြီး designer တွေက screenshot မဟုတ်ဘဲ အစစ်ကို စစ်နိုင်အောင် preview deployment တွေ သုံးပါ။

API ကို screen တွေ လိုတာအပေါ် အခြေခံပြီး design လုပ်ပါ၊ contract ကို OpenAPI ဒါမှမဟုတ် GraphQL schema အဖြစ် အရင်ရေးပါ၊ အဲ့ဒါကနေ TypeScript type နဲ့ mock တွေ generate လုပ်ပြီး CI မှာ contract test တွေ ထည့်ပါ။ Front end က ပုံစံမတူတာ လိုရင် backend-for-frontend layer ကို စဉ်းစားပါ — Next.js မှာ Route Handlers ဒါမှမဟုတ် server-only data layer က အဲ့ အခန်းကဏ္ဍကို ယူနိုင်ပါတယ်။

ရလဒ်တွေအကြောင်း ပြောပါ — phone တွေဆီ code နည်းနည်းပဲ ပို့တာမို့ page တွေ ပိုမြန်မြန် load ဖြစ်တယ်၊ search engine တွေက content အပြည့်ကို မြင်ရတယ်၊ sensitive logic တွေက server ပေါ်မှာပဲ ရှိနေတယ်။ Pilot ကရတဲ့ နံပါတ်တွေနဲ့ ထောက်ခံပါ — ဥပမာ page တစ်ခုချင်း JavaScript သုံးပုံတစ်ပုံ လျော့သွားပြီး LCP တိုးတက်လာတာ — နဲ့ ကျင့်သုံးဖို့ အချိန်နဲ့ risk ကုန်ကျစရိတ်ကိုပါ ပြောပါ။

ထင်မြင်ချက်ကနေ စံနှုန်းဆီ ရွှေ့ပါ — performance၊ ရိုးရှင်းမှု၊ delivery speed — ဘာကို optimise လုပ်နေတာလဲ။ ဘက်တစ်ဘက်ချင်းကို တင်ပြခွင့်ပေးပါ၊ သက်သေနဲ့ ဖြေရှင်းလို့ရရင် spike တိုလေး run ပါ၊ ပြီးမှ ကျိုးကြောင်းကို ရေးမှတ်ထားပြီး ဆုံးဖြတ်ပါ ဒါမှမဟုတ် ဆုံးဖြတ်ချက်ကို လမ်းပြပါ။ လူတိုင်းကို commit လုပ်ခိုင်းပြီး ဆုံးဖြတ်ချက်ကို ဘယ်အချိန် ပြန်သုံးသပ်မလဲ သဘောတူပါ။

ဖြေရှင်းပြီးသား ပြဿနာတွေအတွက် ရင့်ကျက်တဲ့ ecosystem tool တွေကို သုံးပါ — authentication၊ form၊ data fetching၊ headless UI၊ internationalisation — ကိုယ့် product ကို ထူးခြားစေတာကိုပဲ တည်ဆောက်ပါ။ Dependency တစ်ခုချင်းကို maintenance ကျန်းမာရေး၊ bundle size၊ Server Components နဲ့ ကိုက်ညီမှု၊ licence နဲ့ နောက်မှ အစားထိုးရမယ့် ကုန်ကျစရိတ်နဲ့ အကဲဖြတ်ပါ။

Dependency စာရင်းကို တိုတိုထားပါ၊ Renovate ဒါမှမဟုတ် Dependabot နဲ့ update တွေကို automate လုပ်ပါ၊ CI မှာ package တွေကို audit လုပ်ပြီး lock file နဲ့ version တွေကို pin လုပ်ပါ။ Dependency အသစ်တွေ မထည့်ခင် review လုပ်ပါ၊ supply-chain attack နဲ့ typosquatting ကို သတိထားပြီး security fix တွေ မြန်မြန်ရောက်အောင် Next.js နဲ့ React ကို support လုပ်ဆဲ version တွေမှာ ထားပါ။

Request အများစုကို CDN က serve လုပ်အောင် static နဲ့ cache လုပ်ထားတဲ့ rendering ကို အားကိုးပါ၊ data ကို ရှင်းလင်းတဲ့ tag နဲ့ သက်တမ်းတွေနဲ့ cache လုပ်ပြီး data source တွေကို rate limit နဲ့ request deduplication နဲ့ ကာကွယ်ပါ။ Dynamic route တွေကို load-test လုပ်ပါ၊ cache hit rate နဲ့ server latency ကို စောင့်ကြည့်ပြီး self-host လုပ်ထားတဲ့ setup တွေက instance တွေကြား cache ကို မျှသုံးကြောင်း သေချာလုပ်ပါ။

Product နဲ့ user metric တွေ — Core Web Vitals၊ error rate၊ အဓိက flow တွေရဲ့ conversion — ကို deployment frequency၊ lead time၊ change failure rate နဲ့ ပြန်ကောင်းဖို့ကြာချိန် လို delivery metric တွေနဲ့ တွဲပါ။ CI time နဲ့ survey ရလဒ်လို developer-experience signal တွေ ထည့်ပါ။ Bottleneck ရှာဖို့ သုံးပါ၊ engineer တစ်ဦးချင်းကို အဆင့်သတ်မှတ်ဖို့ ဘယ်တော့မှ မသုံးပါနဲ့။

အချိန်ဘယ်ကို ကုန်လဲ တိုင်းတာပြီး အတားအဆီးတွေကို ဖယ်ရှားပါ — Turbopack နဲ့ မြန်တဲ့ local dev၊ မြန်ပြီး ယုံကြည်ရတဲ့ CI၊ route နဲ့ component အသစ်တွေအတွက် generator တွေ၊ ရှင်းလင်းတဲ့ ဥပမာတွေ၊ ကောင်းတဲ့ error message တွေ၊ type ပါတဲ့ environment variable တွေနဲ့ pull request တိုင်းအတွက် preview deployment တွေ။ တိုးတက်မှု သေးသေးလေးတွေက engineer တိုင်း နေ့တိုင်း အချိန်သက်သာစေပါတယ်။

Team တွေကို product domain တွေနဲ့ ကိုက်အောင်လုပ်ပြီး တစ်ခုချင်းကို ပိုင်ဆိုင်တဲ့ route group နဲ့ feature package တွေ ပေးကာ CODEOWNERS နဲ့ import boundary တွေနဲ့ အကောင်အထည်ဖော်ပါ။ Platform team က design system၊ shared tooling နဲ့ root layout ကို ပိုင်ပါတယ်။ Team တွေက သီးခြား deployment တကယ်လိုရင် micro-frontend ကို မသုံးခင် multi-zone ကို စဉ်းစားပါ။

သီးခြား team အများကြီးက product တစ်ခုရဲ့ အစိတ်အပိုင်းတွေကို schedule မတူဘဲ release လုပ်ရပြီး organisation ဆိုင်ရာ ဝေဒနာက တကယ်ရှိမှပါ။ ကုန်ကျစရိတ်တွေက သိသာပါတယ် — dependency ထပ်နေတာ၊ UX မညီညွတ်တာ၊ shared state နဲ့ routing ရှုပ်ထွေးမှု။ Next.js လောကမှာ multi-zone (domain တစ်ခုအောက်က သီးခြား app တွေ) က များသောအားဖြင့် ပိုရိုးရှင်းတဲ့ အလယ်အလတ် ရွေးချယ်မှုပါ။

စုစုပေါင်းကုန်ကျစရိတ်နဲ့ စွမ်းရည်ကို နှိုင်းယှဉ်ပါ။ Managed platform က operations အလုပ်နည်းနည်းနဲ့ feature တိုင်း၊ preview နဲ့ scaling ကို ပေးပါတယ်။ Self-host က cost၊ region နဲ့ compliance အပေါ် ထိန်းချုပ်မှု ပေးပေမဲ့ instance တွေကြား caching၊ image optimisation၊ scaling နဲ့ monitoring ကို ကိုယ်တိုင် ပိုင်ရပါတယ်။ Traffic၊ budget၊ regulation နဲ့ team မှာ တကယ်ရှိတဲ့ operations skill ပေါ်မူတည်ပြီး ရွေးပါ။

လိုအပ်ချက်တွေကို ကြိုသဘောတူပါ — URL၊ metadata၊ structured data၊ page speed — ပြီး platform ထဲ ထည့်တည်ဆောက်ပါ — အဓိပ္ပာယ်ရှိတဲ့ default တွေပါတဲ့ Metadata API၊ generate လုပ်ထားတဲ့ sitemap နဲ့ Open Graph image တွေ၊ canonical နဲ့ hreflang tag တွေနဲ့ server-rendered content။ Marketing ကို title နဲ့ description တွေအတွက် CMS ပေးပြီး Search Console နဲ့ Core Web Vitals ကို စောင့်ကြည့်ပါ။

URL structure နဲ့ locale detection ကို စောစော ဆုံးဖြတ်ပါ၊ message တွေကို ICU plural ပါတဲ့ translation system ထဲမှာ ထားပြီး server ပေါ်မှာ load လုပ်ကာ date၊ number နဲ့ currency တွေကို locale အလိုက် format လုပ်ပါ။ ပိုရှည်တဲ့ text နဲ့ မတူတဲ့ script တွေအတွက် layout ကို ကြိုစီစဉ်ပါ — မြန်မာစာက line height ပိုမြင့်ဖို့လိုပြီး Arabic က right-to-left လိုပါတယ် — ဘာသာပြန်သူနဲ့ မိခင်ဘာသာစကားပြောသူတွေကို review မှာ ပါဝင်စေပါ။

လိုအပ်တဲ့ data ကိုပဲ စုဆောင်းပြီး document လုပ်ပါ၊ analytics ဒါမှမဟုတ် marketing script တွေ load မလုပ်ခင် consent ကို လေးစားပါ — next/script က condition နဲ့ load လုပ်ခွင့်ပေးပါတယ်။ ကိုယ်ရေးကိုယ်တာ data ကို log၊ client bundle နဲ့ error report တွေထဲ မထည့်ပါနဲ့၊ data-residency rule တွေနဲ့ ကိုက်တဲ့ hosting region တွေကို ရွေးပြီး third-party script တွေကို ပုံမှန် review လုပ်ပါ။

ပြဿနာ၊ goal နဲ့ non-goal တွေကို ဖော်ပြပြီး အဆိုပြု design ကို ရေးပါ — route တွေ၊ component boundary တွေ၊ data flow၊ caching နဲ့ revalidation၊ error state တွေနဲ့ accessibility။ စဉ်းစားခဲ့တဲ့ alternative တွေ၊ risk တွေ၊ rollout plan နဲ့ အောင်မြင်မှုကို ဘယ်လိုတိုင်းမလဲ စာရင်းလုပ်ပါ။ Draft အဖြစ် စောစော မျှဝေပြီး လူတွေ တကယ်ဖတ်လောက်အောင် တိုတိုထားပါ။

လူတွေကို critical area တွေကြား လှည့်ပါ၊ ရှုပ်ထွေးတဲ့ ပြောင်းလဲမှုတွေမှာ pair လုပ်ပါ၊ တစ်ယောက်ထက်ပိုတဲ့ review လိုအပ်ပါစေ၊ runbook နဲ့ architecture docs တွေကို ခေတ်မီအောင် ထားပါ။ App တစ်ခုချင်းကို အနည်းဆုံး နှစ်ယောက်က deploy၊ debug နဲ့ rollback လုပ်နိုင်အောင် သေချာလုပ်ပါ — ပြီး ကိုယ်တိုင်ပဲ တစ်ခုခုကို နားလည်တဲ့ တစ်ဦးတည်းသောသူ ဖြစ်လာတာကို သတိထားပါ။

သီးသန့်နဲ့ စောစော စကားပြောပါ၊ တိကျတဲ့ ဥပမာတွေနဲ့ အကြောင်းရင်းကို စူးစမ်းပါ — မျှော်လင့်ချက် မရှင်းတာ၊ skill၊ workload ဒါမှမဟုတ် ကိုယ်ရေးကိုယ်တာ ပြဿနာ။ ရှင်းလင်းတဲ့ goal နဲ့ pairing ဒါမှမဟုတ် ပိုသေးပြီး ကောင်းကောင်းသတ်မှတ်ထားတဲ့ task လို အကူအညီကို သဘောတူပါ၊ ပုံမှန် check in လုပ်ပြီး တိုးတက်မှုကို မှတ်တမ်းတင်ပါ။ သဘောတူထားတဲ့ အချိန်အတွင်း မတိုးတက်ရင် ကိုယ့် manager ကို ပါဝင်စေပါ။

အာရုံစိုက်တဲ့ပုံစံနဲ့ hands-on ဆက်ဖြစ်နေပါ — pull request review၊ prototype နဲ့ spike တည်ဆောက်တာ၊ critical မဟုတ်တဲ့ ticket တွေယူတာ၊ release note နဲ့ RFC တွေ ဖတ်တာ။ Team ကို မအဆိုပြုခင် feature အသစ်တွေကို side project တွေမှာ စမ်းပါ။ ခေတ်မီနေတာက critical path ပေါ် မရှိဘဲ ယုံကြည်ရတဲ့ ဆုံးဖြတ်ချက်တွေ ချနိုင်စေပါတယ်။

ကိုယ့်ရဲ့ အဓိက output က team ရဲ့ output ဖြစ်တာမို့ လူတွေကို unblock လုပ်ပေးတာ၊ ဦးတည်ချက်ကို ရှင်းလင်းစေတာနဲ့ အလုပ်တွေကို review လုပ်တာကို ဦးစားပေးပါ။ ထက်မြက်နေဖို့ coding လုံလောက်အောင် ဆက်လုပ်ပေမဲ့ ကိုယ့်အချိန်က ကြားဖြတ်ခံရတတ်လို့ critical-path task တွေကို မပိုင်ပါနဲ့။ Design document နဲ့ prototype လို နက်နဲတဲ့ အလုပ်တွေအတွက် focus time ကို ကာကွယ်ပါ။

သင်ယူမှုကို ပုံမှန်အလုပ်ရဲ့ အစိတ်အပိုင်း ဖြစ်စေပါ — lunch-and-learn session တွေ၊ React feature အသစ်တွေအကြောင်း reading group တွေ၊ "ဘာအသစ်တွေရှိလဲ" အကျဉ်းချုပ်ကို အလှည့်ကျ ပိုင်ဆိုင်တာနဲ့ ပြဿနာအစစ်တွေပေါ်မှာ အချိန်ကန့်သတ်ထားတဲ့ spike တွေ။ လူတွေကို internal post တိုလေးတွေ ရေးဖို့ အားပေးပါ၊ experiment တွေ fail ဖြစ်ရင်တောင် ဂုဏ်ပြုပြီး ကိုယ်တိုင် ဘာသင်ယူနေလဲ မျှဝေခြင်းနဲ့ စံပြလုပ်ပါ။

အများအားဖြင့် တဖြည်းဖြည်း refactor လုပ်ပါ။ ပြန်ရေးတာက နှစ်ပေါင်းများစွာရဲ့ bug fix တွေကို လွှင့်ပစ်ပြီး feature အလုပ်ကို ရပ်တန့်စေကာ မကြာခဏ ကျရှုံးပါတယ်။ Platform က တကယ် support မလုပ်တော့တာ ဒါမှမဟုတ် လိုအပ်ချက်တွေနဲ့ မကိုက်နိုင်တော့မှပဲ စဉ်းစားပါ၊ အဲ့ဒီအခါမှာတောင် strangler နည်းလမ်း — domain တစ်ခုတည်းနောက်မှာ stack အသစ်နဲ့ route အသစ်တွေ — ကို သုံးလို့ value က အဆက်မပြတ် ship ဖြစ်ပြီး risk သေးငယ်နေပါတယ်။

STAR structure ကို သုံးပါ — အခြေအနေနဲ့ ကန့်သတ်ချက်တွေ၊ ချိန်ဆခဲ့တဲ့ option တွေ၊ ဆုံးဖြတ်ချက်နဲ့ ဘာကြောင့်လဲ၊ ဖြစ်နိုင်ရင် နံပါတ်တွေနဲ့ ရလဒ်။ ဘာကို ကွဲကွဲပြားပြား လုပ်မလဲ ဆိုတာ ထည့်ပါ။ Interviewer တွေက ပြီးပြည့်စုံတဲ့ ရလဒ်ထက် စနစ်ကျတဲ့ ကျိုးကြောင်းဆင်ခြင်မှု၊ stakeholder တွေနဲ့ ဆက်သွယ်ပြောဆိုမှုနဲ့ သင်ယူမှုကို ရှာပါတယ်။

အရာတွေကို မပြောင်းခင် နားထောင်ပါ — one-to-one တွေလုပ်ပါ၊ code နဲ့ ဆုံးဖြတ်ချက်တွေရဲ့ နောက်က သမိုင်းကြောင်းကို ဖတ်ပြီး လူတွေကို ဘာက စိတ်ပျက်စေလဲ မေးပါ။ Team တောင်းဆိုခဲ့တဲ့ တိုးတက်မှု အသေးလေး အနည်းငယ်ကို deliver လုပ်ပါ၊ ကတိတွေကို တည်ပါ၊ credit ကို ရက်ရက်ရောရော ပေးပြီး ကိုယ့်အမှားတွေကို ပွင့်ပွင့်လင်းလင်း ဝန်ခံပါ။ ယုံကြည်မှုက ကြေညာချက်ကြီးတွေထက် တသမတ်တည်းရှိမှုကနေ လာပါတယ်။

ဦးတည်ချက်က server ပေါ်မှာ အလုပ်ပိုလုပ်ပြီး client ပေါ်မှာ JavaScript နည်းဖို့ပါ — Server Components၊ streaming၊ Partial Prerendering နဲ့ ရှင်းလင်းတဲ့ caching — နဲ့ manual optimisation ကို ဖယ်ရှားပေးတဲ့ compiler တွေ။ Team ကို API ထက် fundamentals ကို တည်ဆောက်ပေးတာ၊ codebase ကို upgrade လုပ်ရလွယ်အောင် ထားတာ၊ feature အသစ်တွေကို risk နည်းတဲ့ area တွေမှာ စမ်းပြီး တကယ့်ပြဿနာတွေကို ဖြေရှင်းမှ ကျင့်သုံးတာနဲ့ ပြင်ဆင်ပေးပါ။

ပထမလ — လူတိုင်းနဲ့ တွေ့ပါ၊ product ကို လေ့လာပါ၊ architecture၊ delivery pipeline နဲ့ ဝေဒနာတွေကို map လုပ်ပါ။ ဒုတိယလ — မြန်ပြီး မြင်သာတဲ့ တိုးတက်မှု အနည်းငယ် deliver လုပ်ပါ — ပိုမြန်တဲ့ CI၊ ပြင်ပြီးသား performance hotspot၊ ပိုရှင်းတဲ့ convention တွေ။ တတိယလ — architecture၊ quality နဲ့ လူတွေရဲ့ ကြီးထွားမှုကို ဖုံးတဲ့ team နဲ့ stakeholder တွေ သဘောတူထားတဲ့ technical vision နဲ့ roadmap ကို စာနဲ့ရေးပြီး မျှဝေပါ။