标签：#react

TypeScript Generic Constraints in Depth: extends , keyof , and the Patterns That Prevent Runtime Errors This article was written with the assistance of AI, under human supervision and review. Most TypeScript runtime errors stem from unconstrained generics that accept anything and crash on nothing. Teams write function get<T>(obj: T, key: string) and ship code that compiles cleanly but throws Cannot read property 'undefined' of undefined in production. The compiler stays silent because the generic accepts any type and the key accepts any string—no constraint exists to prove the key belongs to the object. Generic constraints solve this by restricting what types a generic parameter can accept. The extends keyword establishes a boundary—the generic must satisfy a specific shape. The keyof operator extracts valid keys from that shape. Together they form a type-level contract that makes illegal property access unrepresentable. The corrected signature function get<T, K extends keyof T>(obj: T, key: K): T[K] proves at compile time that key exists on obj , eliminating the entire class of property-access errors. This distinction is critical. Unconstrained generics provide no safety beyond what any offers. Constrained generics encode domain rules directly into the type system, shifting entire categories of bugs left from runtime to compile time. The patterns that follow demonstrate how production codebases use extends and keyof to build type-safe APIs that fail fast during development instead of silently in production. Key Takeaways Generic constraints with extends restrict type parameters to specific shapes, preventing the compiler from accepting types that would cause runtime failures. The keyof operator extracts object keys as a union type, enabling type-safe property access when combined with extends keyof constraints. Combining T extends SomeType with K extends keyof T creates a compile-time proof that a key exists on an object, eliminating property-access errors. Conditi

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . There is a version of this story where I walk you through the technical challenges in a clean, detached voice. Structured. Professional. Composed. This is not that version. Seven months. A hundred pages of documentation written alongside the code, not after it. A live system serving rural clinics in Delta State, Nigeria. And three bugs so specific and so cruel that each one felt designed to find the exact gap between what I thought I knew and what I actually knew. The Delta Health Information and Appointment Booking System was my final year project at the University of Port Harcourt. That sentence makes it sound smaller than it was. This was a real system for real clinics, serving patients who travel for hours to reach a healthcare facility only to find the clinic is full, the doctor is not in, or nobody told them their appointment was cancelled. These are not hypothetical users. These are people whose access to healthcare depends on whether the software works. That is a different kind of pressure than getting a good grade. And it did not start at deployment. Before a single line of code was written, I had to pitch the entire concept to my university supervisor, the Head of Department, the Faculty Dean, and an external examiner. The system had to be defensible not just technically but practically. It had to demonstrate that it solved a real problem that real people in Delta State were actually facing. I was presenting to people with decades of experience who would ask questions I had not thought of yet. That kind of scrutiny either sharpens you or breaks you. I chose to let it sharpen me. The stack was React.js, Node.js, PHP with Laravel, MySQL, AWS, and Docker. Communication channels included SMS gateways, WhatsApp Business API, and USSD because not every patient in rural Delta State has a smartphone. The system had to run on 2G connections, on entry-level Android phones with 2GB RAM

Before I critique modern web development, I want to make some points: I'm not discouraging anybody from web development. This is only my opinion and my experience of the story. Everyone has their own story. Part 1. Javascript JavaScript is known for being the web's language. It's used everywhere in the web, and can also be used to make external applications outside of web development. JavaScript has many flaws in its language, such as its comparison logic. JavaScript uses the "strict equality operator" that tries to solve its weird type coercions (e.g [] == ![] being true). Another flaw is that JavaScript has poor maintainability. JavaScript has a poorly managed type system that introduces errors without proper error handling. You cannot explicitly define what error you're trying to catch in the try-catch statement. try { functionThatThrowsError () } catch ( error ) { console . error ( error ); if ( error instanceof MyError ) { doSomething (); } } instead of modern languages: try { functionThatThrowsError () } catch ( e : MyError ) { print ! ( " error: ${e.message} " ) } This adds complexity to try-catch statements and makes it almost impossible to handle errors in a robust manner. Another issue with JavaScript's maintainability is the wording of the language. JavaScript has two keywords called undefined and null . In practice these should mean the same thing but it doesn't. An undefined variable is an uninitialized variable, or a function that doesn't return anything. Undefined: // Returns undefined function getName () {} // syntactically correct in JavaScript // but will cause undefined console . log ( getName ()); const myCoolObject = {}; console . log ( myCoolObject . property ); // still syntactically correct in JavaScript even though the property doesn't exist. Null: // Returns a null name function getName () { return null ; } // output: null console . log ( getName ()); const myCoolObject = { property : null }; console . log ( myCoolObject . property ); //out

