Mastering React Fundamentals with Code Examples

React Components: Functional vs Class (With Lifecycle Explained)  In React, components are the core building blocks of any application.    There are two main types:  - Functional Components  - Class Components  * Functional Components:  Functional components are simple JavaScript functions that return JSX.  Key Features:  - Cleaner and shorter syntax  - Use Hooks (useState, useEffect)  - Preferred in modern React  - Easier to test and maintain    Example:  import React, { useState, useEffect } from "react";     function Counter() {    const [count, setCount] = useState(0);     useEffect(() => {       console.log("Component Mounted or Updated");      return () => {         console.log("Component Unmounted");      };    }, [count]);       return (      <div>        <p>Count: {count}</p>        <button onClick={() => setCount(count + 1)}>Increment</button>      </div>    );  }  Lifecycle in Functional Components (Using Hooks)  Functional components handle lifecycle using the useEffect Hook.    * Class Components:  Class components are ES6 classes that extend React.Component.  Key Features:  - Use this.state  - Have built-in lifecycle methods  - More boilerplate  Example:  import React, { Component } from "react";  class Counter extends Component {    constructor(props) {      super(props);       this.state = { count: 0 };    }        componentDidMount() {      console.log("Mounted");    }        componentDidUpdate() {      console.log("Updated");   }        componentWillUnmount() {      console.log("Unmounted");    }        render() {      return (        <div>          <p>Count: {this.state.count}</p>          <button onClick={() => this.setState({ count: this.state.count + 1 })}>           Increment          </button>        </div>      );    }  }    Lifecycle in Class Components:  Mount:  componentDidMount()  Update: componentDidUpdate()  Unmount: componentWillUnmount()    Today, Functional Components + Hooks = Standard Practice in React.  Class components are still supported, but mostly used in older projects.  Which lifecycle approach do you find easier — Hooks or Class methods?  #React #FrontendDevelopment #WebDevelopment #JavaScript #Programming #DeepDivine

🚀 React 19: RIP forwardRef! If you’ve ever struggled with the awkward syntax of forwardRef, I have great news. React 19 has officially simplified how we handle Refs. Now, ref is just a standard prop. No more wrapping your components in Higher-Order Components just to access a DOM node. 🛑 The "Old" Way (React 18) You had to wrap your entire component, which messed up your component definition and made TypeScript types a nightmare to write. JavaScript // Complex and boilerplate-heavy const MyInput = forwardRef((props, ref) => { return <input {...props} ref={ref} />; }); ✨ The React 19 Way (Clean & Simple) Just destructure ref from your props like any other value. It’s cleaner, more readable, and much more intuitive. JavaScript // Just a normal functional component! function MyInput({ label, ref }) { return ( <label> {label} <input ref={ref} /> </label> ); } 📊 Quick Comparison: Why this matters FeatureReact 18 (Old)React 19 (New)Passing RefsforwardRef((props, ref) => ...)Standard prop: ({ ref }) => ...DXHigh friction / boilerplateZero friction / NaturalTypeScriptforwardRef<HTMLButtonElement, Props>interface Props { ref: Ref<HTMLButtonElement> }🔥 Bonus Feature: Ref Cleanup Functions React 19 also solved a long-standing issue with third-party libraries (like D3, Google Maps, or Canvas). You can now return a cleanup function directly from a ref callback! JavaScript <div ref={(node) => { if (node) { console.log("DOM Node added"); // Initialize your 3rd party library here } return () => { console.log("Cleanup time!"); // Destroy library instance to prevent memory leaks }; }} /> 💡 Why we love this: Less Boilerplate: Your component tree stays flat and readable. Better TypeScript Support: No more guessing where to put the Generic types. Memory Safety: Native cleanup for DOM-attached libraries without needing an extra useEffect. React 19 is clearly focusing on making the "Developer Experience" as smooth as possible. Are you still using forwardRef, or are you ready to refactor? 👇 #ReactJS #React19 #WebDevelopment #Frontend #JavaScript #CleanCode #ProgrammingTips #SoftwareEngineering

