标签：#React

You know that moment when your React Suspense fallback jumps on the screen, then disappears, then reappears, leaving you wondering if you did something wrong? I’ve been there , seeing flickers, multiple loading spinners, or even UI glitches around Suspense felt like chasing ghosts. Turns out, React’s concurrent rendering scheduler is doing a lot behind the scenes , juggling priorities, pausing work, and restarting it , and Suspense boundaries are right in the middle of this dance. Understanding how React schedules work and handles interruptions can save you hours of frustration. React’s concurrent rendering scheduler: what’s it really doing? React’s concurrent mode isn’t just a fancy name; it means React doesn’t blindly render your entire component tree all at once. Instead, it breaks rendering work into chunks and spreads it out over multiple frames. This keeps your app responsive to user input and other high-priority tasks. Imagine you’re painting a huge mural. Instead of finishing it in one go (blocking everything else), you paint a little, step back, listen if someone calls you, then paint some more. React’s scheduler works similarly: Units of work : React slices rendering into small units it can pause and resume. Priorities : Some updates are more urgent , like responding to a click , so they jump ahead. Interruptions : If something more important comes up, React pauses current work and switches. This model makes React apps feel snappy even when doing heavy rendering or fetching data. What happens when Suspense enters the scene? Suspense boundaries are React’s way to say, “Hey, if this component isn’t ready yet (because it’s waiting on data, code, or something else), show this fallback for now.” Under the hood, when a component suspends (throws a Promise), React marks that unit of work as "waiting," and the Suspense boundary kicks in to show the fallback UI immediately. But here’s the catch: React keeps trying to finish rendering the suspended component in the

Welcome back to the React Mastery Series ! In the previous article, we learned how React applications communicate with backend services using Fetch API and Axios , along with best practices like service layers, interceptors, and error handling. Today, we'll explore one of the most common features you'll build as a React developer: Forms in React Whether it's: User Login Registration Profile Update Payment Details Contact Forms Search Filters Forms are everywhere. Learning how to build performant, scalable, and validated forms is an essential skill for every React developer. Understanding Forms in React A form is a collection of input elements used to collect user data. Example: Login Form Email,Password and Login Button React provides multiple ways to manage form data. The two most common approaches are: Controlled Components Uncontrolled Components Controlled Components In a controlled component, React controls the input value through state. Example: import { useState } from " react " ; function Login () { const [ email , setEmail ] = useState ( "" ); return ( < input type = "email" value = { email } onChange = { ( e ) => setEmail ( e . target . value ) } /> ); } Flow: User Types ↓ onChange ↓ React State ↓ Input Updates The input value always comes from React state. Why Controlled Components? Benefits: Easy validation Easy formatting Predictable state Better debugging Example: if ( email . length < 5 ) { // Show validation message } Since the value is stored in state, validation becomes straightforward. Uncontrolled Components In uncontrolled components, the DOM manages the input value. React accesses it using a ref. Example: import { useRef } from " react " ; function Login () { const emailRef = useRef < HTMLInputElement > ( null ); function handleSubmit () { console . log ( emailRef . current ?. value ); } return ( <> < input ref = { emailRef } /> < button onClick = { handleSubmit } > Login </ button > </> ); } Use uncontrolled components when you don't need Reac

