标签：#React

30 React.js Interview Questions You Should Know Before Your Next Frontend Interview ⚛️ Whether you're preparing for a frontend interview or simply want to brush up on your React.js knowledge , this guide covers 30 real-world, scenario-based React interview questions that interviewers frequently ask. The goal isn't just to memorize definitions. These questions are designed to help you understand how and when to apply React concepts in real-world applications . 📌 Bookmark this article and come back to it during your next interview preparation session. 📚 What We'll Cover In this guide, we'll explore questions around: Conditional rendering API calls and side effects Form validation Performance optimization State management Component re-rendering Keys and lists Dark mode Dynamic components useEffect vs useLayoutEffect Large-list optimization And much more... 1. How do you handle conditional rendering in React? Conditional rendering allows you to render different UI based on application state or conditions. You can use standard JavaScript techniques such as: if...else Ternary operators Logical && Example { isLoggedIn ? < Dashboard /> : < Login />} 💡 Interview Tip For simple conditions, a ternary operator or && is usually sufficient. For more complex conditions, consider moving the logic outside the JSX to keep the component readable. 2. You need to fetch API data when a component mounts. What's the best way to do it? 💡 Key Concept The typical approach is to perform the API request inside a useEffect hook when the component needs to fetch data after rendering. A common pattern is: useEffect (() => { // Fetch API data }, []); The empty dependency array indicates that the effect is intended to run after the initial render. Note: In modern React applications, the best approach can also depend on the framework or data-fetching library you're using. 3. How would you handle form validation in React? A common approach is to use controlled inputs and perform validation during even

The Quest Begins (The "Why") I still remember the first time I tried to add login to a side‑project. I’d read a tutorial that said “just store a token in localStorage and you’re good,” slapped together a few fetch calls, and called it a day. A week later I got an email from a user: “Hey, I can’t log out, and someone else seems to be using my account.” My heart sank. I realized I’d bolted a flashy lock onto a screen door — it looked secure, but anyone with a screwdriver could walk right in. That moment kicked off a deep dive. I wanted to understand the trade‑offs between sessions , JSON Web Tokens (JWT) , and OAuth so I could pick the right tool for each job, not just the shiniest one. What followed felt like assembling a superhero squad: each member has a unique power, and knowing when to call on them makes the difference between saving the day and causing collateral damage. The Revelation (The Insight) Sessions – The Trusty Sidekick Sessions are the classic, server‑side approach. When a user logs in, the server creates a random identifier (the session ID), stores it in a database or cache (Redis, Memcached, etc.), and sends it back to the browser as an HttpOnly cookie. On every request, the browser automatically includes that cookie, the server looks up the ID, and pulls the associated user data. Why I love it: The secret never leaves the server, so stealing a cookie only gives an attacker a session ID that’s useless without the server’s store. Revoking a session is trivial — just delete the row from the store. Works great for traditional web apps where you control both front‑ and back‑end. Where it stumbles: Horizontal scaling requires a shared session store; otherwise each instance forgets who the user is. Every request does a database/lookup, which can add latency if the store isn’t fast enough. JWT – The Lone Wolf with a Signed Badge A JWT is a compact, URL‑safe string that contains claims (like sub , exp , roles ) and is cryptographically signed (HMAC or RSA).

Shadcn, a design engineer at Vercel, has introduced new components for chat interfaces within the shadcn/ui project. This release includes components like MessageScroller and Message, focusing on conversation functionality. The approach emphasizes modular design, allowing developers to adapt elements without affecting underlying logic or styles. Support for headless components is also provided. By Daniel Curtis