I was tired of studying security tools from static cheatsheets, so I built ShellStack When I started prepping for CEH and doing more CTFs, I ran into the same wall over and over: every resource for learning offensive security tools was either a wall of text in a PDF, a GitHub gist with no context, or a cheatsheet that assumed you already knew what half the flags did. I didn't want notes. I wanted something that felt like sitting at an actual terminal — where I could browse tools, see real commands with context, and build the exact command I needed without digging through five tabs. So I built ShellStack . 🔗 Live: https://shell-stack.vercel.app/ 💻 Code: https://github.com/shlokkokk/ShellStack What it actually does ShellStack is a cybersecurity study platform built around one idea: learning security tools should feel operational, not passive. 280+ curated offensive security tools , organized into 19 categories, each with deep-dive docs — commands, common flags, when to use it, installation notes, and real examples Interactive command builders — instead of memorizing flag combos, you fill in a form and get a ready-to-copy command generated live 20 CEH-aligned learning modules , built for structured study instead of flipping through slides 1,000+ command cheat sheet with fast search and one-click copy A terminal-inspired UI that actually feels like a cyber-ops console instead of another docs site The build Stack: React 19, TypeScript, Vite, Tailwind CSS, GSAP, React Router, Radix UI primitives A few things I focused on: Search that actually ranks results. Early on, tool search was just naive string matching, which meant typing "nmap" could bury the actual Nmap entry under ten unrelated tools that happened to mention it in a description. I rebuilt it to weight exact and prefix matches higher, so the tool you're looking for shows up first, not buried on page 3. Command builders that don't feel like a form. The tricky part wasn't the UI, it was designing a data model that

Hot take 👀 The hardest part of React isn't hooks. It's knowing how to structure an app so it stays maintainable as it grows. Clean architecture beats clever code every time. What's been the biggest challenge in your React projects?

How I Built a Block Puzzle Game with React Native and Expo A few weeks ago, I launched my first mobile game — a block puzzle called Blockbeam. It's an 8x8 grid where you drag colorful blocks, fill rows and columns, and chase high scores. Simple concept, but building it taught me a lot about React Native's capabilities beyond typical CRUD apps. Here's what I learned. Why React Native for Games? Most mobile games are built with Unity or native code. But for a 2D puzzle game, React Native is surprisingly capable. The game doesn't need 60fps 3D rendering — it needs gesture handling, state management, and smooth animations. React Native handles all three well. The key stack: Expo SDK 54 — managed workflow, over-the-air updates, zero native config react-native-reanimated — 60fps drag animations react-native-gesture-handler — PanResponder for drag-and-drop react-native-svg — block rendering AsyncStorage — game state persistence The Puzzle Engine The core of any block puzzle is the board state. I used a flat 64-element array for the 8x8 grid: const BOARD = 8 ; const CELLS = BOARD * BOARD ; // 64 type Board = number []; // 0 = empty, 1-7 = block colors Piece placement is straightforward: check if all target cells are empty, fill them, then scan for complete rows and columns to clear. The interesting part was the "greedy solver" I built for the auto-play bot. It tries every piece in every position and picks the move that clears the most lines: for ( const piece of tray ) { for ( let r = 0 ; r <= BOARD - piece . h ; r ++ ) { for ( let c = 0 ; c <= BOARD - piece . w ; c ++ ) { if ( ! canPlace ( board , piece , r , c )) continue ; const score = simulateClear ( board , piece , r , c ); if ( score > bestScore ) { /* pick this move */ } } } } Drag and Drop with PanResponder The trickiest part was the drag mechanic. Each tray piece has a PanResponder that tracks touch position and renders a floating ghost. On release, it calculates the nearest cell position: const anchor = { col : M