𝗥𝗲𝗮𝗰𝘁.𝗷𝘀 𝗣𝗮𝗿𝘁 𝟮 (𝟮𝟬𝟮𝟲): 𝗝𝗦𝗫 𝗮𝗻𝗱 𝗣𝗿𝗼𝗽𝘀 𝘃𝘀 𝗦𝘁𝗮𝘁𝗲 𝗗𝗲𝗲𝗽 𝗗𝗶𝘃𝗲 🔥 𝗛𝗶 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲! 👋 In my last post, we discussed why React continues to dominate the frontend ecosystem in 2026. Today, let’s dive into two foundational concepts that every React developer must understand deeply: ✅ JSX (what it is + why it exists) ✅ Props vs State (data flow + behavior + re-render rules) 1) 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗝𝗦𝗫? 🤔 JSX stands for: 𝗝𝗦𝗫 = 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 + 𝗫𝗠𝗟 It allows us to write UI directly inside JavaScript, in a way that looks like HTML. It’s syntax that gets compiled into JavaScript behind the scenes. ✅ Why JSX exists (in simple terms) JSX makes React code:  • More readable  • Easier to maintain  • Faster to build UIs  • Better supported by IDEs + TypeScript 👉 𝗞𝗲𝘆 𝗿𝘂𝗹𝗲 𝘁𝗼 𝗿𝗲𝗺𝗲𝗺𝗯𝗲𝗿: 𝗔𝗻𝘆𝘁𝗵𝗶𝗻𝗴 𝗶𝗻𝘀𝗶𝗱𝗲 { } 𝗶𝘀 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁. 𝗝𝗦𝗫 𝗿𝘂𝗹𝗲𝘀 𝗲𝘃𝗲𝗿𝘆 𝗯𝗲𝗴𝗶𝗻𝗻𝗲𝗿 𝗺𝘂𝘀𝘁 𝗸𝗻𝗼𝘄  • Return one parent element  • Use className instead of class  • Close all tags properly  • Event handlers use camelCase (onClick, onChange) 2) 𝗣𝗿𝗼𝗽𝘀 𝘃𝘀 𝗦𝘁𝗮𝘁𝗲 ⚡ This is where most React confusion begins, and once you understand it, React becomes easy. ✅ Props (Parent → Child) 𝗣𝗿𝗼𝗽𝘀 𝗮𝗿𝗲 𝘃𝗮𝗹𝘂𝗲𝘀 𝗽𝗮𝘀𝘀𝗲𝗱 𝗳𝗿𝗼𝗺 𝗮 𝗽𝗮𝗿𝗲𝗻𝘁 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝘁𝗼 𝗮 𝗰𝗵𝗶𝗹𝗱 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁. Props are:  • Read-only (child can’t modify them)  • Unidirectional (flow only downward)  • Like function arguments 𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗵𝗲𝗻 𝘁𝗵𝗲 𝗽𝗮𝗿𝗲𝗻𝘁 𝗿𝗲-𝗿𝗲𝗻𝗱𝗲𝗿𝘀? When the parent state changes:  1. Parent re-renders  2. New props are passed  3. Child re-renders with fresh props  4. That’s React’s default behavior. ✅ State (Component’s internal memory) 𝗦𝘁𝗮𝘁𝗲 𝗶𝘀 𝗶𝗻𝘁𝗲𝗿𝗻𝗮𝗹 𝗱𝗮𝘁𝗮 𝘀𝘁𝗼𝗿𝗲𝗱 𝗶𝗻𝘀𝗶𝗱𝗲 𝗮 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁. State is:  • Mutable (changes over time)  • Local to the component  • Triggers re-render when updated 🔥 Important: State survives re-renders. If React re-renders a component, the state does NOT reset. 𝗕𝘂𝘁... ❌ State does NOT survive page refresh Refreshing the page restarts the entire React app: ❌ All state is lost ✅ Components start fresh ✅ Props are re-initialized If you want the state to persist across refresh, you need:  • localStorage  • sessionStorage  • database  • cookies  • URL params 🎯 The easiest way to remember  • 𝗣𝗿𝗼𝗽𝘀 = 𝗲𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗱𝗮𝘁𝗮 (𝗽𝗮𝘀𝘀𝗲𝗱 𝗶𝗻)  • 𝗦𝘁𝗮𝘁𝗲 = 𝗶𝗻𝘁𝗲𝗿𝗻𝗮𝗹 𝗱𝗮𝘁𝗮 (𝗺𝗮𝗻𝗮𝗴𝗲𝗱 𝗶𝗻𝘀𝗶𝗱𝗲) Next post: 𝚁̲𝚎̲𝚊̲𝚌̲𝚝̲ ̲𝙷̲𝚘̲𝚘̲𝚔̲𝚜̲ ̲𝙳̲𝚎̲𝚎̲𝚙̲ ̲𝙳̲𝚒̲𝚟̲𝚎̲ ̲(̲𝚞̲𝚜̲𝚎̲𝚂̲𝚝̲𝚊̲𝚝̲𝚎̲,̲ ̲𝚞̲𝚜̲𝚎̲𝙴̲𝚏̲𝚏̲𝚎̲𝚌̲𝚝̲,̲ ̲𝚞̲𝚜̲𝚎̲𝚁̲𝚎̲𝚏̲)̲ ̲+̲ ̲𝚆̲𝚑̲𝚎̲𝚗̲ ̲𝚝̲𝚘̲ ̲𝚞̲𝚜̲𝚎̲ ̲𝚎̲𝚊̲𝚌̲𝚑̲🚀̲ ̲ If you found this helpful, drop a 👍 or comment “Part 3,” and I’ll share the next one. #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #React2026 #LearnReact #StateManagement