A team-lead's breakdown of 8 real React Native project architectures — what each one actually solves, where the "Domain-Driven" and "Micro-Frontend" labels get misused, and how to pick one without over-engineering an MVP. The house-building analogy When you build a house, the labor that lays the bricks gets paid well. The architect who drew the blueprint gets paid more — because the architect already accounted for the second floor you'll add next year, and made sure the foundation could take the load without anyone tearing down a wall later. React Native codebases work the same way. The folder structure you pick on day one either lets your app absorb 10 more features and 40 more engineers, or it collapses under its own weight and someone gets hired specifically to rewrite it. This is also, almost word for word, what a React Native team lead interview is probing for: "Walk me through how you'd structure a project" or "What's your folder structure and why?" Nobody wants your code in that answer — they want to hear you reason about trade-offs. So here are eight real folder structures, what each one actually solves, and two places where the common naming gets sloppy. 1. Flat Structure — for prototypes and MVPs src/ ├── App.js ├── HomeScreen.js ├── ProfileScreen.js ├── Button.js ├── Card.js └── api.js Everything in one src/ folder, no categorization. When to use it: a client demo, a hackathon build, a single-screen proof of concept — anything with a short shelf life, or code you expect a bigger team to re-architect later. Where it breaks: past 10–15 files you're scrolling through an undifferentiated pile with no signal about what belongs together. 2. Feature-Based Structure — the industry default src/ └── features/ ├── auth/ │ ├── components/ │ ├── screens/ │ └── services/ ├── profile/ │ ├── components/ │ ├── screens/ │ └── services/ └── feed/ ├── components/ ├── screens/ └── services/ This is the most common structure in production RN apps. Each product area — auth, pro

App Review rejected my iOS app under Guideline 2.1. The note said reviewers were unable to locate the App Tracking Transparency permission request when they tested the build. The prompt worked on my iPhone. Every single launch. It just didn't work on theirs. The cause turned out to be two properties of the ATT API that are easy to miss individually and genuinely nasty in combination: together they produce a bug that is invisible on a fast device and completely reproducible on a slow one. Your test device is fast. The reviewer's device is not necessarily. This post is the root cause, the fix I shipped, and the list of other things that silently suppress the prompt. The two facts that explain everything 1. iOS only presents the ATT prompt while your app is active Apple's documentation for requestTrackingAuthorization(completionHandler:) states, for iOS 15 and later: "Calls to the API only prompt when the application state is UIApplicationStateActive." That's UIApplication.State.active — not merely "in the foreground," and not "the code is running." During launch there is a window where your JS/UI is already executing but the app is still inactive : splash screen dismissal, the first render, a modal transition animating in or out. Call the API in that window and iOS declines to present. 2. When iOS declines to present, you don't get an error You get notDetermined back ( undetermined in expo-tracking-transparency ) — which is the exact same value you get when the user simply hasn't answered yet. There is no "I couldn't show it" signal. There is no thrown error. There is no presented: false flag. From the return value alone, "the user hasn't decided yet" and "iOS silently no-op'd your request" are indistinguishable. That's the trap. The API looks like it succeeded. The bug I shipped Reduced to its essentials: // Called during startup, while the splash screen was still going away. const { status } = await requestTrackingPermissionsAsync (); const granted = status === ' gr

We just shipped EverShop 2.2.1 — the largest release since 2.0. It folds in the React 19 work that had been sitting in an unpublished 2.1.3 branch and stacks four months of development on top of it: a visual page builder, a blog module, entity custom fields, a multi-language storefront with a translated admin, a rebuilt shipping and fulfillment stack, built-in cloud storage, product recommendations, and a serious security and performance pass. If you're upgrading an existing store, one number to keep in mind: 31 database migrations across 10 modules run automatically on first start. Several of them transform data and drop legacy tables, so back up your database first and read the breaking-changes section below. This release also patches several security vulnerabilities, so upgrading promptly is the right move. Here's a tour of what's new, and what you'll need to change if you maintain themes or extensions. Visual Page Builder The headline feature is a drag-and-drop editor for the storefront, living at /admin/page-builder . You edit any storefront route — plus CMS pages and landing pages — by composing widgets into your theme's areas, with layout-aware drag/drop. The workflow is draft-based: changes accumulate in a per-admin, per-theme draft changeset with per-widget auto-save. When you're ready you can publish immediately, or schedule a rollout for later — and those rollout plans stay editable and cancelable right up until they run. There's inline editing on the canvas (text and images edited in place, with an image picker that understands cloud storage), a layers panel, a "Globals" view for site-wide areas, and per-widget styling controls. Link fields resolve products, categories, CMS pages, and blog posts through a single unified link resolver. Because it's touching public-facing content, the whole editor pipeline went through a dedicated security-hardening pass and ships with an end-to-end test suite. Blog module EverShop now has a first-class blog core module: p

