React Props: Passing Data Between Components

Most React codebases become unmanageable within 6 months. Not because React is the problem. Because nobody planned the architecture before writing the first component. I have seen this in almost every project we take over from another team. Components doing too much. Business logic mixed into UI layers. State scattered across the app with no clear pattern. API calls happening inside components that should only render data. It works fine at 10 components. It breaks at 50. Here is how we structure every React and Next.js project at Velox Studio from day one: → Strict separation of concerns. UI components never contain business logic. Data fetching lives in its own layer. Formatting and transformation happen in utility functions, not inside JSX. → Component hierarchy defined before code is written. We map every screen into a tree of components before building anything. Parent components manage state. Child components receive props. No exceptions. → A consistent naming and folder convention. Every developer on the project knows exactly where to find a component, a hook, a utility, or an API call. No guessing. No searching. → Custom hooks for reusable logic. If two components need the same data or behaviour, it becomes a hook. Not copy-pasted code. → State management chosen for the use case, not the trend. Local state for component-specific data. Context for shared UI state. Server state handled by React Query or SWR. Global stores only when genuinely needed. The goal is not to write clever code. The goal is to write code that a new developer can understand in 15 minutes and contribute to in an hour. Architecture is not overhead. It is the difference between a project that scales and one that stalls. How does your team handle architecture decisions before starting a new build? #ReactJS #FrontendArchitecture #NextJS #WebDevelopment #CleanCode

🚀 Handling API Requests Like a Pro (Fetch + AbortController) Fetching data is easy — managing requests properly is where real frontend engineering starts. Here’s how I handle it 👇 🧠 Basic Fetch const res = await fetch("/api/data") const data = await res.json() ⚠️ Problem: What if the user navigates away or types quickly (search input)? 👉 Multiple requests = wasted resources + race conditions 🛑 AbortController (Cancel Requests) const controller = new AbortController() fetch("/api/data", { signal: controller.signal }) controller.abort() // cancels request ⚡ Real-World Use Case Search input: let controller async function search(query) { if (controller) controller.abort() controller = new AbortController() const res = await fetch(`/search?q=${query}`, { signal: controller.signal }) const data = await res.json() console.log(data) } 💡 Why It Matters • Prevents unnecessary API calls • Avoids race conditions • Improves performance • Better user experience 🎯 Takeaway: Good apps don’t just fetch data — they control when and how requests run. Building smarter and more efficient data-fetching patterns. 💪 #JavaScript #FetchAPI #FrontendDeveloper #Performance #MERNStack #SoftwareEngineering

🚀 Handling 1M+ Records in React Without Crashing the UI One challenge I recently explored was: How do you display very large datasets (1M+ rows) in a React application without slowing down the browser? Rendering everything at once is not practical. It leads to heavy DOM rendering, slow performance, and poor user experience. Here are some practical approaches developers use in real-world applications: 1️⃣ Pagination Instead of loading everything, fetch data page by page from the backend. Example: Page 1 → 50 records Page 2 → next 50 records This reduces memory usage and improves performance. 2️⃣ Virtualization (Windowing) Libraries like react-window or react-virtualized render only the rows visible on the screen. Even if you have 1M records, the UI may only render 20–30 DOM nodes at a time. 3️⃣ Lazy Loading / Infinite Scroll Load more data as the user scrolls. Example flow: User scrolls → trigger API → load next batch of records. 4️⃣ Backend Filtering & Searching Never send huge datasets to the frontend. Instead, let the backend handle: filtering sorting searching pagination Example architecture: Frontend (React) ⬇ API (FastAPI / Flask) ⬇ Database Query with LIMIT / OFFSET Key takeaway: Handling large datasets is not just a frontend problem — it requires proper frontend + backend architecture. Performance optimization becomes critical when working with large-scale applications. Curious to know how other developers handle large datasets in UI? #React #FrontendDevelopment #WebPerformance #FastAPI #SoftwareEngineering

