标签：#React

If you've ever tried to build a trading dashboard, a crypto portfolio tracker, or any financial app, you probably ran into the "charting problem" pretty quickly. The standard industry approach goes something like this: Embed a heavy <iframe> from a 3rd party provider. Realize it doesn't quite match your app's UI/theme. Struggle with limited postMessage APIs to push real-time data. Watch the UI lag when you try to render multiple charts on the same page. I got tired of fighting with iframe embeds and DOM-based SVG charts that couldn't handle thousands of real-time ticks. I needed something native, fast, and entirely under my control. So, I built one. And today, I'm fully open-sourcing the core engine. Meet Exeria Charts Exeria Charts is a source-available, high-performance financial charting library designed for self-hosted web applications. Instead of embedding external widgets, Exeria renders directly inside your application using a highly optimized Canvas architecture. Here’s a quick look at what it can do: https://exeria.dev The Tech Constraints (Why build another charting lib?) Building a financial chart isn't just about drawing boxes and lines. It’s about performance under pressure. When designing the architecture, we had a few strict requirements: Zero iframes: It had to be a native JavaScript/React module that lives in the main DOM tree, styled perfectly to match the host application. High-frequency updates: Crypto and forex markets move fast. The library needed to handle sub-millisecond tick updates without dropping frames or blocking the main UI thread. Unified runtime: I didn't want a separate library for line charts, another for candlesticks, and another for volume histograms. We needed one engine that could switch views instantly. How to use it We designed the API to be as straightforward as possible. Here is what a vanilla JS implementation looks like: import { createChart } from " @efixdata/exeria-chart " ; // 1. Grab your container const container = d

Hi everyone 👋 I'm a Full Stack Developer with experience in JavaScript, React.js, Next.js, Node.js, Express.js, MongoDB, and WordPress development. Over the last few years, I have worked on multiple projects ranging from company websites to full-stack web applications. In this article, I want to share my experience transitioning from the traditional MERN stack to Next.js and why it has become my preferred framework for modern web development. Why I Started with MERN Stack The MERN stack was my first choice because it allowed me to build complete applications using JavaScript. Technologies MongoDB Express.js React.js Node.js Benefits ✅ Single language across frontend and backend ✅ Huge ecosystem ✅ Fast development ✅ Easy API integration Challenges I Faced As projects became larger, I started facing issues like: SEO limitations Performance optimization Routing complexity Code organization Server-side rendering requirements This is where Next.js entered the picture. Why I Switched to Next.js Next.js provides several powerful features out of the box. Server-Side Rendering (SSR) Pages can be rendered on the server which improves SEO and initial page load performance. 2.** Static Site Generation (SSG)** Perfect for blogs, landing pages, and marketing websites. 3.** App Router** The new App Router makes routing cleaner and more scalable. Server Components Less JavaScript is sent to the browser, improving performance. Better Developer Experience Features like: File-based routing Built-in image optimization Middleware API routes make development faster and cleaner. My Current Tech Stack Frontend Next.js React.js TypeScript Tailwind CSS Backend Node.js Express.js MongoDB Tools Git & GitHub Postman Vercel Contentful CMS What I Learned The biggest lesson I learned is: Focus on solving real business problems instead of chasing every new technology. Frameworks will change, but understanding JavaScript fundamentals, APIs, databases, authentication, and system design will always be