One of the best ways to learn React is by building small, practical projects. A currency converter is an excellent example because it introduces state management, user input handling, calculations, and performance optimization—all in a single application. I built a simple currency converter using React that converts from USD to EUR, GBP, and JPY. For simplicity, I used fixed exchange rates instead of calling a live exchange rate API. React applications are interactive because they can respond to user actions. The useState hook allows components to remember values between renders. For this project, I declared it as thus, const [amount, setAmount] = useState(1); const [currency, setCurrency] = useState("EUR"); The amount stores the value entered. The setAmount() updates it. The currency variable stores the selected currency. The setCurrency() changes the selected currency. Whenever either value changes, React automatically re-renders the component. Now, to calculate the conversion, I stored the exchange rate in an object const RATES = { USD: 1, EUR: 0.92, GBP: 0.79, JPY: 157.3 }; The interface contains: A number input. A dropdown menu. A heading displaying the converted amount. Example: ```return ( Currency Converter <input type="number" value={amount} onChange={(e) => setAmount(Number(e.target.value))} /> <select value={currency} onChange={(e) => setCurrency(e.target.value)} > <option value="EUR">EUR</option> <option value="GBP">GBP</option> <option value="JPY">JPY</option> </select> <h2> {amount} USD = {convertedAmount} {currency} </h2> );```

Astro 7 focuses on build performance, utilizing native tooling and a rewritten compiler in Rust. The new version includes faster Markdown processing and stricter HTML rules. Recent updates introduced advanced routing and incremental builds, while issues around legacy file compatibility and dependency counts were raised in feedback. Astro targets content-driven sites with minimal JavaScript. By Daniel Curtis

Variable-size nodes break dagre's centering, first paint flickers, and straight chains render with kinked edges. Here is the why and the fix for each. Every React Flow and dagre tutorial shows the same thing: uniform gray boxes, laid out in a neat tree, everything centered. You copy the pattern, wire it up, and it works. Then you replace the gray boxes with real cards. A title that wraps to two lines. A card with a description and one without. And the layout starts to look subtly wrong: a parent sits off-center from its children, edges bend where they should be straight, and everything flashes in the top-left corner for a frame before jumping into place. I hit all three building an approval-workflow graph for a fintech app. The nodes were cards with variable content, so none of the fixed-size assumptions held. It took a while to understand that these are three separate bugs with three separate causes. So here is each one, why it happens, and the fix. At the end: the small package where I put all of it, so you do not have to rebuild this. Why dagre centers nodes off-balance (and the bounding-box fix) dagre centers a parent on the barycenter of its children, meaning the average of their center positions. That is correct when every child is the same size. It is visibly wrong when they are not. Concrete numbers from a graph I probed. A parent with two children, one 40px tall and one 200px tall. dagre puts the children at centers y=20 and y=180, so the parent lands at their average, y=100. But the visual middle of that group, the midpoint of the bounding box from the top of the small child to the bottom of the tall one, is y=140. The parent is 40px off from where your eye says it should be, and the taller the imbalance, the worse it gets. The fix is a post-pass on dagre's output: for every parent with two or more children, recompute its cross-axis position as the midpoint of the children's bounding box, walking deepest rank first so children settle before their parents.