𝐖𝐡𝐲 𝐲𝐨𝐮 𝐬𝐡𝐨𝐮𝐥𝐝 𝐜𝐨𝐧𝐬𝐢𝐝𝐞𝐫 𝐮𝐬𝐢𝐧𝐠 𝐑𝐞𝐚𝐜𝐭 𝐐𝐮𝐞𝐫𝐲 𝐭𝐨 𝐡𝐚𝐧𝐝𝐥𝐞 𝐲𝐨𝐮𝐫 𝐀𝐏𝐈 𝐫𝐞𝐪𝐮𝐞𝐬𝐭𝐬. Fetching data is simple but managing that data properly is where things can get complicated. You have to handle caching, refetching, syncing across components, handling errors. React Query can ease that process for you. 🔵 𝐖𝐡𝐚𝐭 𝐲𝐨𝐮 𝐠𝐞𝐭:  ➡️ Caching: same query across components doesn't refetch  ➡️ Background refetching: data stays fresh without loading spinners  ➡️ Retry logic: failed requests retry automatically ➡️ Stale-while-revalidate: show cached data while fetching new  ➡️ Optimistic update: show desired outcome and fallback to cashed data if req failed  ➡️ Devtools: see exactly what's cached and when 🟣 𝐓𝐡𝐞 𝐛𝐢𝐠𝐠𝐞𝐫 𝐛𝐞𝐧𝐞𝐟𝐢𝐭: It separates server state from client state.  Your Redux or Context stays clean for UI state (modals, tabs, forms).  Your async data lives in React Query. That way you are to mixing an” is the modal open" info with "what did the API return." 🔑 Less boilerplate. Better UX. Clearer architecture. What libraries have simplified your React codebase and speed the development process? ⬇️ #frontenddeveloper  #reactdeveloper  #frontend  #recruiter  #javascript

🚀 Day 23 — Mastering Upward Data Flow in React In React, data flows downward by default — from parent to child via props. But scalable applications require something equally important: 👉 Upward data flow — sending data from a child component back to its parent. Today, I focused on mastering this pattern and applying it in a real project. 🔹 Understanding Upward Data Flow (Child ➝ Parent) Although it may seem indirect, the mechanism follows a clear and predictable pattern: ✅ The 4-Step Pattern 1️⃣ Define a Custom Event Prop The child receives a function as a prop (e.g., onCategoryChange). 2️⃣ Trigger the Event in the Child Inside the child component, a function is executed (often via a synthetic event like a button click) that calls the prop function and passes relevant data. 3️⃣ Handle the Event in the Parent The parent passes a handler function to the child. 4️⃣ Update Parent State The parent receives the data and updates its state, triggering a controlled re-render. This preserves React’s unidirectional data model while enabling interactive behavior. 🔹 Real-World Application — Fake Store Project 🛒 I applied this pattern in a project using the Fake Store API. Architecture overview: Parent component: manages state for category filters and search text Child component: triggers filtering events based on user interaction Parent re-renders child with updated filtered data This separation keeps: • State ownership centralized • Components reusable • Data flow predictable 🧠 Key Engineering Insight React applications scale well when: State lives at the correct hierarchy level Child components remain reusable and stateless where possible Communication patterns remain explicit and predictable Upward data flow is not a workaround — it is a deliberate architectural pattern. Onward to Day 24 🚀 💬 For frontend developers: How do you decide where state should live in a complex component tree? #ReactJS #FrontendDevelopment #ReactPatterns #SoftwareEngineering #WebArchitecture #JavaScript #100DaysOfCode #LearningInPublic

In a recent project, I faced a challenge with integrating a complex API and making a dashboard responsive Instead of just 'patching' it, I took a step back to: Analyze: Identified the bottleneck in the data flow. Refactor: Modularized the components for better reusability. Test: Ensured cross-browser compatibility across all devices. The result? A 20% increase in load speed and a much happier client. Being a developer means being a professional problem solver first, and a coder second. If you’re looking for a developer who values scalable architecture and clean UI, let’s connect! #SoftwareEngineering #FrontendDeveloper #ProblemSolving #JavaScript #WebDev"