Expo SDK 56 ships with a custom Kotlin compiler plugin that eliminates reflection from Expo Modules on Android. The result: 70% faster module initialization and a 30% reduction in time to first render. The plugin runs during compilation, so app developers get these performance gains automatically without changing any code. Module authors can unlock even bigger wins with a single annotation. This post walks through how we built it and why this approach succeeded where previous attempts failed. For the Swift side where we now talk to JSI directly, check out our companion post Talking to JSI in Swift . The reflection problem we inherited Before Expo Modules, we had Unimodules. They worked like old React Native bridge modules: you'd sprinkle annotations across methods you wanted to expose, and the runtime would discover everything through reflection. class ClipboardModule ( context : Context ) : ExportedModule ( context ) { override fun getName () = "ExpoClipboard" @ExpoMethod fun getStringAsync ( promise : Promise ) { val clip = clipboardManager . primaryClip ?. getItemAt ( 0 ) promise . resolve ( clip ?. text ?. toString () ?: "" ) } @ExpoMethod fun setStringAsync ( content : String , promise : Promise ) { clipboardManager . setPrimaryClip ( ClipData . newPlainText ( null , content )) promise . resolve ( true ) } } Reflection made sense when we needed metadata about our own code. What methods does this module export? What arguments do they accept? The JVM could answer those questions. But reflection costs time, and on Android that time comes straight out of your startup budget. Every module the runtime introspects adds milliseconds before users see your app. Building the Expo Modules API gave us a chance to fix this. We wanted better ergonomics and less reflection. The Kotlin DSL delivered both in one move, removing most reflection while making modules easier to write. But we couldn't eliminate all of it. Type information for function arguments and Record properties s

How we built a medicine-substitution engine that refuses to be clever There is a category of bugs where the code looks perfectly correct in code review, the unit tests pass, the demo on stage goes beautifully, and a real person dies. Medicine substitution is one of them. We built Agada — point a phone camera at a medicine strip in India, and the app tells you whether the drug is registered with the regulator, what it does, and whether a chemically identical version is available at the government pharmacy for a fraction of the price. The point is real: Indians spend about ₹65,000 crore a year out of pocket on branded medicines when the same molecule sits in a Jan Aushadhi Kendra at a tenth of the cost. The Dolo-650 story (₹32 vs ₹4.90 for the same paracetamol) is the most famous example, not the only one. The hard part isn't the camera, the OCR, or the price lookup. The hard part is the substitution engine — the piece of code that decides "is this salt the same as that salt." Get that wrong in the wrong direction, and the app cheerfully tells a user that their 500mg anti-epileptic can be replaced with a 200mg one, because the strings look similar. So we built a matcher that refuses to be clever. This post is about the parts we deleted. The starting problem A user scans "Crocin 500mg Tablet IP". A Jan Aushadhi record says "Paracetamol 500 mg". A naive matcher says: both contain "500", both contain "Paracetamol" (or "Acetaminophen", which is the same thing in a different country), ship it. The user buys the generic. Savings: ₹20. Everyone wins. Now consider: Crocin 650 Advance vs Dolo 650 — same molecule, same dose, different brands. Fine. Augmentin 625 vs Augmentin 375 — same two salts, different ratio. The combo tolerance might let it through, but the clinical implication is real. Levofloxacin 500 vs Ofloxacin 400 — both fluoroquinolones, both "similar," but levofloxacin is the levo-isomer of ofloxacin and is dosed at roughly half. A "fuzzy" match here could halve so

Prologue A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component. My last development article completed the base requirements for keyboard functionality within the component; attention now shifts to adding some of the last functionality required, closing sublists when the lists holding them now close and determining what happens when a closed component is entered via the keyboard through the Tab and Shift+Tab keys. Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 0.8.0 . Links in the article will take you to the proper file in the tagged GitHub Repository. Because the code for this release is scattered, line numbers are added to make it easier to locate in the linked GitHub file. Line numbers are also provided for those who would like to follow along with a downloaded copy. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component. You can view the requirements for the Focus and Refinement Support Release along with previous requirements. Content Links Introduction Acceptance Criteria Entering Closings Setting Up For Success Introduction The implementation of keyboard handling left one obvious keyboard issue to fix: an apparent keyboard trap that occurs when focus shifts into the component