TypeScript 6.0 --noPropertyAccessFromIndexSignature : The Flag That Forces Honest API Contracts This article was written with the assistance of AI, under human supervision and review. The Silent Type Hole in Your Codebase Most runtime property access errors stem from index signatures pretending to guarantee properties they don't. Teams define Record<string, T> or { [key: string]: T } for objects where specific properties might not exist, then access those properties with dot notation as if the type system proved their presence. The compiler stays silent. Production crashes follow when the property is undefined. The --noPropertyAccessFromIndexSignature flag eliminates this false confidence. When enabled, TypeScript prohibits dot notation for properties defined only through index signatures. The type system forces bracket notation instead, making the uncertainty explicit at every call site. This distinction is critical—it transforms implicit runtime failures into compile-time enforcement of honest contracts. When developers adopt this flag, the contract becomes explicit. Index signatures signal "this property might not exist" and the syntax enforces that uncertainty. Explicit properties signal "this property is guaranteed" and dot notation confirms the guarantee. The codebase gains honesty. Key Takeaways The --noPropertyAccessFromIndexSignature flag prevents dot notation on properties defined only through index signatures, forcing bracket notation that signals uncertainty. Index signatures ( [key: string]: T ) describe unknown property sets; explicit properties describe guaranteed contracts—the flag enforces this semantic difference. Enabling this flag exposes implicit runtime failures as compile errors, converting production crashes into immediate feedback during development. The migration path involves converting dot access to bracket notation for index-signature properties while keeping dot notation for explicit properties. Combining this flag with --noUncheckedInd

Part 1 was about waiting well. Part 2 was about not waiting at all. This one is about a value I...

If you're testing an iOS build with real devices, you've got two main paths: Apple's TestFlight, or Expo's EAS Preview using Ad-Hoc provisioning. They solve the same problem — getting a build onto a real iPhone without the App Store — but the workflows are genuinely different, not just cosmetically. How each one works TestFlight uses Apple's official infrastructure. You upload your build to App Store Connect (often via npx testflight to speed this up), Apple processes/reviews it, and testers install the TestFlight app and accept an email or public link invite. No UDID collection needed — Apple handles device registration behind the scenes. Expo EAS Preview (Ad-Hoc) uses Ad-Hoc provisioning. You register each tester's device UDID against your Apple Developer account before building — either manually (eas device:create, eas device:list) or by having the tester scan a QR code that installs a temporary profile. Once devices are tied to your provisioning profile, you build with: bash eas build --platform ios --profile preview This generates a direct install link/QR code — no App Store account or TestFlight app required. Comparison table Feature Expo Preview / Ad-Hoc Apple TestFlight Device limit ~100 devices/device class/year (Apple Developer account tier) Up to 10,000 external testers Processing time Immediate after cloud build finishes Apple review/processing (mins to hours) UDID management Manual or profile-based registration required Not required, handled by Apple Best for Fast internal testing, client demos, strict ad-hoc distribution Larger-scale beta testing, staging before production Which one should you use? Fast internal iteration, client demos, small teams → Ad-Hoc. No waiting on Apple, instant install links. Wider beta testing before a production release → TestFlight. Built-in scale, no manual device management. Most teams I've worked with end up using both at different stages: Ad-Hoc during active development for quick feedback loops, TestFlight once the bui

The easiest way to remember it: preventDefault() → stops the browser's default action. stopPropagation() → stops the event from moving through the DOM. event.preventDefault() It prevents the browser's built-in behavior associated with an event. Example: clicking a link. Google document.getElementById("link").addEventListener("click", (event) => { event.preventDefault(); }); Normally: Click ↓ Browser navigates to Google With preventDefault(): Click ↓ preventDefault() ↓ ❌ Browser does NOT navigate Common uses: // Form submission event.preventDefault(); // Link navigation event.preventDefault(); // Drag/drop browser behavior event.preventDefault(); event.stopPropagation() This prevents the event from bubbling up or capturing down through parent/child elements. Example: Click me parent.addEventListener("click", () => { console.log("Parent clicked"); }); child.addEventListener("click", (event) => { event.stopPropagation(); console.log("Button clicked"); }); Without stopPropagation(): Click Button ↓ Button handler ↓ Parent handler Output: Button clicked Parent clicked With stopPropagation(): Click Button ↓ Button handler ↓ stopPropagation() ↓ ❌ Parent handler doesn't receive the event The important difference Imagine: Like If you click the button: preventDefault() button.addEventListener("click", (event) => { event.preventDefault(); }); The event can still propagate: Button ↓ Anchor ↓ Card But the browser's default action (such as following the link) is prevented. stopPropagation() button.addEventListener("click", (event) => { event.stopPropagation(); }); The event doesn't continue through the DOM: Button ↓ ❌ Anchor/Card handlers But the browser's default behavior is not automatically cancelled. Can you use both? Yes. button.addEventListener("click", (event) => { event.preventDefault(); event.stopPropagation(); }); Now you're saying: Don't perform the browser's default action. Don't let this event reach other elements.

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. Introduction: The...

