Two-Way Data Binding vs React State: Key Differences

🚀 A React Feature That Looked Simple… But Was Surprisingly Complex While working on a recent React assignment, I implemented a data table with server-side pagination and persistent row selection using React + TypeScript + PrimeReact. At first glance, it seemed like a straightforward task. But once I started building it, I realized how many real-world concepts are involved behind the scenes. Here’s what the feature included: 🔹 Server-Side Pagination Instead of loading all data at once, the table fetches data page-by-page from the API. This keeps the application efficient and scalable. 🔹 Persistent Row Selection Across Pages Users can select rows on one page, navigate to another page, and return later — and their selections remain intact. To achieve this, I stored only row IDs using a Set, avoiding unnecessary data storage and ensuring fast lookup. 🔹 Custom Row Selection Panel I built a custom selection feature using PrimeReact’s OverlayPanel, where users can enter a number to automatically select the first N rows of the current page. 🔹 Avoiding Prefetching Pitfalls The assignment required that we must not fetch additional pages or store other page data. So the logic strictly operates on current page data only, keeping memory usage safe and compliant with the requirements. 🔹 Handling Component Re-rendering Challenges One interesting challenge was that row selection updates didn’t immediately reflect due to DataTable’s internal optimization. Understanding React reconciliation and component keys helped resolve this. 💡 Key Concepts I Reinforced While Building This Server-side pagination Efficient state management using Set React refs (useRef) for controlling UI components Accessibility improvements using aria-label React reconciliation & component re-render behavior Building interactive UI with PrimeReact 🎥 I’ve also recorded a walkthrough of the project, explaining the architecture and logic step-by-step. Would love to hear your thoughts or suggestions! #React #TypeScript #WebDevelopment #FrontendDevelopment #PrimeReact #LearningInPublic #DeveloperJourney #CFBR

🚀 Why I replaced Object with Map() in a performance-critical backend feature I was working on a feature where I needed to track active driver sessions in memory. Initially, I used a normal Object: const sessions = {}; sessions[101] = { status: "online" }; sessions[102] = { status: "offline" }; It worked well… until the number of active sessions grew to thousands. Frequent insertions, deletions, and lookups started becoming harder to manage efficiently. That’s when I switched to Map(). 📌 What is Map()? Map is a built-in JavaScript data structure designed for efficient key-value storage with faster and predictable performance. 📌 How to create Map()? Map can be created using the Map constructor. const sessions = new Map(); 📌 Operations with Time Complexity sessions.set(101, { status: "online" }); // Insert → O(1) sessions.get(101); // Lookup → O(1) sessions.has(101); // Check → O(1) sessions.delete(101); // Delete → O(1) All major operations in Map are O(1) average time complexity, making it ideal for high-performance systems. 📌 Why use Map instead of Object? • Faster insert and lookup → O(1) • Maintains insertion order • Supports any data type as key • Optimized for frequent add/remove operations • Better performance for large datasets 📌 Real-world backend use cases • Caching user sessions • Managing socket connections • Storing in-memory lookup tables • Deduplication logic • Tracking active users 📌 Object vs Map (Performance Insight) Object → Not optimized for frequent insert/delete Map → Designed for high-performance key-value operations Map internally uses a hash table, enabling constant-time operations. 💡 Key Lesson Choosing the right data structure can significantly improve performance. Map provides predictable O(1) performance, making it a powerful tool for scalable backend systems. #JavaScript #NodeJS #BackendEngineering #SoftwareEngineering #Programming #Performance