This is Part 8 of 10 , a bonus practice article with 70 code-output challenges . Each challenge asks you to predict the result before revealing the answer and reasoning. Complete series This Dev.to series has five core handbook articles plus five focused practice extras. Open the series page to move through the complete reading order: Part 1: JavaScript — core handbook, questions 1–120 Part 2: React — core handbook, questions 121–220 Part 3: React Native — core handbook, questions 221–420 Part 4: Performance & Architecture — core handbook, questions 421–560 Part 5: Senior & System Design — core handbook, questions 561–719 Part 6: Output-Based JavaScript Practice — bonus practice article Part 7: Coding Interview Practice — bonus practice article Part 8: Code Output Challenges — bonus practice article Part 9: Current React Native Interview Questions — new high-frequency practice article Part 10: Project & Production Interviews — senior project ownership and real-production practice How to use this challenge set Read the code, state the exact output or error, then explain the language rule. Do not run the snippet until you have committed to an answer. For React Native interviews, connect the JavaScript behavior to rendering, state updates, list handling, or the JavaScript thread when relevant. Skills tested Hoisting, scope, closures, and this Arrays, conditions, references, object behavior, and loose versus strict equality Promises, timers, async / await , and microtasks Common JavaScript patterns used in React and React Native interviews Code output challenges Challenge 1. Block-scoped counter Predict the exact output before opening the answer. let total = 0 ; for ( let i = 0 ; i < 3 ; i ++ ) { total += i ; } console . log ( total ); Answer and explanation Expected output: 3 Why: The loop adds 0, 1, and 2. Challenge 2. var callback loop Predict the exact output before opening the answer. for ( var i = 0 ; i < 3 ; i ++ ) { setTimeout (() => { console . log ( i ); }, 0

This is Part 7 of 10 , a bonus practice article containing 75 coding interview questions drawn from the React Native Interview Handbook. It covers the implementation tasks commonly used in JavaScript and React Native rounds, from string and array problems to hooks, FlatList , asynchronous work, caching, retries, and native modules. Complete series This Dev.to series has five core handbook articles plus five focused practice extras. Open the series page to move through the complete reading order: Part 1: JavaScript — core handbook, questions 1–120 Part 2: React — core handbook, questions 121–220 Part 3: React Native — core handbook, questions 221–420 Part 4: Performance & Architecture — core handbook, questions 421–560 Part 5: Senior & System Design — core handbook, questions 561–719 Part 6: Output-Based JavaScript Practice — bonus practice article Part 7: Coding Interview Practice — bonus practice article Part 8: Code Output Challenges — bonus practice article Part 9: Current React Native Interview Questions — new high-frequency practice article Part 10: Project & Production Interviews — senior project ownership and real-production practice How to answer coding questions Before coding, clarify inputs, output, edge cases, platform constraints, time complexity, space complexity, cancellation, and test coverage. Start with a correct readable solution, then optimize only when the constraint justifies it. Topics covered Strings, arrays, maps, sets, recursion, and algorithmic complexity Debounce, throttle, memoization, deep cloning, and polyfills Custom hooks, API state, error boundaries, and React rendering FlatList pagination, pull to refresh, search, and offline retry Promises, timeouts, concurrency limits, and exponential backoff Caching, EventEmitter, Pub/Sub, LRU design, and native module boundaries Interview coding checklist Confirm assumptions before writing code. State time and space complexity. Handle empty input, invalid input, and duplicate values deliberately

This is Part 6 of 10 , a bonus practice article containing 191 output-based JavaScript interview questions . It includes 111 questions drawn from the React Native Interview Handbook plus 80 additional questions on the JavaScript behavior interviewers commonly test in React Native rounds: hoisting, scope, closures, arrays, objects, functions, coercion, conditions, Promises, and the event loop. Complete series This Dev.to series has five core handbook articles plus five focused practice extras. Open the series page to move through the complete reading order: Part 1: JavaScript — core handbook, questions 1–120 Part 2: React — core handbook, questions 121–220 Part 3: React Native — core handbook, questions 221–420 Part 4: Performance & Architecture — core handbook, questions 421–560 Part 5: Senior & System Design — core handbook, questions 561–719 Part 6: Output-Based JavaScript Practice — bonus practice article Part 7: Coding Interview Practice — bonus practice article Part 8: Code Output Challenges — bonus practice article Part 9: Current React Native Interview Questions — new high-frequency practice article Part 10: Project & Production Interviews — senior project ownership and real-production practice How to use this guide Before opening an answer, state the exact output first. Then explain the rule that causes it: evaluation order, scope, coercion, reference identity, prototype lookup, or microtask scheduling. Run the snippet only after committing to an answer. Topics covered Hoisting, Temporal Dead Zone, var , let , const , and function declarations Scope, closures, this , arrow functions, call , apply , and bind Arrays, sparse arrays, map , reduce , sort , slice , splice , and mutation Objects, references, shallow copies, prototypes, getters, and property lookup Conditions, truthiness, equality, nullish coalescing, and type coercion Promises, async / await , microtasks, timers, and error recovery React and React Native rendering behavior, state updates, effects,

Parallel Routes let you render multiple pages simultaneously within the same layout. Instead of navigating away from a page to show another one, you can display both at the same time — a dashboard with independently navigable sections, a main content area alongside a sidebar that changes with its own navigation, or a feed with an openable detail panel that doesn't replace the feed. This is one of the more powerful App Router features and one of the more confusing to set up initially. Here's the complete pattern, including the design approach used for complex multi-panel interfaces like the generation tool at Pixova . The Core Concept — Named Slots Parallel routes use named slots: special folders prefixed with @ that define independent rendering areas within a layout. app/ ├── layout.tsx ← Receives slot props ├── page.tsx ← Default slot content ├── @sidebar/ │ ├── page.tsx ← Sidebar default │ └── settings/ │ └── page.tsx ← Sidebar settings view └── @modal/ ├── page.tsx ← Modal default (null) └── photo/[id]/ └── page.tsx ← Photo modal The layout receives each slot as a prop: // app/layout.tsx export default function Layout ({ children , sidebar , modal , }: { children : React . ReactNode ; sidebar : React . ReactNode ; modal : React . ReactNode ; }) { return ( < div className = "flex h-screen" > < aside className = "w-64 border-r" > { sidebar } </ aside > < main className = "flex-1" > { children } </ main > { modal } </ div > ); } Now children , sidebar , and modal can each navigate independently. Independent Navigation — The Key Behavior Each parallel route slot navigates independently. When a user navigates from / to /settings , the children slot updates. The sidebar slot stays exactly where it was — its navigation state is independent. This is the key difference from nested layouts. Nested layouts rerender from the changed segment outward. Parallel routes don't affect each other. User is at / (children shows home, sidebar shows default nav) User navigates to /setti

Hey everyone, I recently had an "aha!" moment regarding how React handles updates under the hood, and I wanted to share it because I realize a ton of developers (including myself, until recently) trip over this exact concept. The common mental model is that React Reconciliation compares the Virtual DOM directly to the Real Browser DOM and surgically updates only what changed. But that’s fundamentally incorrect. React never reads or directly compares the real DOM during the diffing process. It actually splits the process into two entirely separate phases —The Render Phase and The Commit Phase —which creates a massive distinction between Re-rendering and Re-painting. Here is the exact breakdown of what happens when a single state change affects just 1 out of 100 divs in a component: The Render Phase (Pure JavaScript) When state changes, React calls your component function. It doesn't know which of your 100 divs changed yet, so it has to evaluate the entire JSX block. The Scope: React re-renders all 100 virtual divs in memory. The Process: It builds a brand-new Virtual DOM tree and compares it to the previous Virtual DOM tree (JavaScript object vs. JavaScript object). The Outcome: It spots that 99divs are identical, but 1 div has an update. It flags that single virtual node with an "Update" tag. Because this happens purely in-memory as JavaScript, it is incredibly fast and cheap. The Commit Phase (The Real DOM Update) This is where Reconciliation does its primary job. It acts as a shield to protect the browser from doing unnecessary work. The Scope: React completely ignores the 99 unchanged elements. The Process: It surgically targets the single real browser div associated with the flagged Virtual DOM element and updates only its modified property (e.g., element.textContent = "New Value"). The Outcome: The browser repaints only 1 single div on the screen. The Conclusion: Reconciliation isn't about stopping React from re-rendering (re-running JS to calculate the UI). It

Hoi hoi! I’m @nyaomaru, a frontend engineer currently fighting the intense European heatwave by...

In today's mobile-first world, users expect authentication to be both secure and effortless. Typing passwords every time an app is opened not only impacts the user experience but also introduces security risks if passwords are weak or reused. Biometric authentication solves this problem by allowing users to verify their identity using Fingerprint , Face ID , Touch ID , Iris Scanner , or even their device's PIN/Password . If you're building a React Native application, @sbaiahmed1/react-native-biometrics is one of the most comprehensive biometric libraries available. Beyond simple authentication prompts, it offers hardware-backed cryptographic key management, biometric enrollment detection, device integrity checks, StrongBox support, and compatibility with both the React Native New Architecture and Expo. In this article, we'll explore everything this library offers and learn how to integrate biometric authentication into a React Native application. Why Biometric Authentication? Traditional authentication methods come with several drawbacks: Passwords are easy to forget. Weak passwords are vulnerable to attacks. OTP-based logins can be slow and frustrating. Users often abandon apps with poor login experiences. Biometric authentication addresses these challenges by providing: 🔒 Enhanced security ⚡ Faster authentication 😊 Better user experience 📱 Native platform support 🔑 Secure fallback using device credentials Whether you're building a banking app, healthcare platform, enterprise application, or e-commerce app, biometric authentication has become an expected feature. Installation Install the package using npm: npm install @ sbaiahmed1 /react-native-biometric s or with Yarn: yarn add @ sbaiahmed1 /react-native-biometric s For iOS: cd ios pod install Platform Configuration Before using biometric authentication, configure the required permissions for both Android and iOS. Android Open your android/app/src/main/AndroidManifest.xml file and add the following permissions: <

I run EstimatorSuite.com — we review construction estimating software for US contractors (HVAC, electrical, plumbing, roofing, landscaping). We just open-sourced our entire calculator suite: 42 construction calculators under MIT license. React + TypeScript + Tailwind. 🔗 Repo 🔗 Live Demo 🔗 npm What's included: • 36 material calculators (concrete volume, roofing squares, drywall, paint, flooring, etc.) • 6 trade estimators (HVAC load, electrical conduit fill, plumbing pipe sizing) Two entry points: → React components — drop into any project → Pure calculation functions — zero UI dependency, works in Node.js, Vite, Next.js, anywhere Why we built this: Construction software is expensive. Contractors told us they needed free tools that actually work — not ad-filled spreadsheets. So we built them, and we open-sourced them. Full story →

🎧 DJ ROOTS – Building a Real-Time Collaborative Music Platform with Gesture Control Crowd Vibes. You Control. Music is one of the best ways to bring people together. However, during parties, college events, hostel gatherings, or study sessions, one common problem always exists— who gets to control the music? Usually, one person owns the playlist while everyone else keeps requesting songs. This often creates confusion, interruptions, and arguments over what should play next. Our team wanted to solve this problem by creating a platform where everyone in the room gets an equal voice. Welcome to DJ ROOTS . 🚨 The Problem Traditional music streaming at group events has several limitations: Only one person controls the playlist. Song requests are ignored or forgotten. No real-time collaboration. Existing queue systems don't truly represent the crowd's choice. There is no simple browser-based solution that works instantly without downloading an app. We wanted to build something that makes music democratic . 💡 Our Solution DJ ROOTS is a real-time collaborative DJ platform where anyone can join a room using a simple room code. Participants can: Create or join a music room Add songs using YouTube Upvote or downvote tracks Automatically reorder the queue based on crowd votes Watch every change happen instantly across all connected devices Let the host control playback using webcam hand gestures Instead of one person deciding the playlist, the entire crowd decides what plays next. 🛠 Tech Stack Frontend React 19 Vite Tailwind CSS v4 Framer Motion Three.js GSAP OGL Backend Node.js Express.js Database & Authentication Supabase PostgreSQL Supabase Authentication Supabase Realtime Computer Vision Google MediaPipe Gesture Recognizer Audio Pipeline yt-dlp youtube-dl-exec HTML5 Audio API Web Audio API Deployment Vercel (Frontend) ⚙️ How It Works Users create or join a room using a unique room code. Songs are added using a YouTube link or search. Song metadata is automatically fetched. E

The problem with most web UIs is the gap between user action and visible feedback. A user clicks "like" and waits 200-400ms for the server to respond before the button changes. That delay reads as slowness even when the server is fast. The network round-trip is the ceiling. Optimistic UI inverts this: assume the operation will succeed, update the UI immediately, then reconcile with the server response when it arrives. If the server fails, roll back. React 19's useOptimistic hook gives you this pattern with minimal boilerplate and automatic rollback built in. The API const [ optimisticState , addOptimistic ] = useOptimistic ( state , // the current "real" state — synced from server updateFn , // (currentState, optimisticValue) => newOptimisticState ) optimisticState — during a pending transition, reflects the optimistic update. Once the transition completes, it reverts to state addOptimistic(value) — triggers an optimistic update, must be called inside startTransition Pattern 1: Like Button ' use client ' import { useOptimistic , useTransition } from ' react ' import { toggleLike } from ' @/actions/likes ' type LikeState = { liked : boolean ; count : number } export function LikeButton ({ postId , initialLiked , initialCount }: { postId : string initialLiked : boolean initialCount : number }) { const [ isPending , startTransition ] = useTransition () const [ optimisticState , addOptimistic ] = useOptimistic < LikeState > ( { liked : initialLiked , count : initialCount }, ( current ) => ({ liked : ! current . liked , count : current . liked ? current . count - 1 : current . count + 1 , }) ) function handleToggle () { startTransition ( async () => { addOptimistic ( ' toggle ' ) // updates UI immediately await toggleLike ({ postId }) // syncs with server }) } return ( < button onClick = { handleToggle } disabled = { isPending } > < Heart className = { cn ( ' h-4 w-4 ' , optimisticState . liked && ' fill-red-500 text-red-500 ' ) } /> < span > { optimisticState . count }

Hello Dev Community! 👋 It is officially Day 136 of my software engineering marathon! Today, I engineered the absolute heart of my MERN Stack capstone application, Sprintix : The complete Product Collection Grid & Faceted Filter Sidebar View ( /collection ) ! ⚛️🛍️🗂️ To prepare the application for seamless full-stack state management integration later, I built this layout using dynamic state arrays and object schemas. This ensures that switching from demo arrays to live API streams will happen effortlessly. 🛠️ Deconstructing the Day 136 Catalog Architecture As displayed across my browser rendering workspace in "Screenshot (311).jpg" and "Screenshot (312).jpg" , phase one of the product engine splits into structural layout segments: 1. Faceted Category Filter Sidebar Organized dedicated verification check-boxes mapping out specific consumer collections: Categories: Segmented target groups (Men, Women, Kids). Type Filters: Segmented style formats (Top Wear, Bottom Wear, Winter Wear). Styled within minimal box borders to give users an uncluttered desktop searching experience. 2. Header Control Grid & Sort Registries Installed a top-level workspace header showing "All Collection" alongside an interactive drop-down management node ( Sort by: relevant / low-to-high / high-to-low ). Ready to hold local state flags that rearrange the data arrays instantly before looping. 3. Deep Route Parameter Mapping Preparation Look at the hover elements in "Screenshot (311).jpg" ! Every single rendering card passes localized hex-token structures mapping toward dynamic pathways like: text /product/:id (e.g., /product/6a436b5c921b7aa010d29318)

Hello Dev Community! 👋 It is officially Day 134 of my software engineering marathon! Today, I successfully extended the layout grids of my MERN Stack capstone e-commerce application, Sprintix , by implementing fully responsive feature banners, newsletter hooks, and a clean global footer! ⚛️🛡️📬 A premium storefront relies heavily on trust anchors and consistent site-wide navigational structures. Today's focus was ensuring these terminal layers look flawless across all viewport breaking thresholds. 🛠️ Deconstructing the Day 134 Interface Terminal As captured in my local hosting environments within "Screenshot (301).jpg" and "Screenshot (302).jpg" , the system layout introduces high-fidelity structural blocks: 1. Trust Policy Infrastructure Positioned a 3-column micro-service layer layout framing crucial customer success policies (Easy Exchange, 7 Days Return, 24/7 Support). Balanced standard tracking font sizes and vector alignments to maintain optimal layout readability. 2. Immersive Newsletter Conversion Segment Engineered an engaging email onboarding banner using rich layered visual configurations. Integrated a responsive inline input element paired with an absolute action button to ensure the container shifts scales perfectly when transitioning down to mobile form factors. 3. Consolidated Multi-Grid Footer System Look at "Screenshot (302).jpg" ! Structured a highly scalable flex-wrapping matrix containing: Brand Identity Columns hosting contextual descriptive descriptions. Navigational Routing Indexes pointing clearly to operational views (Home, About Us, Privacy Policy). Direct Touchpoints aggregating structural contact details. Finished off the grid matrix with a clean full-width divider row holding structural copyright information. 💡 The Technical Win: Designing for Fluid Responsiveness First When building high-traffic online stores, mobile responsiveness isn't a secondary polish step—it has to be native. Writing components with flexible flexbox wrapping, relat

I wanted to build something different from the usual fan project. Instead of recreating gameplay, I asked a different question: How well do players actually remember the worlds of Super Mario Odyssey? The result is OdysseyGuessr, a browser game inspired by GeoGuessr. Players receive a screenshot from one of the game's Kingdoms and must place a marker on the correct location. Every meter counts. The project includes: Browser-based gameplay Single-player with customizable rounds Real-time multiplayer with a 5,000 HP battle system Community-submitted locations Admin moderation tools One of the biggest challenges wasn't the gameplay—it was collecting interesting locations that were difficult but still fair. Watching players confidently choose the wrong cliff or rooftop has been surprisingly entertaining. If you're interested in browser games or Nintendo fan projects, I'd love to hear your feedback. Play here: https://odyssey-guessr.lovable.app OdysseyGuessr is an unofficial fan project and is not affiliated with Nintendo.

Everyone can type "use client" . Almost nobody can say what survives the trip across it — and then something breaks: next build dies at prerender, the error names no file and no import chain, and the prop that killed it was an arrow one level down inside an object called options . Here's the uncomfortable secret: the boundary is one serializer . React walks every prop you hand a client component, encodes each value it has a branch for, and throws on the first one it doesn't. This post reads those branches out of React 19's Flight source — one file, no framework — and shows the two traps that pass code review and fail the build anyway. What crosses A prop is legal if the serializer has a branch for it. Everything else falls into one prototype check and throws. The whole contract fits on a screen: // app/page.tsx — a Server Component. Every comment is the serializer's verdict. export default function Page () { return ( < Chart title = "Q3" data = { { rows : [ 1 , 2 , 3 ] } } when = { new Date () } seen = { new Set ([ 1 ]) } index = { new Map () } rows = { fetchRows () } // an un-awaited Promise; the client calls use(rows) bytes = { new Uint8Array ( 8 ) } // ArrayBuffer, DataView, every typed array upload = { new File ([], ' a.csv ' ) } // there is no File branch — a File is a Blob form = { new FormData () } stream = { new ReadableStream () } kind = { Symbol . for ( ' chart ' ) } // global symbols cross; Symbol('chart') throws Slot = { Legend } // a client component: a function, and a client reference save = { saveRow } // a "use server" function: a server reference err = { new Error ( ' boom ' ) } // crosses — and arrives empty in production // no branch — every one of these throws at render match = { /q3/ } href = { new URL ( ' https://x.dev ' ) } cache = { new WeakMap () } user = { new User ( ' ada ' ) } bare = { Object . create ( null ) } onPick = { ( id ) => select ( id ) } /> ); } Four of those lines are the ones people get wrong: new Error() crosses, and product