30 Technical Interview Questions You Should Be Able to Explain Out Loud (JS / React / Node) Most interview prep content gives you a definition. Real interviews test something different: can you explain your reasoning clearly, out loud, under a little pressure — not just recite the right words. I put together 30 questions across JavaScript, React, and Node.js. Every answer here is written the way you'd actually say it in an interview, not the way a textbook would write it. How to actually use this: cover the answer, try explaining it out loud in under 30 seconds, then read the answer. If you froze or rambled, that's the real signal — more than whether you technically knew the concept. JavaScript Fundamentals 1. What's a closure, and why does it actually matter in real code? A closure is a function that remembers the variables from where it was created, even after that outer function has finished running. It powers private variables, debouncing, memoization, and module patterns. 2. setTimeout(fn, 0) vs Promise.then() — which runs first? The Promise wins. .then() callbacks go into the microtask queue, which fully drains before the next macrotask (like setTimeout ) runs — even with a 0ms delay. 3. Why does var break inside loops with closures, but let doesn't? var is function-scoped — every iteration shares the same variable. let is block-scoped, so each iteration gets its own fresh binding. 4. Where does == actually give you a different (and wrong) answer than === ? == does type coercion first — 0 == false and '' == 0 are both true. === compares type and value directly, no surprises. 5. Why does this break in callbacks with regular functions, but not arrow functions? Regular functions get this based on how they're called. Arrow functions inherit this lexically from where they were defined, so it stays consistent no matter how they're invoked. 6. If a property isn't on an object, where does JS look next? JS walks the prototype chain — the object, then its prototype, the

Static site generation has a branding problem. Say "static site" and people picture a blog with twelve posts and a contact form. So how far can you actually push it before you need a backend? Further than most people assume. This is a walkthrough of a production site that has no database, no API layer, no user accounts and no server-side state, and still ships 232 prerendered pages with per-user results, shareable links and dynamic social cards. The site is a Spanish political test with nine ideological axes, seventeen parties, fifty-four questions. It is in Spanish, but nothing here depends on reading it. Treat it as the reference implementation. The architecture in one sentence Three data files are the source of truth, everything else is derived at build time, and everything user-specific happens in the browser. That is the whole trick. The rest is consequences. 1. Derive pages, don't author them The site has 232 URLs. Almost none of them were written by hand. There are three data modules: the axes, the parties, and the questions. From those, generateStaticParams produces every content route: // app/ejes/[id]/page.tsx export function generateStaticParams () { return AXES . map (( a ) => ({ id : a . id })) } The interesting one is the comparison pages. Seventeen parties means 17 × 16 / 2 = 136 unique pairs, and each pair gets its own page, its own metadata and its own canonical URL: export function allPairs () { const out = [] for ( let i = 0 ; i < PARTIES . length ; i ++ ) for ( let j = i + 1 ; j < PARTIES . length ; j ++ ) out . push ({ a : PARTIES [ i ]. id , b : PARTIES [ j ]. id }) return out } export function generateStaticParams () { return allPairs (). map (( p ) => ({ pair : pairSlug ( p . a , p . b ) })) } 136 pages from twelve lines. And because the page body is computed from the same vectors, recalibrating one party silently rewrites the sixteen pages that involve it . No CMS, no migration, no content drift. The numbers on the page cannot disagree with