Creating custom validators in Signal Forms is simpler than you think! In my previous articles, I talked about the built-in validation rules and async validation in Signal Forms, but what happens when you hit a highly specific business requirement? Maybe you want the password to contain a special character, or a username to not be "admin". In traditional Reactive Forms, this meant writing a custom 'ValidatorFn', digging into the 'AbstractControl' to grab the value, and returning a generic error map. Signal Forms make this incredibly elegant with the new 'validate' function. You just read the value directly from the signal. No more control.value guesswork. And since the form is driven by your data model, TypeScript knows exactly what type of data you are validating. If the data is valid, return 'null'. If it’s invalid, return a simple object with a 'kind' property and your custom message. If you want to make your validator reusable, just wrap 'validate' inside a function, and then you can use that function in any form where you want that custom validation to happen. It feels much more like writing standard, predictable JavaScript/TypeScript rather than fighting the framework. #Angular #TypeScript #WebDevelopment #Frontend #SignalForms #SoftwareEngineering

I stopped using useEffect for data fetching. Here's why. For years, my React components looked like this: useEffect(() => { setLoading(true); fetch('/api/users') .then(res => res.json()) .then(data => setUsers(data)) .catch(err => setError(err)) .finally(() => setLoading(false)); }, []); Loading state. Error state. Race conditions. Cleanup functions. Stale closures. Every. Single. Component. Then I switched to React Query (TanStack Query) and deleted 40% of my state management code overnight. Here's what changed: → No more loading/error/data useState triplets → Automatic caching — same data across 10 components, 1 network request → Background refetching — users always see fresh data without spinners → Race condition handling — built in, not bolted on → Retry logic — automatic, configurable, zero custom code But here's what most tutorials won't tell you: React Query doesn't replace ALL useEffect calls. It replaces the ones you should never have written in the first place. useEffect is still perfect for: • Subscriptions (WebSocket, event listeners) • DOM synchronization • Third-party library integration The mistake is using useEffect as a "fetch on mount" hook. That was always a workaround, not a pattern. In my TypeScript projects, I enforce this with a simple ESLint rule: no fetch() inside useEffect. If you're fetching data, use a query hook. Period. The result? Components that are 50% shorter, easier to test, and actually work correctly with React 18+ concurrent features. What's your go-to data fetching approach in React? Still useEffect, or have you moved on? #React #TypeScript #ReactQuery #TanStackQuery #WebDevelopment #JavaScript #DeveloperProductivity #CleanCode

𝐈𝐟 𝐲𝐨𝐮'𝐫𝐞 𝐬𝐭𝐢𝐥𝐥 𝐰𝐫𝐞𝐬𝐭𝐥𝐢𝐧𝐠 𝐰𝐢𝐭𝐡 𝐚𝐧𝐲 𝐰𝐡𝐞𝐧 𝐦𝐚𝐩𝐩𝐢𝐧𝐠 𝐨𝐛𝐣𝐞𝐜𝐭 𝐩𝐫𝐨𝐩𝐞𝐫𝐭𝐢𝐞𝐬 𝐢𝐧 𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭, 𝐲𝐨𝐮'𝐫𝐞 𝐦𝐢𝐬𝐬𝐢𝐧𝐠 𝐨𝐮𝐭. I've seen so many React components become any-land when trying to build reusable utilities that operate on object shapes. Like a generic Picker component that takes an array of objects and needs to extract a specific id or name field, but only if that field exists. The magic often lies in properly constraining your generics. Instead of `function getProperty<T>(obj: T, key: string)` (which loses all type safety for `key`), try `extends keyof T`. Example: ```typescript function pickProperty<T extends Record<string, any>, K extends keyof T>( items: T[], key: K ): T[K][] { return items.map(item => item[key]); } // Usage: interface User { id: string; name: string; email: string; } const users: User[] = [ /* ... */ ]; const userIds = pickProperty(users, 'id'); // Type: string[] // pickProperty(users, 'address'); // TS Error: 'address' does not exist on type 'User' ``` Here, `T extends Record<string, any>` ensures `T` is an object, and `K extends keyof T` makes sure `key` is a valid property of `T`. This gives you strong type inference and compiler errors where you need them. This pattern is a lifesaver for building type-safe, reusable data transformations in your React/Next.js applications, especially when dealing with API responses that share common structures. What's your go-to pattern for keeping object manipulations type-safe without falling back to any? Share your thoughts below! #TypeScript #React #FrontendDevelopment #Generics #WebDev