android doze kills your background tasks and nobody explains why properly been building a react native app that schedules stuff to run later. worked fine every time i tested it. shipped it, and it started missing schedules. only when the phone had been sitting idle for a while. never on my desk. took me way too long to figure out what was going on so writing it up here. what happens you schedule something for 1am. check logs next morning: 01:00:00 alarm fired 01:00:02 connected (while back grounded, 2 seconds) 01:18:xx the actual send ran the connection came up fine. in 2 seconds. while the phone was back grounded. but the code that was supposed to do something with that connection ran 18 minutes later when something else woke the phone up. why doze mode freezes javascript timers. setTimeout, setInterval, any polling loop on the js thread-all frozen. but native events (connection callbacks, lifecycle events, native module bridges) keep firing. i had a setInterval checking "are we connected yet" every second. doze froze that loop. the connection came up, nobody noticed for 18 minutes because the thing checking for it was asleep. the phone could do the work. my code just couldn't tell. stuff i tried that didn't fix it foreground service — keeps the process alive but doesn't unfreeze js timers. not the problem. more setTimeout/setInterval variations, literally the thing causing it. spent two days making the problem worse. HeadlessJS dropped in without changes compiled, never ran on newer RN. lost a few hours there. the actual fix move everything off timers. put your work directly in the event handler. instead of polling to check if you're connected: js // this is frozen by doze. don't. setInterval (() => { if ( isReady ()) doWork () }, 1000 ) do this : jsconnection . on ( ' status ' , ( state ) => { if ( state === ' connected ' ) { doWork ( job ) } }) native events survive doze. timers don't. that's the whole thing. for waking up at the right time — native AlarmManager

I built a browser-based desktop environment (IP Linux) with React, TypeScript and Vite I have been working on a project called IP Linux : a browser-based desktop environment that runs as a static web app. Live site: https://ip-os-linux.vercel.app/ GitHub Repository: https://github.com/ikerperez12/IP-OS-LINUX It is not a real Linux distribution, and it does not run native binaries. The idea is different: I wanted to explore how far a polished desktop-like experience can go inside a normal browser tab. The result is a small web OS-style environment with: A splash / entry screen A desktop with icons, folders, and widgets A top panel with system controls A dock and app launcher Resizable and draggable windows Virtual workspaces Snap assist A global search / Spotlight-style command palette Local-first apps (Files, Terminal, settings, player) Reactive wallpapers Glass UI and visual effects Why I built it Most web demos are landing pages, dashboards, or small single-purpose apps. I wanted to build something that feels more like an environment. I was interested in questions like: Can a web app feel physical and desktop-like? How should windows behave inside a browser viewport? How far can local-first storage go before a backend is actually needed? How do you organize many small apps without making the UI messy? IP Linux became a way to test all of that in one project. The app includes a catalog of built-in apps and tools: Files, Terminal, Browser, Settings, App Store, Music Player, Matrix Rain, games, developer tools, productivity apps, and visual utilities. The virtual file system and user preferences are stored locally in the visitor's browser with IndexedDB/localStorage. There is no backend, no account system, and no required environment variables for the public release. Would love to get feedback on the interaction design, responsiveness, or features!