If you've ever needed to build a serious data table in React, you've probably run into this problem....

A “Download all as ZIP” button in React starts simple. A production version also needs progress, cancellation, retry, useful errors, and a plan for archives that are too large for browser memory. In this tutorial, we’ll use Eazip , an open-source ZIP toolkit for JavaScript and React. Its React package gives you a hook for starting ZIP jobs and a ready-made tray for showing their status. Everyday files can be zipped entirely in the browser. When the same feature needs to handle multi-GB archives or thousands of remote URLs, it can move the job to Eazip Cloud without adding any backend code. Install the React package npm install @eazip/react @eazip/react requires React 18 or later. It includes the core ZIP engine, so you do not need to install another Eazip package. Build a working ZIP download component This component lets a user select several files and download them as one ZIP: import { useState } from ' react ' ; import { EazipTray , useEazip } from ' @eazip/react ' ; export function FileZipDownload () { const [ files , setFiles ] = useState < File [] > ([]); const zip = useEazip (); return ( < section > < label > Files to download < input type = "file" multiple onChange = { ( event ) => setFiles ( Array . from ( event . currentTarget . files ?? [])) } /> </ label > < button type = "button" disabled = { files . length === 0 || zip . isBusy } onClick = { () => zip . download ({ files , zipName : ' selected-files.zip ' , }) } > Download { files . length || '' } files as ZIP </ button > < EazipTray /> </ section > ); } There are three Eazip pieces in this example: useEazip() gives the component its download commands and current task. zip.download() starts the ZIP job and returns immediately. <EazipTray /> shows progress, cancel, retry, partial results, errors, and the completed download. No provider or CSS import is required. What happens to the selected files? Without a strategy option, Eazip uses its Local strategy. The selected File objects stay on the user’s devi

Ask any AI coding assistant directly whether using array index as a React key is a good idea, and it will tell you no. It will explain why. Reordering, insertion, and deletion of list items can cause React to misidentify which DOM node corresponds to which data, leading to state bugs and unnecessary re-renders. This is not obscure knowledge. It is one of the most commonly repeated pieces of React advice that exists, and every model has clearly seen it thousands of times during training. And yet, if you look through a codebase where the AI generated a meaningful portion of the list rendering, you will very likely find at least one instance of exactly this pattern. A map over an array, using the index as the key prop, sitting quietly in a component that otherwise looks perfectly reasonable. This is a strange thing to observe once you notice it. The AI is not confused about the rule. Ask it directly and it recites the correct answer immediately and confidently. But somewhere between knowing the rule in the abstract and applying it consistently during generation, something gets lost. Why knowing a rule and applying it are different things There is a meaningful difference between an AI model having encountered information during training and that information reliably surfacing during every relevant generation task. When you ask directly whether index as key is a good idea, you are prompting the model to retrieve and state a fact it has strong, well reinforced associations with. This is a different cognitive task than generating a list rendering component from scratch while simultaneously handling several other decisions about structure, naming, data shape, and styling. During active generation, the model is not running through a checklist of best practices for every line it writes. It is producing output token by token based on patterns, and in the moment of writing a map function, the path of least resistance is often exactly the pattern that gets flagged as wrong when