React re-renders your entire component tree to update one value. Granular doesn't re-render. Ever. In React, state lives inside components. Change a value and the component re-renders — along with its children, unless you've carefully memoized everything. This is where the pain starts: stale closures, infinite useEffect loops, race conditions between renders, dependency arrays that silently break. Granular takes a completely different approach. state() is a standalone reactive primitive. It doesn't live inside a component. It doesn't depend on a component lifecycle. It exists wherever you declare it. const count = state(0); count.set(5); That's it. The DOM nodes that reference "count" update directly. No component re-renders. No diffing. No reconciliation. No virtual DOM. Because state() is just a value — not tied to any component — you can declare it anywhere: // store.js export const userStore = state({ name: "", email: "", preferences: {} }); // Any file, any component, any utility: import { userStore } from "./store"; userStore.name; // reactive read userStore.set({ ...userStore.get(), name: "Gui" }); // reactive write That's your global store. No createContext, no Provider wrappers, no useSelector, no Redux, no Zustand, no Jotai. Just a reactive value in a file. Why this matters in practice: - No stale closures — there are no closures around renders, because there are no renders - No race conditions — state updates are synchronous and direct - No dependency arrays — no useEffect, no useMemo, no useCallback - No provider pyramids — global state is just an exported variable - No performance hacks — you don't need React.memo() when nothing re-renders Every framework has tried to patch React's re-render model: Solid uses signals, Svelte compiles away reactivity. Granular goes further — state is a first-class reactive primitive that operates outside the component model entirely. Granular is open source: https://lnkd.in/dZGxj8Dy npm create @granularjs/app my-app #javascript #frontend #webdev #opensource #reactivity

🤔 Ever imported a package and got hit with one of these? ReferenceError: require is not defined Cannot use import statement outside a module “Why does this library work in Node but not in the browser?” That’s almost always ESM vs CommonJS. 🧠 JavaScript interview question What’s the difference between ESM and CommonJS, and when would you use each? ✅ Short answer CommonJS (CJS) uses require() / module.exports and loads modules at runtime (Node’s classic system). ES Modules (ESM) uses import / export, is static by default, and enables better tooling like tree-shaking. 🔍 The real differences that matter in real projects 📦 Syntax CJS: const x = require("x") + module.exports = ... ESM: import x from "x" + export ... ⏱️ When it resolves CJS resolves while your code runs → can do if (...) require(...) ESM is statically analyzed (imports are at the top level) → bundlers can optimize it 🌳 Tree-shaking ESM: ✅ easy to remove unused exports (webpack/vite/rollup love this) CJS: ❌ harder because exports can be dynamic 🔁 Interop gotchas Importing CJS in ESM can lead to “default export weirdness” In Node, ESM often needs "type": "module" or .mjs 💻 Tiny examples CJS // math.js function add(a, b) { return a + b; } module.exports = { add }; // index.js const math = require("./math"); console.log(math.add(2, 3)); ESM // math.mjs export function add(a, b) { return a + b; } // index.mjs import { add } from "./math.mjs"; console.log(add(2, 3)); ⚛️ React / Next.js practical note Modern React apps + Next.js code is ESM-first (bundlers + tree-shaking). But some Node tooling / older libs still ship CJS → you’ll see mixed ecosystems in monorepos. 🎯 Rule of thumb ✅ Choose ESM for modern apps and libraries. ✅ Use CJS when you must support older Node setups or legacy packages. #JavaScript #Frontend #WebDevelopment #NodeJS #React #Nextjs #TypeScript #CodingInterview