🚀 Lately, I’ve been diving deeper into TanStack Query (React Query) and honestly, it’s been a game changer for handling server state in React apps. If you’ve ever struggled with: ❌ Managing loading, error, and success states manually ❌ Re-fetching data after mutations ❌ Caching and syncing server data with UI ❌ Writing repetitive API logic Then TanStack Query solves all of this beautifully. 💡 What makes it powerful: • Automatic caching → reduces unnecessary API calls • Background refetching → keeps data fresh without extra effort • Built-in loading & error handling → cleaner UI logic • Optimistic updates → instant UI feedback for better UX • Devtools support → super helpful for debugging ⚡ What stood out to me: Instead of thinking in terms of “when to call APIs”, you start thinking in terms of “what data does my UI need”. TanStack Query takes care of the rest. 📌 Simple example: useQuery → fetch & cache data useMutation → update server state + auto sync This shift significantly improves: ✅ Code readability ✅ Performance ✅ Developer experience If you’re building React apps and still managing server state manually, I’d highly recommend exploring TanStack Query. Definitely a must-have tool in a modern full-stack developer’s toolkit 💯 #React #TanStackQuery #WebDevelopment #Frontend #FullStack #JavaScript #DeveloperExperience

React Query changed how I think about frontend architecture. Before learning it deeply, my React apps looked like this: • `useEffect` everywhere • Manual loading states • Duplicate API calls • Complex global state The real problem? I was mixing server state with client state. Once I understood React Query architecture, everything became simpler. --- ## 🧠 Mental Model Think of React Query as a server state manager. Architecture: Server (API) ↓ React Query Cache ↓ React Components Your components never talk directly to the server. They talk to the cache layer. This small shift solves many problems automatically. --- ## ⚡ Query Flow When a component requests data: 1️⃣ React Query checks cache 2️⃣ If data exists → return instantly 3️⃣ If stale → re-fetch in background 4️⃣ Cache updates → UI re-renders This pattern is called: Stale-While-Revalidate Result: • Fast UI • Fresh data • Minimal API calls --- ## 🔄 Mutations (Writes) For updates like: • Add to cart • Update profile • Create order React Query uses mutations. Flow: User Action ↓ Mutation request ↓ Server update ↓ Invalidate related queries ↓ Refetch fresh data This keeps UI and backend in sync. --- ## 🚀 Prefetching Strategy One underrated feature is prefetching. Example: User opens product list. When they hover on a product → prefetch product details API. By the time they click → data already exists in cache. Navigation becomes instant. --- ## 🔥 Why This Matters When apps scale: Manual fetching leads to: ❌ API duplication ❌ inconsistent UI state ❌ difficult debugging React Query solves this by introducing a data architecture layer. Frontend starts behaving like a **distributed system client** instead of just UI. --- Now I’m designing frontend apps with: • Server state layer • Cache strategy • Query invalidation rules Instead of just writing fetch calls. --- 👉 Curious to know: Do you prefer **React Query** or **SWR** for server state management? #SystemDesign #Frontend #Backend #MERNStack #WebDev #FullStack #Developer #Web #Developer #Performance #Rendering #Express #JavaScript #BackendDev #Node #Mongo #Database #TanStack #Query #React

One of the biggest misconceptions I see: “Signals make lifecycle irrelevant.” No — they just shift it. React controls UI lifecycle (Render → Commit) Signals control data lifecycle (invalidate → recompute → schedule) If you don't respect both boundaries, things break: - tearing - infinite renders - inconsistent updates This article is about drawing that line correctly. #react #webdevs #frontend #javascript #typescript #signals #reactivity