I never intended to create an audio trading app. It happened by accident during a particularly frustrating week where my eyes couldn't keep up with fourteen monitor windows simultaneously. I was watching BTC oscillate around $62k while SOL dropped another 0.92%, and my brain just... seized. Too many numbers. Too much noise. What if instead of looking, I listened ? That question led me down a rabbit hole called sonification—the practice of converting data into sound. Today, August 2026, I'm running Confrontational Meditation®, and we're sonifying real-time price movements across 1400+ cryptocurrency pairs. It's unconventional. It's chaotic. It's also the clearest way I've ever understood market movement. The Problem With Eyes Traditional charting is exhausting. You stare at candlesticks, watch moving averages, monitor volume bars. Your visual cortex becomes the bottleneck. Traders develop tunnel vision literally—focusing so hard on one chart that you miss the market context around it. When BICO spiked +28.57% today while VIC crashed -19.19%, the traditional trader has to toggle between windows. The audio listener hears it all at once . Sonification inverts this problem. Your auditory system evolved to detect patterns in sound simultaneously across a frequency spectrum. A symphony has dozens of instruments playing at once, and you parse it instantly. The same neurobiology applies to price sonification. How We Map Markets to Music At Confrontational Meditation®, each cryptocurrency generates a unique tonal signature: Pitch correlates to price. Higher prices = higher frequencies. Lower prices = lower frequencies. Volume (loudness) reflects trading volume. Silent = illiquid. Loud = significant volume. Timbre is determined by asset class or volatility profile. BTC gets a warm, stable tone. Volatility assets like PIVX (down -23.94% today) get harsh, bright timbres. Here's the core logic I built for price-to-frequency mapping: const mapPriceToFrequency = ( currentPrice , pr

Client intake often requires two types of information: searchable answers and files for review. This Vite and React example collects both in the same response. You can try the form without an account. Ask only what you need The example asks for: the client's name; a work email address; the result they need; an optional target date; up to five briefs or reference files. Each answer should help someone prepare for the first call. Leave detailed discovery questions for the call. Define the form The form schema lives in the React app: import { createClient , defineForm , FilloForm } from " @usefillo/react " ; const intake = defineForm ({ id : " vite-client-intake " , title : " Tell us about your project " , description : " Tell us what you need, when you need it and which files will help us prepare. " , pages : [ { id : " intake " , blocks : [ { id : " name " , kind : " short_text " , label : " Your name " , required : true }, { id : " email " , kind : " email " , label : " Work email " , required : true }, { id : " outcome " , kind : " long_text " , label : " What result do you need? " , required : true , }, { id : " target-date " , kind : " date " , label : " Target date " }, { id : " documents " , kind : " file_upload " , label : " Briefs or reference files (PDF, DOCX, PNG or JPG) " , accept : [ " .pdf " , " .doc " , " .docx " , " .png " , " .jpg " , " .jpeg " ], maxFiles : 5 , }, ], }, ], settings : { submitLabel : " Send project details " }, }); Keep the form and field IDs after you collect the first response. Fillo uses them as stored answer keys. You can change labels and help text without changing the IDs. The React app controls the route, layout, styles and what happens after submit. Fillo handles the schema, validation, uploads and responses. The SDK renders React controls in the page. It does not use an iframe. Send files straight to storage The browser sends each file to the storage connected to the Fillo workspace. The Vite app does not proxy the file throu

Originally published on tamiz.pro . Caching in modern web development is no longer just about serving static assets faster; it is the primary mechanism for balancing performance, cost, and data freshness. In the context of Next.js, the caching architecture has evolved significantly, shifting from a simple getStaticProps / getServerSideProps dichotomy to a sophisticated, multi-layered system that spans the Edge Runtime, the Server Components architecture, and the Node.js server environment. For software engineers and systems architects, understanding the default behaviors of Next.js caching is insufficient. To build production-grade applications that handle high concurrency without hammering your database, you must master the advanced patterns: granular revalidation, cache tagging, and external cache management. This article dives deep into these mechanisms, explaining how they work under the hood and how to orchestrate them for optimal performance. The Evolution of Next.js Caching To appreciate advanced patterns, we must first contextualize the current caching model. Next.js 13+ (App Router) introduced a new caching paradigm that is both simpler by default and more powerful when customized. The default behavior is now: App Router (RSC): Components are cached by default. Server Components are rendered once and cached on the server. The next request for the same data returns the cached result. Static Generation: Pages and layouts are built at build time and served statically. Server Components: Fetched data is cached in memory on the server, not in the browser. The critical shift here is that caching is opt-out, not opt-in . Previously, you had to explicitly mark things as static. Now, you must explicitly invalidate cache when data changes. This inversion of control places the responsibility of consistency squarely on the developer, requiring precise tools to manage invalidation. Granular Revalidation: The Tag-Based System The most significant advanced caching pattern