Streamlining Dashboard Layouts with React Context & TypeScript Managing layout states—like a collapsible sidebar toggled from a topbar—can quickly become messy if you rely on prop drilling. In my recent dashboard project, I implemented a clean and scalable solution using the React Context API. This approach allows any component (Topbar, Sidebar, or Main Content) to access the layout state without unnecessary re-renders or complex prop passing. Key highlights of this implementation: ✅ Centralized Logic: One source of truth for the sidebar's open/closed state. ✅ Type Safety: Leveraging TypeScript interfaces to ensure reliable data flow. ✅ Custom Hook: Created a useLayout hook to make the context easy to consume with built-in error handling. Here is the code snippet: "use client"; import React, { createContext, ReactNode, useContext, useState } from "react"; interface SidebarContextType { sidebar: boolean; handleSidebar: () => void; } export const SidebarContext = createContext<SidebarContextType | undefined>(undefined); const SidebarProvider: React.FC<{ children: ReactNode }> = ({ children }) => { const [sidebar, setSidebar] = useState<boolean>(true); const handleSidebar = () => setSidebar(!sidebar); return ( <SidebarContext.Provider value={{ sidebar, handleSidebar }}> {children} </SidebarContext.Provider> ); }; export default SidebarProvider; export const useLayout = () => { const context = useContext(SidebarContext); if (!context) { throw new Error("useLayout must be used within a SidebarProvider"); } return context; }; Why this matters: By using this pattern, the Topbar can trigger the toggle, the Sidebar can animate based on the state, and the Main Content can automatically adjust its margin—all perfectly synchronized. Fro More Details Please Checkout My Project:https://lnkd.in/ehPP4fRh #ReactJS #NextJS #TypeScript #WebDevelopment #FrontendEngineering #CleanCode #ProgrammingTips #SoftwareDevelopment

Is your React component becoming a "Fat Component"? We’ve all been there. You start a project, and everything is clean. But then... 1. You add an API fetch. 2. You add form validation. 3. You add window resize listeners. Suddenly, your 20-line component is 150 lines long, and your UI is buried under a mountain of logic. The fix? Custom Hooks. I call it the "Power Strip" pattern. Instead of plugging everything into your component, you plug it into a hook and just use one line of code to bring that logic in. In my latest article, I break down: How to identify "Logic Bloat." The 3 rules of building your own hooks. A real-world useFetch example you can use today. If you want to shrink your codebase and write professional-grade React, check out the full guide here: https://lnkd.in/gNqZkznW What’s one logic block you find yourself copying and pasting constantly? Let’s talk in the comments! #ReactJS #WebDevelopment #CleanCode #JavaScript #ProgrammingTips #Frontend

Structuring my knowledge about React hooks. React currently has 20+ built-in hooks (including client, server, and special ones like experimental). But in reality, in production we regularly use around 8–12 hooks. The rest are situational — for specific tasks or architectural decisions. In typical development without heavy domain-specific complexity: - 70% of the time — useState, useEffect, useMemo, useCallback - 20% — useRef, useContext, useReducer - 10% — everything else Below is a short cheat sheet of the main hooks. Core Hooks: 1. useState — local component state. Used almost anytime you need to store data. 2. useEffect — side effects (API calls, subscriptions, timers). Runs after render. 3. useContext — access context without prop drilling. Global data: theme, auth, localization. 4. useReducer — complex state logic. Great for forms, state machines, and complex transitions. 5. useRef — stores a mutable value without triggering re-render. DOM access or a “variable outside render”. 6. useMemo — memoizes computed values. Useful for expensive calculations. 7. useCallback — memoizes functions. Prevents unnecessary function recreation and breaking memo. 8. useLayoutEffect — synchronous effect before paint. Rarely needed. Mostly for DOM measurements. 9. useImperativeHandle — custom API via ref. Used with forwardRef. 10. useId — generates stable IDs. Important for SSR and accessibility. React 18+ and Modern Hooks: 11. useTransition — deferred updates without blocking the UI. For heavy renders. 12. useDeferredValue — defers a value. Useful for filtering and search. 13. useSyncExternalStore — subscription to external stores. Foundation for Redux, Zustand, etc. 14. useInsertionEffect — for CSS-in-JS libraries. Not needed in most regular apps. React 19 / Server Hooks: 15. useOptimistic — optimistic UI updates. 16. useFormStatus — form submission status (server actions). 17. useFormState — server-driven form state management. 18. useActionState — manage server actions. 19. use — experimental hook for working with promises and resources in Server Components; the most unusual one and, formally, not quite a hook in the traditional sense. 📌 The takeaway: You should know all of them. You won’t use all of them daily. You must deeply understand the core 8–10.