React TypeScript Property Form Validation export interface PropertyForm { propertyTitle : string ; description : string ; amenities : string ; monthlyRent : string ; location : string ; unitsAvailable : string ; applicationDeadline : string ; } export interface PropertyFormErrors { propertyTitle ?: string ; description ?: string ; amenities ?: string ; monthlyRent ?: string ; location ?: string ; unitsAvailable ?: string ; applicationDeadline ?: string ; } export const validatePropertyField = ( name : keyof PropertyForm , value : string ): string => { switch ( name ) { case " propertyTitle " : if ( ! value . trim ()) { return " Property title is required " ; } if ( value . trim (). length < 3 ) { return " Property title must be at least 3 characters " ; } return "" ; case " description " : if ( ! value . trim ()) { return " Description is required " ; } if ( value . trim (). length > 2000 ) { return " Description cannot exceed 2000 characters " ; } return "" ; case " amenities " : if ( ! value . trim ()) { return " Amenities are required " ; } return "" ; case " monthlyRent " : if ( ! value . trim ()) { return " Monthly rent is required " ; } if ( Number ( value ) <= 0 ) { return " Monthly rent must be greater than 0 " ; } return "" ; case " location " : if ( ! value . trim ()) { return " Location is required " ; } return "" ; case " unitsAvailable " : if ( ! value . trim ()) { return " Units available is required " ; } if ( ! Number . isInteger ( Number ( value ))) { return " Units available must be a whole number " ; } if ( Number ( value ) < 1 ) { return " At least 1 unit must be available " ; } return "" ; case " applicationDeadline " : if ( ! value ) { return " Application deadline is required " ; } return "" ; default : return "" ; } }; export const validatePropertyForm = ( formData : PropertyForm ): PropertyFormErrors => { const errors : PropertyFormErrors = {}; Object . entries ( formData ). forEach (([ name , value ]) => { const error = validatePropertyFiel

Welcome back to the React Mastery Series ! In the previous article, we explored Custom Hooks in React and learned how reusable logic helps developers build scalable and maintainable applications. Today, we will explore one of the most important concepts in modern frontend development: React Routing Almost every real-world React application contains multiple screens: Login Dashboard Profile Settings Reports Transactions Admin panels But React applications are usually built as: Single Page Applications (SPA) So how do we navigate between different pages without refreshing the browser? The answer is React Router What is Client-Side Routing? Traditional websites work like this: User Clicks Link | ↓ Browser Requests New HTML Page | ↓ Server Sends Page | ↓ Browser Reloads Every navigation causes a full page refresh. React Single Page Applications work differently: User Clicks Link | ↓ React Router Intercepts Request | ↓ URL Changes | ↓ React Loads Component | ↓ No Page Refresh This creates a smooth application experience. What is React Router? React Router is a library that enables navigation between different components based on the URL. Example: /login /dashboard /profile /settings Each URL maps to a React component. Example: /login | ↓ Login Component /dashboard | ↓ Dashboard Component Installing React Router For a React application: npm install react-router-dom The package provides: BrowserRouter Routes Route Link Navigate useNavigate useParams Setting Up BrowserRouter The first step is wrapping your application. Example: import { BrowserRouter } from " react-router-dom " ; import App from " ./App " ; ReactDOM . createRoot ( document . getElementById ( " root " )). render ( < BrowserRouter > < App /> </ BrowserRouter >, ); Now React can manage browser navigation. Creating Routes Routes define which component should display for a URL. Example: import { Routes , Route } from " react-router-dom " ; function App () { return ( < Routes > < Route path = "/" element = { < Ho

This is part of my Building Fluentic Style series, where I’m writing down the design decisions, tradeoffs, and small surprises from building Fluentic Style . It is one thing to make a styling library feel good in a client-side app. It is another thing to make it feel good in Next.js App Router. In a simple SPA-style development setup, most of the styling loop lives in one place: component renders in the browser Fluentic style chain resolves atomic CSS rule is inserted DevTools can inspect the generated rule sourcemap points back to authored code That is already a lot of work. But at least the browser is the main place where the style is produced and consumed. Next.js App Router changes the shape of the problem. Now the page can involve: server rendering React Server Components client components streamed HTML hydration client-side navigation HMR Webpack or Turbopack development sourcemaps production extraction So the hard part is not just “can Fluentic run in Next.js?” The hard part is: Can Fluentic keep the same CSS debugging experience when styles cross the server/client boundary? That is what this post is about. Docs for the Next.js integration are here: Next.js Integration DevTools And Sourcemaps Runtime And Dev Debug Without Getting Lost The Goal Was Not A Special Next.js API I did not want Fluentic to have one mental model for client apps and another one for Next.js. This should still be normal Fluentic: const card = style ({ padding : 16 , borderRadius : 12 , }). hover ({ boxShadow : ' 0 12px 30px rgb(15 23 42 / 0.16) ' , }); export function Card () { return < section css = { card } > Hello </ section >; } And this should still be normal Fluentic too: const buttonStyles = { root : style . slot ({ display : ' inline-flex ' , border : 0 , }), label : style . slot ({ fontWeight : 700 , }), }; const danger = style . scope ([ buttonStyles . root ({ backgroundColor : ' #dc2626 ' , }), buttonStyles . label ({ color : ' #ffffff ' , }), ]); The Next.js integration shou

There are exactly three sensible ways to get an SVG icon into a React codebase: paste it inline as a component, import the file through a build transform like SVGR, or reference it from a sprite. Most projects need only the first. This guide walks through the inline approach with Next.js and Tailwind specifics, and points to the deeper guides where a topic deserves its own article. Option 1: an inline JSX component Take a real icon from the catalog, convert the SVG attributes to JSX casing, and you have a dependency-free component. This is Lucide's search icon, exactly as it ships in the Lucide set , wrapped for React: export function SearchIcon ( props ) { return ( < svg xmlns = "http://www.w3.org/2000/svg" viewBox = "0 0 24 24" fill = "none" stroke = "currentColor" strokeLinecap = "round" strokeLinejoin = "round" strokeWidth = { 2 } aria-hidden = "true" { ... props } > < path d = "m21 21l-4.34-4.34" /> < circle cx = "11" cy = "11" r = "8" /> </ svg > ); } The JSX gotchas are all attribute casing: stroke-width becomes strokeWidth , stroke-linecap becomes strokeLinecap , and class becomes className . Icon pages on this site do the conversion for you: every icon offers React, Vue, Svelte, and Solid snippets next to the raw SVG, so you can copy the JSX form directly. If you have a folder of SVG files instead, the free SVG to component converter batch-converts them in the browser. Prefer importing .svg files over pasting? That is the SVGR route, covered step by step in our React with Vite and SVGR guide . Next.js: server components by default An icon component like the one above has no state, no effects, and no event handlers, which makes it a perfect React Server Component. In the Next.js App Router it renders to static markup on the server and adds nothing to the client bundle: import { SearchIcon } from " @/components/icons " ; export default function DocsHeader () { return ( < label className = "flex items-center gap-2" > < SearchIcon className = "h-5 w-5 text-zinc

Welcome back to the React Mastery Series ! In the previous article, we explored useEffect Hook and learned how React handles side effects such as: API calls Timers Event listeners WebSocket connections Cleanup operations Today, we will explore two more powerful React Hooks: useRef and useMemo These Hooks are frequently used in production applications to: Access DOM elements Store values without triggering re-renders Optimize expensive calculations Improve application performance Understanding useRef Hook useRef is a React Hook that allows us to store a value that persists across renders without causing the component to re-render. Syntax: const reference = useRef ( initialValue ); The returned object looks like: { current : initialValue } The value is accessed using: reference . current useRef vs useState A common question: Why do we need useRef when we already have useState? The difference: useState useRef Updates trigger re-render Updates do not trigger re-render Used for UI data Used for storing values React tracks changes React does not track changes Example: const [ count , setCount ] = useState ( 0 ); Updating: setCount ( count + 1 ); causes: State Update | ↓ Component Re-render With useRef: const count = useRef ( 0 ); Updating: count . current ++ ; does: Value Updated | ↓ No Re-render Using useRef to Access DOM Elements One of the most common use cases of useRef is accessing DOM elements directly. Example: import { useRef } from " react " ; function SearchBox () { const inputRef = useRef (); function focusInput () { inputRef . current . focus (); } return ( < div > < input ref = { inputRef } /> < button onClick = { focusInput } > Focus Input </ button > </ div > ); } Flow: Button Click | ↓ focusInput() | ↓ inputRef.current | ↓ Input DOM Element | ↓ focus() Real-World Example: Login Page Imagine a banking login page. When the page loads: Open Login Page | ↓ Username Field Automatically Focused Implementation: useEffect (() => { usernameRef . current . focus ();

Introduction React is fast, but that doesn't mean every React application is. One of the most common performance problems—especially in growing applications—is unnecessary re-rendering . A small project with a few components may feel instant, but as your application grows, unnecessary renders can cause sluggish interfaces, input lag, excessive CPU usage, and poor user experience. The good news is that unnecessary re-renders are usually preventable once you understand why React re-renders components . In this article, we'll explore how React rendering works, learn how to identify performance bottlenecks, and apply practical optimization techniques such as React.memo , useMemo , useCallback , better state management, and component architecture. Whether you're building dashboards, e-commerce stores, SaaS products, or portfolio websites, these techniques will help you write more efficient React applications. Table of Contents Understanding React Rendering What Causes Unnecessary Re-renders? Identifying Performance Problems Optimizing with React.memo Optimizing Expensive Calculations with useMemo Preventing Function Recreation with useCallback State Colocation Splitting Components Optimizing Context Rendering Large Lists Using the React Profiler Best Practices Common Mistakes Performance Tips Security Considerations Accessibility Considerations SEO Considerations Real Project Example Conclusion Discussion Background Before optimizing anything, it's important to understand what React actually does. A render simply means React executes your component function to determine what the UI should look like. That does not always mean the browser updates the DOM . React compares the new Virtual DOM with the previous one and only updates the parts that actually changed. However, if many components re-render unnecessarily, React still has to: Execute component functions Recreate objects Recreate arrays Recreate event handlers Compare Virtual DOM trees All of that work adds up. Step

Welcome back to the React Mastery Series ! In the previous article, we explored React Rendering and Component Lifecycle . We learned: What causes a component to re-render How React reconciliation works The difference between rendering and DOM updates How lifecycle behavior is handled using Hooks Now let's learn how React applications respond to user interactions. Every modern application depends on events: Clicking buttons Typing into forms Selecting options Submitting data Dragging and dropping elements Keyboard shortcuts React provides a powerful event system to handle all these interactions. What is Event Handling? Event handling is the process of responding to user actions in an application. Examples: User Action | ↓ Event Triggered | ↓ Event Handler Executes | ↓ State Updated | ↓ UI Re-renders Example: A user clicks the "Transfer Money" button: Click Button | ↓ Handle Click Event | ↓ Validate Data | ↓ Call API | ↓ Update UI Events in Traditional JavaScript vs React Traditional JavaScript const button = document . getElementById ( " save " ); button . addEventListener ( " click " , saveData ); You manually: Find the DOM element Attach event listeners Manage updates React React attaches events directly inside JSX. < button onClick = { saveData } > Save </ button > React manages the event registration internally. React Event Syntax React events use: camelCase naming JSX expressions Function references HTML: <button onclick= "save()" > Save </button> React: < button onClick = { save } > Save </ button > Notice: onclick ❌ onClick ✅ Handling Click Events Example: function Button () { function handleClick () { console . log ( " Button clicked " ); } return ( < button onClick = { handleClick } > Click Me </ button > ); } When the user clicks: Click | ↓ handleClick() | ↓ Execute Logic Passing Functions vs Calling Functions A very common beginner mistake. Incorrect < button onClick = { handleClick () } > Save </ button > This executes immediately during rendering. Correc

Welcome back to the React Mastery Series ! In the previous article, we learned about State in React and how state changes make our applications interactive. Today, we will understand one of the most important concepts for every React developer: How does React render components? Many developers know how to write React code, but understanding when and why React renders is what separates a beginner from an advanced React developer. A strong understanding of rendering helps you: Build faster applications Avoid unnecessary re-renders Debug performance issues Use optimization techniques correctly Let's dive in. What is Rendering in React? Rendering is the process where React: Takes your component code Creates a representation of the UI Updates the browser DOM when necessary A simple way to visualize it: Component Code | ↓ React creates Element Tree | ↓ Reconciliation Process | ↓ Browser DOM Update Rendering does not always mean updating the browser DOM . React may render a component, compare the result, and decide that no DOM changes are required. Initial Render When a React application starts, the first rendering process happens. Example: function App () { return ( < h1 > Hello React </ h1 > ); } The flow: index.html | ↓ main.tsx | ↓ <App /> | ↓ React creates UI | ↓ Browser displays content This is called the initial render . What Causes a Re-render? A component re-renders when: 1. State Changes Example: const [ count , setCount ] = useState ( 0 ); setCount ( 1 ); When state changes: State Update | ↓ Component Re-renders | ↓ UI Updates 2. Props Change Example: < User name = "Siva" /> If the parent changes: < User name = "John" /> The child component receives new props and re-renders. 3. Parent Component Re-renders When a parent component renders, React also re-renders its children by default. Example: function Parent () { return ( <> < Child /> </> ); } If Parent updates, Child also gets rendered again. Later, we will learn how React.memo can prevent unnecessary child re

Welcome back to the React Mastery Series . In Day 1, we introduced the roadmap of this series and discussed what we will cover — from React fundamentals to enterprise-level architecture. Today, we will start with the most important question: What is React, and why was it created? What is React? React is an open-source JavaScript library for building user interfaces , especially single-page applications (SPAs). It was created by engineers at Meta (Facebook) and was initially released in 2013. React focuses on one core idea: Build complex user interfaces by breaking them into small, reusable components. Instead of creating a complete application as one large piece of code, React encourages developers to divide the UI into independent and manageable components. Example: A banking application dashboard can be divided into: Dashboard │ ├── Header │ ├── AccountSummary │ ├── TransactionList │ ├── TransferMoneyForm │ └── Notifications Each part can be developed, tested, and maintained independently. Why Was React Created? Before React, developers commonly used traditional JavaScript and libraries like jQuery to update web pages. For small applications, this approach worked well. But as applications became larger, several challenges appeared. 1. Managing Complex UI Updates Imagine a banking application where: Account balance changes Transactions are updated Notifications appear User profile information changes With traditional DOM manipulation, developers had to manually find elements and update them. Example: document . getElementById ( " balance " ). innerHTML = " $5000 " ; As the application grew, managing thousands of DOM updates became difficult. React introduced a different approach: Describe what the UI should look like, and React manages the updates. The Problem With Direct DOM Manipulation The browser provides the Document Object Model (DOM), which represents the HTML structure. Example: HTML | DOM Tree | Browser Rendering When we update the DOM frequently: Browser

Hello Dev Community! 👋 It is officially Day 166 of my full-stack engineering track! Today, I designed and implemented the active messaging canvas component ( ChatContainer.jsx ) for my messaging app, QuickChat ! 💬📷⚡ Focusing on dynamic chat alignment, text bubble rendering, image attachments, and input controls was today's core milestone. Here is how I structured the component. 🛠️ Technical Breakdown: ChatContainer & Attachment Pipeline As captured in my UI and VS Code setup ( Screenshots ): 1. Dynamic Alignment & Sender Detection Conditioned flexbox directions based on authentication state so sender messages lock to the right while recipient messages render on the left: javascript

React Hooks have revolutionized how we write React components, offering a powerful way to manage state and side effects directly within functional components. This paradigm shift has led to cleaner, more readable, and often more maintainable codebases by moving away from the complexities of class components. Why the Shift to Hooks? Before Hooks, managing stateful logic and side effects often meant relying on class components. This approach could introduce several challenges: understanding this binding, managing complex lifecycle methods across different phases of a component's life, and dealing with "wrapper hell" – deeply nested component structures resulting from Higher-Order Components (HOCs) and render props when trying to reuse logic. Hooks solve these problems by allowing developers to "hook into" React features directly from functional components. This makes logic reuse more straightforward and components inherently easier to understand and test. Essential React Hooks at a Glance Let's explore the core Hooks that form the backbone of modern React development: 1. useState : Adding State to Functional Components The useState Hook is the most fundamental. It allows you to declare state variables in functional components. Instead of dealing with this.state and a separate this.setState() method, useState provides a direct variable for your state and a dedicated function to update it. This simplifies local component state management significantly, making it more intuitive and less prone to errors. 2. useEffect : Handling Side Effects The useEffect Hook is designed for performing side effects in functional components. Side effects encompass operations like data fetching from an API, setting up event listeners or subscriptions, or directly manipulating the DOM. This Hook consolidates logic that was previously spread across multiple lifecycle methods like componentDidMount , componentDidUpdate , and componentWillUnmount in class components. A key aspect of useEffect i

Project Overview The project is a React-based web application that fetches data from a REST API and displays it in a dynamic dashboard. Users can navigate between pages, search data, and interact with multiple components that rely on asynchronous API calls. While testing the application, I noticed that navigating away from a page during an active API request occasionally caused React warnings and unnecessary memory usage. This issue affected the application's stability and could lead to performance degradation over time. The problem was caused by an asynchronous operation continuing even after the component had been unmounted. For example, an API request initiated inside useEffect would still complete after the user navigated away, attempting to update the component's state. React would warn that a state update was attempted on an unmounted component. Before useEffect(() => { fetch("/api/users") .then((res) => res.json()) .then((data) => setUsers(data)); }, []); If the component unmounted before the request finished, the callback still attempted to update the state. After I solved the issue by using the AbortController API to cancel the request during cleanup. useEffect(() => { const controller = new AbortController(); fetch("/api/users", { signal: controller.signal, }) .then((res) => res.json()) .then((data) => setUsers(data)) .catch((err) => { if (err.name !== "AbortError") { console.error(err); } }); return () => controller.abort(); }, []); This ensures that pending requests are cancelled when the component unmounts, preventing unnecessary state updates and avoiding memory leaks. Code Prince3963 (Patel Prince) / Repositories · GitHub Prince3963 has 48 repositories available. Follow their code on GitHub. github.com My Improvements This fix focused on improving both performance and application reliability. What I improved Prevented memory leaks caused by unfinished asynchronous requests. Added proper cleanup logic inside useEffect. Eliminated React warnings about u

This is an English translation of my original article on Qiita . An Android build failed in an Expo SDK 54 app. The project still used Expo SDK 54, but several Expo packages had been upgraded to versions intended for SDK 55. TypeScript checks passed, and the development server ran normally. I did not catch the mismatch until EAS Build reached the native build step. What the dependency list looked like The relevant part of package.json looked like this: { "dependencies" : { "expo" : "~54.0.33" , "expo-apple-authentication" : "~55.0.13" , "expo-dev-client" : "^55.0.27" , "expo-image-picker" : "^55.0.18" , "expo-linking" : "^55.0.12" , "expo-notifications" : "^55.0.19" , "expo-splash-screen" : "^55.0.18" } } The expo package was still on version 54, while several related packages were on version 55. This happened because those packages had been installed individually using their latest versions. The package version does not always match the Expo SDK number. For example, Expo SDK 54 uses expo-notifications 0.32 and expo-splash-screen 31. Looking only at major version numbers is not enough to determine SDK compatibility. Start with expo install --check Expo CLI can compare the installed packages with the versions expected by the current SDK: npx expo install --check It can also return the result as JSON: npx expo install --check --json This is more reliable than trying to infer compatibility from package.json manually. Expo CLI can fix the versions automatically: npx expo install --fix npx expo-doctor I wanted to review each change, so I used the reported versions to update package.json myself. The versions I changed These were the main corrections: - "expo-apple-authentication": "~55.0.13" + "expo-apple-authentication": "~8.0.8" - "expo-dev-client": "^55.0.27" + "expo-dev-client": "~6.0.21" - "expo-image-picker": "^55.0.18" + "expo-image-picker": "~17.0.11" - "expo-linking": "^55.0.12" + "expo-linking": "~8.0.12" - "expo-notifications": "^55.0.19" + "expo-notifications"

JDK 24 removed the monitor-related carrier-thread pinning that stalled Netflix and similar teams on Java 21. What has replaced it on JDK 25 LTS is downstream-resource saturation: The bottleneck moved and now demands explicit bounding in application code. This article maps the failure modes that surface after virtual-thread adoption and gives a practical sequence backed by a public benchmark. By Sandeep Bharadwaj

JavaScript vs React: Understanding How They Work Together If you're starting web development, you've probably heard about JavaScript and React. Many beginners think they are competitors, but they actually work together. Let's understand them in simple terms. What is JavaScript? JavaScript is a programming language used to make websites interactive. Without JavaScript, a website would mostly be static. JavaScript allows you to: Handle button clicks Validate forms Create animations Fetch data from APIs Update content without refreshing the page Example: document . getElementById ( " btn " ). addEventListener ( " click " , () => { alert ( " Hello World! " ); }); JavaScript is the foundation of modern web development. What is React? React is a JavaScript library created by Meta Platforms for building user interfaces. Instead of manipulating the webpage manually, React helps developers create reusable UI components. Example: function Welcome () { return < h1 > Hello World! </ h1 >; } React uses JavaScript to create dynamic and interactive user interfaces more efficiently. Simple Analogy Think of building a house: JavaScript = The tools and materials (bricks, cement, wood) React = A construction framework that helps you build the house faster and more efficiently You need JavaScript to use React. Key Differences Feature JavaScript React Type Programming Language JavaScript Library Purpose Adds logic and interactivity Builds UI components Learning Curve Easier to start Requires JavaScript knowledge Usage Works everywhere Used mainly for frontend applications Created By Netscape Meta (Facebook) DOM Updates Manual Virtual DOM for optimized updates Why React Became Popular As applications grew larger, managing UI with plain JavaScript became difficult. React solves this by providing: Component-based architecture Reusable code Better state management Faster UI updates with Virtual DOM Large ecosystem and community support This makes React ideal for building modern applications

Every year, thousands of people struggle to find blood donors during emergencies. I wanted to build something that could simplify that process while improving my full-stack development skills. So I built a Blood Donation Management System using the MERN Stack. The goal was simple: create a platform where donors, recipients, and volunteers can connect efficiently through a modern web application. In this article, I'll share the architecture, key features, and the lessons I learned while building it. Tech Stack : Frontend React.js React Router Tailwind CSS Axios Backend Node.js Express.js Database MongoDB Mongoose Authentication JWT bcrypt Deployment Vercel (Frontend) Render (Backend) The Problem Finding blood donors during emergencies is often difficult because information is scattered across social media and messaging apps. I wanted to build a centralized platform where users could: Register as blood donors Search donors by blood group and location Request blood Manage donation information Keep donor data organized 🏗️Project Architecture Client (React) │ REST API │ Node.js + Express │ ├── Authentication ├── Donor Management ├── Blood Requests ├── User Dashboard └── Admin Panel │ MongoDB Keeping the frontend and backend separated made the project easier to maintain and scale. Key Features Secure user authentication Role-based dashboard Blood donor registration Search donors by blood group Blood request management Responsive UI Protected routes RESTful API Project Structure client/ ├── components/ ├── pages/ ├── hooks/ ├── layouts/ └── routes/ server/ ├── controllers/ ├── middleware/ ├── models/ ├── routes/ ├── utils/ └── config/ Organizing the project into separate folders helped keep the codebase clean and easier to extend. Authentication Flow Authentication was implemented using JWT and bcrypt. The basic flow looks like this: Register ↓ Password Hashing ↓ MongoDB ↓ Login ↓ JWT Token ↓ Protected Routes This keeps user data secure while allowing authenticated access