🚀 **Next.js Frontend Data Fetching: Mistakes vs Best Practices (Big Scale Projects)** Frontend e data fetching properly handle na korle project ta quickly messy hoye jay 😓 Especially large-scale app e — structure na thakle maintain kora impossible. Here’s a simple breakdown from real-world experience 👇 --- ❌ **Common Mistakes (Avoid These)** • Direct component e API call kora (useEffect diye) • No caching → same request bar bar 🔁 • UI & data logic mix kora • Loading & error state ignore kora • Over-fetching unnecessary data • Duplicate API logic across components --- ✅ **Best Practices (Follow These)** 🔹 **1. Use Service Layer for Data Fetching** API call gula ekta separate layer e rakho 👇 ✔ Clean code ✔ Reusable ✔ Easy maintenance 🔹 **2. Use TanStack React Query** Async state manage korar jonno MUST use koro 👇 ✔ Smart caching ✔ Auto refetch ✔ Loading & error handling ✔ Better performance 🚀 🔹 **3. Keep Components Clean (UI Only)** Component e sudhu UI thakbe — logic na --- 🏗️ **Recommended Frontend Flow** UI Component ↓ Custom Hook (useProducts) ↓ Service Layer (API functions) ↓ Backend API --- 💡 **Why This Matters?** 👉 Without structure: Code messy, slow & hard to scale 👉 With proper flow: ✔ Clean architecture ✔ Better performance ✔ Easy to scale ✔ Developer-friendly --- ⚠️ **What NOT to Do** 🚫 Component e directly fetch koro na 🚫 Business logic + UI mix koro na 🚫 Caching ignore koro na 🚫 Same API multiple jaygay likho na --- 🔥 **Pro Tip:** “Small project e shortcut cholbe, but big project e structure is everything.” --- #NextJS #ReactJS #FrontendDevelopment #WebDevelopment #CleanCode #SoftwareArchitecture #TanStackQuery #Performance #ScalableApps

Our reporting app was slow, complex, and hard to debug. Every calculation lived inside Blazor pages, making the UI bloated and the team bottlenecked. Here’s how I redesigned it to be faster, cleaner, and scalable… 🔎 𝗧𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝗥𝗲𝗽𝗼𝗿𝘁𝘀 pulled entire datasets into Blazor. 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗹𝗼𝗴𝗶𝗰 and calculations were scattered across UI code. 𝗗𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 was painful, and only full-stack engineers could contribute. ⚙️ 𝗧𝗵𝗲 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 Shifted all calculations into SQL Server 𝗦𝘁𝗼𝗿𝗲𝗱 𝗽𝗿𝗼𝗰𝗲𝗱𝘂𝗿𝗲𝘀. Leveraged advanced SQL features (𝗹𝗶𝗸𝗲 𝗥𝗢𝗟𝗟𝗨𝗣) to generate hierarchical structures directly. Returned results as 𝗝𝗦𝗢𝗡, consumed by a single controller. Blazor pages became display-only, powered by reusable recursive components. 📈 𝗧𝗵𝗲 𝗢𝘂𝘁𝗰𝗼𝗺𝗲 𝗕𝗹𝗮𝘇𝗼𝗿 code reduced to pure display logic → simpler, reusable, and maintainable. 𝗗𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 moved to SQL layer → faster validation. 𝗧𝗲𝗮𝗺 𝘀𝗰𝗮𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆 unlocked: SQL 𝘀𝗽𝗲𝗰𝗶𝗮𝗹𝗶𝘀𝘁 handles queries. 𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 developer focuses on UI. 𝗗𝗲𝘀𝗶𝗴𝗻𝗲𝗿 works on HTML/CSS. 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁 ensures business logic integrity. This refactor taught me that future-proofing isn’t just about technology — it’s about designing systems where teams can grow without friction. By moving logic closer to the data and simplifying the UI, we achieved both performance and collaboration gains #dotnet #blazor #sqlserver #softwarearchitecture #systemdesign #leadership #scalability