We've all been there: staring at a clunky, 10-year-old hospital web portal, clicking through endless nested menus just to book a simple check-up or download a PDF lab result. It's tedious, error-prone, and frankly, a waste of human potential. But what if you could just tell an AI, "Book me a dermatologist for next Tuesday and save my blood test results to my health folder," and it just... did it? In this tutorial, we are diving deep into the world of autonomous agents , GPT-4o , and LLM-driven web navigation . By leveraging the revolutionary Browser-use library and Playwright , we’ll build a vision-capable agent that can navigate complex UIs, handle logins, and automate the most frustrating parts of healthcare administration. 🚀 Why Traditional Scraping Fails (and Why Agents Win) Traditional automation tools like Selenium or Puppeteer rely on brittle DOM selectors ( #button-id-342 ). When a hospital updates its website, your script breaks. Using Browser-use with GPT-4o changes the game. Instead of looking for code, the agent sees the page like a human, understanding that a magnifying glass icon means "Search" regardless of the underlying HTML. The Architecture 🏗️ The system logic involves a feedback loop where the LLM perceives the browser state (screenshot + DOM tree), decides on an action, and executes it via Playwright. graph TD A[User Goal: Book Appointment/Download Report] --> B[LangChain Agent / Browser-use] B --> C{Decision Engine: GPT-4o} C --> D[Action: Click/Type/Scroll] D --> E[Playwright Browser Instance] E --> F[Hospital Portal UI] F --> G[Visual & HTML Feedback] G --> C F --> H[Download Lab Report PDF] H --> I[Structured Storage / RAG Pipeline] I --> J[Task Completed ✅] Prerequisites 🛠️ Before we start, ensure you have the following in your tech stack: Python 3.10+ Playwright (The backbone of browser control) Browser-use (The bridge between LLMs and browsers) OpenAI API Key (We'll use GPT-4o for its superior vision capabilities) pip install browser-use

When a Magento store feels slow, merchants usually notice it first on the homepage. When revenue actually slips, we usually find the damage deeper in the funnel. That was the case on a recent mid-market Magento 2 build we inherited. Product pages were acceptable. Search worked. But checkout analytics told a different story. Mobile users were stalling after address entry, re-clicking shipping methods, and abandoning before payment finished rendering. The merchant described it in business terms: "traffic is fine, but checkout feels fragile." They were right. The store was running a fairly typical Magento checkout stack: Luma fallback checkout, several shipping customizations, two payment methods, tax recalculation on step changes, and a handful of third-party scripts that had quietly accumulated over time. Together, they created a familiar Magento problem: too much JavaScript, too many render passes, and too much waiting on the highest-stakes route in the store. Over a 90-day measurement window after launch, checkout completion improved by 34%. Mobile completion improved by 39%. Lab metrics got much better immediately, and field metrics followed. This article covers why we chose React instead of Hyva Checkout, how we implemented the frontend, what moved the numbers, and what we would do differently next time. The problem with Magento's default checkout Magento's default Luma checkout is functional, but performance is rarely its strength. The architecture was designed around Knockout.js components, RequireJS modules, and a lot of UI behavior being layered in over time. Once a real merchant adds shipping estimation, fraud tooling, tax logic, payment widgets, analytics, and address validation, the route becomes busy in all the wrong ways. In this project, our baseline looked like this on a throttled mobile profile: Metric Before (Luma checkout) After (React checkout) Initial checkout route payload 1.8 MB transferred 486 KB transferred LCP 4.2s 1.1s INP 280ms 92ms CLS 0.1

Magento's default Luma checkout loads a heavy Knockout.js stack, dozens of RequireJS modules, and payment iframes that fight for the main thread. For merchants where checkout is the conversion bottleneck, shaving seconds off load and interaction time pays back faster than another homepage hero image. We rebuilt checkout in React— React Checkout Pro —for Magento 2 and Hyvä stores that needed Shopify-like speed without leaving Adobe Commerce. Here is what we measured, what surprised us, and what we would do differently. The problem: checkout is where Core Web Vitals go to die Homepage optimizations are table stakes. Checkout is different: More JavaScript. Payment methods, validators, shipping step observers, and third-party scripts stack on one route. More layout shift. Address suggestions, shipping method lists, and tax updates re-render large DOM regions. More input delay. Autocomplete plugins, reCAPTCHA, and BNPL widgets compete on keydown handlers. On a representative Luma checkout (mid-size US retailer, ~80 SKUs in catalog, 4 payment methods), lab tests before migration showed: Metric Luma checkout (before) React checkout (after) LCP (lab, 4G) 4.8s 2.1s INP (field interaction) 320ms 95ms CLS (full flow) 0.18 0.04 JS transferred (checkout route) ~1.9 MB ~420 KB Time to interactive (est.) 6.2s 2.8s Field data from CrUX lagged lab wins by 4–6 weeks but trended the same direction once cache and CDN rules settled. Your numbers will differ. The pattern we see repeatedly: the biggest win is shipping less JavaScript to checkout , not micro-optimizing the JavaScript you keep. Architecture: React island, Magento brain We did not headless the entire storefront. Magento still owns: Quote totals and tax calculation Shipping rate requests Payment tokenization and order placement APIs Customer session and cart persistence React owns the UI layer: step navigation, form state, validation UX, and optimistic updates while Magento APIs catch up. High-level flow: Browser → React Chec

How treating modals as typed async operations eliminates boolean state, callback chains, and runtime surprises in React apps. React applications often treat modals as UI details. A boolean flag. A conditional render. An onClose callback. That works fine for one dialog. But real products have modals that are actually business flows: confirm this destructive action rename this entity and return the new name pick a date range and apply it resolve a conflict before continuing complete a wizard step before the next one unlocks These flows need more than a boolean. They need typed input, typed output, and a way to await the result — just like any other async operation in your app. const result = await modal . open ( renameReportModal , { reportId : report . id , currentName : report . name , }); if ( result . status === " renamed " ) { await renameReport ({ id : report . id , name : result . name }); } That is the idea behind: npm install @okyrychenko-dev/react-modal-manager zustand A modal lifecycle manager. Not a component. Not a design system. A typed async contract between your app logic and your dialog UI. The problem with traditional modal state In most React apps, modal state starts locally: function ReportsPage () { const [ isRenameOpen , setIsRenameOpen ] = useState ( false ); return ( <> < button onClick = { () => setIsRenameOpen ( true ) } > Rename </ button > { isRenameOpen && ( < RenameModal onClose = { () => setIsRenameOpen ( false ) } /> ) } </> ); } And then real requirements arrive: const [ isRenameOpen , setIsRenameOpen ] = useState ( false ); const [ isDeleteOpen , setIsDeleteOpen ] = useState ( false ); const [ isShareOpen , setIsShareOpen ] = useState ( false ); const [ renameTarget , setRenameTarget ] = useState < Report | null > ( null ); const [ deleteTarget , setDeleteTarget ] = useState < Report | null > ( null ); const [ shareTarget , setShareTarget ] = useState < Report | null > ( null ); The UI is not the problem. The orchestration is: Where d

Every few months, a post goes viral: "Please stop using [perfectly good tool]." This time it's lucide-react. And honestly? The take is lazy What's the actual problem? Nothing. The library is actively maintained, tree-shakable, TypeScript-friendly, and has 1000+ consistent icons. A new icon library dropped? Cool. That doesn't make this one broken. Tools don't expire — context does Before switching anything in production, ask: Is it maintained? ✅ Does it solve my problem? ✅ Is my team comfortable with it? ✅ Then keep using it. Real usage — still clean in 2026 import { Search , Bell , User } from ' lucide-react ' ; export default function Navbar () { return ( < nav > < Search size = { 20 } /> < Bell size = { 20 } strokeWidth = { 1.5 } /> < User size = { 20 } color = "#6366f1" /> </ nav > ); } Tree-shaking works perfectly — only Search, Bell, and User are bundled. Not the entire library. When you should switch Unpatched security vulnerability Repo abandoned for 2+ years Bundle size issue you've actually measured If none of these apply, you're switching for hype, not logic. The real issue "Please stop using X" posts get engagement. Developers see them, second-guess stable choices, and waste hours migrating things that weren't broken. Don't let LinkedIn trends drive your architecture. Build products. Not migrations.

Tags: react , webdev , onnx , audio Introduction Music generation, vocal separation, and intelligent arrangement have traditionally been server-side tasks requiring complex pipelines and expensive GPU clusters. But what if we could bring the entire interactive music-creation experience—both real-time preview , offline export , prompt-based AI music generation , and local Karaoke processing —directly into the browser? In this post, I'll share how I built AI Groove Pad , a client-side React and Tone.js application featuring: A Prompt-to-Music AI Agent: Enter any prompt (e.g., "Create an energetic Tamil Kuthu beat with a driving bassline and a Nadaswaram melody" ), and the agent composes and adds the tracks directly to the arrangement. A Client-Side Karaoke Separator: Runs a local neural network with 84% accuracy using ONNX Runtime Web to separate vocals and accompaniment locally. 3. High-Performance Audio Engine: Tone.js scheduling, synth fallbacks, and real-time playback. The Tech Stack Frontend UI: React + TypeScript + Tailwind CSS for a premium, glassmorphic dark-mode interface. Audio Engine: Tone.js v15 (built on top of the Web Audio API) for sample playback, precise timing scheduling, and synthesis. Client-Side AI: ONNX Runtime Web ( onnxruntime-web ) executing a local neural network with 84% accuracy for vocal/accompaniment separation (Karaoke mode). AI Music Agent: A natural language agent interface that takes user prompts to compose midi sequences, beats, harmony, and arrangements in real-time. * Offline Rendering: OfflineAudioContext for high-speed, non-realtime rendering of arrangements straight to .wav files. 🤖 The Prompt-to-Music AI Agent With AI Groove Pad , users don't need to be music theory experts. They simply write what they want to hear. The AI Agent interprets the prompt and generates a multi-track composition containing: Groove & Beats: Automatically maps drum samples and rhythmic patterns (e.g. Parai drum, Pambai hits for Kuthu). Melody & Harmony

Modern teams expect software to update instantly. Nobody wants to refresh a page every few seconds to see whether a task has moved from "In Progress" to "Done." Applications like Trello, Jira, and Linear have trained users to expect real-time collaboration. In this tutorial, we'll build a simplified real-time Kanban board using React, TypeScript, and WebSockets. Along the way, we'll cover project structure, state management, optimistic UI updates, and handling concurrent changes from multiple users. What We're Building Our application will support: Creating tasks Drag-and-drop task movement Real-time synchronization between users Optimistic updates Type-safe frontend architecture Tech Stack Frontend React TypeScript Vite React DnD Zustand Backend Node.js Express Socket.IO Database PostgreSQL Why WebSockets Instead of Polling? Many developers start with polling: setInterval (() => { fetch ( " /tasks " ); }, 5000 ); This works, but it's inefficient. Problems include: Unnecessary network requests Delayed updates Increased server load Poor user experience WebSockets maintain a persistent connection between client and server. Instead of asking: "Any updates yet?" the server simply says: "Here's an update." The result is lower latency and fewer network requests. Project Structure A scalable React project should avoid putting everything into a single components folder. Here's a structure that works well: src/ ├── api/ ├── components/ ├── features/ │ ├── board/ │ ├── columns/ │ └── tasks/ ├── hooks/ ├── store/ ├── services/ ├── types/ └── utils/ This feature-based organization scales much better than organizing solely by file type. Setting Up React Create the project: npm create vite@latest kanban-board cd kanban-board npm install Install dependencies: npm install zustand socket.io-client react-dnd react-dnd-html5-backend Defining Task Types Type safety becomes increasingly valuable as applications grow. export interface Task { id : string ; title : string ; description : s

If you’ve been learning React for a while, you’ve probably come across hooks that help optimize your application such as useMemo() and useCallback() and might have wondered: "Do I really need these hooks?", "Where are they useful?" etc. In React 19, the React Compiler was introduced and it's work is to help you optimize your application automatically. This raises a question where if React can automatically optimize an application, why should I bother learning how to optimize my app manually with hooks like useMemo() ?. Let me break down why you would still need to do manual optimization and what the React Compiler was created to solve in a simple, beginner friendly way. What Is the React Compiler? The React Compiler is a new optimization tool developed by the React Team. It's goal is simple: Automatically make your React app faster without you writing extra optimization code. Traditionally, React re-renders a component each time the state changes. This is usually fine, but if you have a component that does a lot of work, this can make your app very slow during re-renders. The React Compiler steps in to: Detect unnecessary re-calculations Memoize values and functions automatically Prevent avoidable re-renders So instead of you writing: const filteredItems = useMemo (() => filterItems ( items ), [ items ]); The compiler handles it for you behind the scenes. Why is this such a big deal? This changes how we write code in React, it helps us avoid over-optimizing our code when it might not need any optimization. Most developers that learn about useCallback() or useMemo() tend to overuse them (guilty party here 😅), resulting in the application behaving much slower instead of faster, hence the need for the React compiler as it optimizes the code where necessary. The React Compiler also provides the following benefits: 1. Less boilerplate code You don’t have to wrap your optimization logic in useMemo() or useCallback() . 2. Fewer mistakes Manual memoization is easy to get wr

You've built todo apps, counters, and forms. But can you handle a grid of 50 cells that reference each other through formulas? This challenge pushes your state management skills into real spreadsheet territory — formula evaluation, two-way cell bindings, and an interface that juggles editing, selection, and keyboard shortcuts all at once. 🔥 Start the Challenge Now 🧩 Overview Build a spreadsheet with real-time formula evaluation. You'll wire up a 10-row × 5-column grid where cells support basic values and Excel-style formulas (like =A1+B2), column and row selection, and a formula bar that mirrors what you're typing. ✅ Requirements Render a spreadsheet with column headers A through E and rows 1 through 10 Each cell uses an <output> element for the computed value and an <input> overlaid for editing Click a cell to edit; press Enter or blur to commit the change Formulas starting with = must be evaluated: Arithmetic: =1+1 → 2 Cell references: A1= 5 and B1= =A1+3 → 8 Click a column header to select/deselect that column Click a row number to select/deselect that row Selecting a column deselects any row and vice-versa Backspace clears the selected column or row Click outside the table deselects everything A formula bar ( fx ) mirrors the editing cell's value Cells must start empty — no default values 💡 Notes Use useState for cells, selected column, and selected row. No need for useReducer here. Each cell uses two overlapping layers: a visible <output> for the computed value and an invisible <input> for the raw formula. Toggle with opacity-0 / opacity-100 so the input stays mounted. Evaluate formulas with eval : generate JS const declarations from all cell values, wrap them in an IIFE, and evaluate. Recompute every cell on any change — cells can reference each other. 🧪 Tests renders the app title renders the spreadsheet with column headers A-E and rows 1-10 renders cells with initial empty values allows editing a cell and displays the new computed value evaluates a simple fo

Originally published on clintech.me If you've integrated Google Maps into a React app and seen Autocomplete randomly stop working, Directions silently fail, or the API throw google is not defined on second render — you've hit the duplicate loading bug. Here's exactly what caused it in my case and how I fixed it. The setup that broke things While building delivery address flows at POLOM — a production e-commerce platform — I integrated Google Places Autocomplete across 20+ screens. I had the Maps JavaScript API loading in two places: A provider.tsx for global script loading across the app A useLoadGoogleMaps hook inside a shared component This caused race conditions. The Autocomplete and Directions APIs were initialising before the script fully resolved in some renders, silently failing in others. The failure wasn't consistent, which made it harder to catch. The fix Step 1 — Remove the global load Delete the script tag or next/script call in provider.tsx . There should be exactly one place the Maps API loads. Step 2 — Centralise in a hook Move all loading logic into a single useLoadGoogleMaps hook using dynamic loading. If you're on Next.js, next/script with strategy="afterInteractive" inside the hook is the right approach. Step 3 — Guard before initialising if ( ! window . google ?. maps ) return ; Check that the API is fully available before attempting to attach Autocomplete or Directions . Don't assume the script load event means every namespace is ready. Step 4 — Scope your ref correctly Bind the autocomplete instance to inputRef.current explicitly. If the component remounts, re-initialise the binding — don't assume the previous instance is still attached. The result One load, one source of truth, no race conditions. Autocomplete and Directions worked consistently across all 20+ screens without reinitialising on every render. Security — the step most developers skip Restrict your API key at the Google Cloud Console level: HTTP referrers: whitelist your domain onl

A complete walkthrough of publishing Cartlify — a React e-commerce UI kit — to npm for the first time. The Milestone Yesterday I published Cartlify to npm. npm install cartlify It sounds simple. But getting to that one line took more decisions, more configuration, and more trial and error than I expected. This article covers everything — from setting up the build config to the actual publish command — so you don't have to figure it out the hard way. What Is Cartlify? Cartlify is a production-ready React + TypeScript + Tailwind CSS component library focused on e-commerce UI. 4 components that every e-commerce project needs: ProductCard — 3 layout variants, image gallery, wishlist, sale badges, skeleton loading CartDrawer — animated slide-in, focus trap, ESC dismiss, quantity stepper CheckoutStepper — horizontal/vertical, animated connectors, keyboard navigation PageLoader — 4 animation styles, 3 position modes Plus 3 utility hooks, 11 tree-shakeable icons, 40+ CSS design tokens, full dark mode, and 141 Jest + React Testing Library tests. Built so freelance developers and indie makers can skip the painful e-commerce UI layer and ship faster. Why Publish to npm? Before npm, Cartlify was only available on Gumroad as a paid download. That's fine — but npm adds something Gumroad can't: Developer sees Cartlify → runs npm install cartlify → evaluates the compiled output → trusts the quality → buys the full source on Gumroad npm is a credibility and discovery channel — not just a distribution method. A package on npm signals that something is real, maintained, and production-ready. Also: npmjs.com gets millions of developer searches every month. That's free traffic you can't get from Gumroad alone. The Build Setup — tsup The most important decision before publishing is how you bundle your library. I chose tsup — a zero-config TypeScript bundler built on esbuild. Here's why: Tool Config needed Speed Output Rollup Lots Medium ESM + CJS Webpack Heavy Slow CJS only Vite lib mode

This is an updated rewrite of my 2021 article on protected routes . A lot has changed in the React ecosystem since then. React Router moved from v5 to v7, class components have faded out, and the patterns we use for authentication state have matured. This version reflects how protected routes are built in modern React applications. Almost every web application requires some form of authentication to prevent unauthorized users from accessing parts of the application meant for signed-in users only. In this tutorial, I'll show how to set up an authentication flow and protect routes from unauthorized access using modern React patterns: function components, hooks, React Router v6+, and the Context API. First things first Install the dependency: npm i react-router-dom That's it. React Router v6 and above ships as a single package, so you no longer need to install react-router and react-router-dom separately. It is worthy of note that we will not be using Redux for authentication state in this version. For something as simple as "is the user logged in?", React's built-in Context API is the standard approach today. Redux still has its place, but it is overkill here. The Auth Context Instead of writing to localStorage directly from components and reading it in random places, we centralize authentication state in a context. This gives us a single source of truth and a clean useAuth() hook we can call anywhere in the app. Create ./src/auth/AuthContext.jsx : import { createContext , useContext , useState } from " react " ; const AuthContext = createContext ( null ); export function AuthProvider ({ children }) { const [ user , setUser ] = useState (() => { // Rehydrate on page refresh const saved = localStorage . getItem ( " user " ); return saved ? JSON . parse ( saved ) : null ; }); const login = async ( username , password ) => { // In a real app, this is an API call to your backend. // We simulate it here with hardcoded credentials. if ( username . toLowerCase () === " admin

TL;DR: Create React App builds bake environment variables at build time. ConfigMaps let you inject runtime configs into your container. Here’s how to bridge them so the same Docker image works across dev, staging, and production. The Problem You’ve built a React app with Create React App (CRA), Vite, or Next.js. You use .env files: js // api.js const API_URL = process.env.REACT_APP_API_URL; You build your Docker image: dockerfile FROM node:18 AS builder COPY . . RUN npm run build # REACT_APP_API_URL gets baked here FROM nginx:alpine COPY --from=builder /build /usr/share/nginx/html Then you deploy to Kubernetes. But now you want different API URLs for staging vs production. You could rebuild the image for each environment (bad – slow, wasteful). Or you could use a ConfigMap to inject values at runtime. ConfigMap to the Rescue A ConfigMap stores key-value pairs. Kubernetes can mount it as a file inside your pod. But React runs in the browser, not in the container’s filesystem. So how does the browser read a file from a ConfigMap? Simple: You serve a dynamic env-config.js file from your web server. Step-by-Step Solution Create a ConfigMap with your environment variables yaml # configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: react-env-config data: env-config.js: | window.__env = { REACT_APP_API_URL: " https://api.production.com ", REACT_APP_FEATURE_FLAG: "true" }; Apply it: bash kubectl apply -f configmap.yaml Modify your React app to read from window.__env Instead of reading process.env directly, use a runtime config: js // config.js export function getEnvVar(name) { // Runtime injection from window. env (provided by ConfigMap) if (window. env && window. env[name] !== undefined) { return window. env[name]; } // Fallback to build-time env vars (for local dev) return process.env[name]; } Use it in your components: js // api.js import { getEnvVar } from './config'; const API_URL = getEnvVar('REACT_APP_API_URL'); Serve the ConfigMap file via your web server U