Import Maps in Rails 8 JavaScript Without Bundlers — Explained Simply Think of your Rails app like a restaurant. Before Import Maps (Bundlers) Bundlers work like a central kitchen: All ingredients are mixed together One big dish (JS bundle) is prepared Every customer gets the same plate Example You change one small JS file → the entire bundle rebuilds. Problems: More tooling Slower feedback Harder debugging Import Maps = Menu + Direct Delivery Import Maps act like a menu that tells the browser where each dish comes from. Example import { Turbo } from "@hotwired/turbo-rails" Browser asks: Where is this? Rails answers: pin "@hotwired/turbo-rails", to: "turbo.min.js" The browser directly downloads that file. No bundling. No build step. How JavaScript Loads (ESM Strategy) The browser loads only what the page needs. Real-world example Blog page Needs Turbo Needs comments_controller.js Does NOT load admin or dashboard JS Only required files are downloaded. Analogy: You order one dish, not the whole menu. Dependency Pinning (Freezing the Recipe) Pinning locks versions so nothing changes accidentally. Example pin "chartjs", to: "chart.min.js" This means: No surprise updates Same behavior in dev and production Real-life analogy Same recipe, same taste—every time. Cache Invalidation (Fresh Files Only) Rails fingerprints JS files. Example comments-abc123.js → old comments-xyz789.js → new Browser logic: “New name? Download again.” Result: No stale JS No hard refresh issues Why Many Small Files Are OK (HTTP/2) Modern browsers can download files in parallel. Analogy Old courier: one parcel per trip Modern courier: many parcels at once That’s why Import Maps are fast enough for most Rails apps. Real-World Fit Perfect for: Admin panels Dashboards CRUD apps Turbo + Stimulus apps Not ideal for: Heavy React/Vue apps Complex client-side state → Use Vite or esbuild there. Bundlers = factory production Import Maps = smart delivery

🚀 How APIs and Promises Work Together in JavaScript When building full-stack applications with React and Express, one concept becomes very clear: 👉 APIs and Promises are deeply connected. It takes time to: • Send the request • Reach the server • Return a response That delay is called an asynchronous operation. And this is where Promises come in. A Promise has three states available: • resolved •pending • rejected When we call an API using fetch() or axios, it returns a Promise. const getUser=async()=>await fetch("/api/users") .then(response => response.json()) .then(data => console.log(data)) .catch(error => console.error(error));(“/api/user”).then(response=>response.json()).then(data=>console.log(data)).catch(error =>console.log(error)) If you would like to wrap it manual Promise const getUser=()=>{ return new Promise((resolve,reject)=>fetch(“/api/users”).then(response =>response.json()).then(data=>resolve(data)).catch(error =>reject(error))) } getUser().then(data=>console.log(data)).catch(err=>console.log(err)) 🚀 Another Real-World Example of Promises in API Design When working with multiple APIs, we often don’t just call one endpoint. We coordinate multiple asynchronous operations. For example: 👉 Fetch user 👉 Fetch user’s orders 👉 Fetch payment details All asynchronously. 🔹 Running API Calls in Parallel with Promise.all() Instead of waiting for each request one by one: const getDashboardData = async (userId) => { try { const [user, orders, payments] = await Promise.all([ fetch(`/api/users/${userId}`).then(res => res.json()), fetch(`/api/orders/${userId}`).then(res => res.json()), fetch(`/api/payments/${userId}`).then(res => res.json()) ]); return { user, orders, payments }; } catch (error) { console.error("Failed to load dashboard data:", error); } }; The above is parallel Promises, where each promise doesn’t depend on each other runs concurrently. When building uh applications in Node.js, understanding how and when to run Promises in parallel vs sequentially makes a measurable performance difference. APIs deliver data. Promises control execution strategy.