💭 Thought about Bonus for 6 days of consistency 🚀 Day 22 of consistency! 🌟 Understanding 4-Layer Architecture in React (Clean & Scalable Frontend Design) While building scalable React applications, structuring your code properly is just as important as writing it. One effective approach is organizing your app into 4 logical layers: 🔹 1. Components Layer (UI Layer) This is where your UI lives. Reusable components like buttons, cards, forms, and layouts are defined here. ✅ Focus: - Rendering UI - Receiving props - Keeping components reusable and clean 💡 Example: Navbar, LoginForm, ChatCard --- 🔹 2. Hooks Layer (Logic Layer) Custom hooks help separate logic from UI. ✅ Focus: - Managing reusable logic - Handling side effects - Keeping components lightweight 💡 Example: useAuth(), useChat(), useFetch() --- 🔹 3. State Layer (Data Management Layer) This layer manages application state. ✅ Focus: - Global/local state handling - Sharing data across components 🔧 Tools you can use: - useState / useReducer - Context API - Redux / Zustand 💡 Example: User authentication state, theme state, chat messages --- 🔹 4. API Layer (Service Layer) Handles all backend communication. ✅ Focus: - API calls (GET, POST, PUT, DELETE) - Error handling - Keeping API logic separate from UI 💡 Example: - loginUser() - fetchMessages() - postChatMessage() ✨ Why this architecture? ✔ Better code organization ✔ Improved scalability ✔ Easy debugging & testing ✔ Clean separation of concerns 📌 Pro Tip: Never mix API calls directly inside components —> keep your UI clean and logic reusable! #ReactJS #FrontendDevelopment #WebDevelopment #CleanCode #JavaScript #SoftwareArchitecture #Developers Satwik Raj Ankur Prajapati

We don’t talk enough about this: useEffect might be the most overused hook in React. After reading a thread by Alvin Sng, I started questioning a default assumption I’ve had for years: “just put it in useEffect.” Thread: https://lnkd.in/djZfqRUp  React docs (“You Might Not Need an Effect”): https://lnkd.in/d9dSAnnT The more I think about it, the more it feels like a design smell — not a solution. Especially in modern codebases (and even more with AI-generated code): 1. Dependency arrays hide coupling 2. Effects create invisible control flow 3. Small “just in case” logic turns into race conditions fast It made me step back and rethink React from a system design perspective: Instead of asking “where do I put this effect?” I’m starting to ask “why does this side effect exist at all?” That shift alone changes how you design components. Some patterns that feel more system-friendly: • Derive state instead of syncing it: If something can be computed, it probably should be. • Push side effects to the edges: Keep core components predictable. Treat effects like I/O boundaries. • Use dedicated data-fetching layers (TanStack Query, SWR, etc.): Fetching inside components feels more like legacy now. • Let events drive behavior: User action → handler → result. No indirection. • Use component boundaries intentionally: Reset state with keys. Lift orchestration up. Keep children simple. It’s already shifting how I approach frontend architecture and think about control flow in React. Feels less like “avoiding a hook” and more like designing systems with clearer control flow. Curious how others think about this: Have you tried minimizing useEffect? Did it improve your codebase - or just add friction? #React #Frontend #SystemDesign #CleanCode #SoftwareEngineering #AIinDev

🚨 Your API is fast… so why is your UI still slow? This is where most engineers get it wrong. They spend hours optimizing: Database queries Backend latency API response time And ignore what happens after the data arrives. --- 👉 The real issue: Main Thread Blocking Your browser runs most of your JavaScript on a single thread. That means: Rendering Event handling JS execution …all compete for the same resource. --- 🔴 What causes UI lag: Large JSON parsing Heavy loops on big datasets Complex state updates (especially in frameworks) Synchronous blocking operations Even a 200–300ms block can cause: 👉 Frame drops 👉 Input lag 👉 Janky scrolling --- 🟢 What high-performance apps do: 1. Break long tasks setTimeout(() => processChunk(data), 0); 2. Use requestIdleCallback Run non-critical work when browser is idle 3. Move heavy work off the main thread Web Workers 4. Optimize rendering frequency Batch state updates Avoid unnecessary re-renders --- ⚡ Real mindset shift: Stop asking: > “How fast is my API?” Start asking: > “How long is my main thread blocked?” --- 💡 Pro tip: Open Chrome DevTools → Performance tab Record a session If you see long tasks (>50ms): 👉 That’s your bottleneck. --- 🚀 Impact when you fix this: Smooth scrolling Instant click response Better perceived performance --- Most developers optimize the backend. Great developers optimize the user experience timeline. Where is your bottleneck right now? #frontend #performance #javascript #webdev #engineering