Illia Yershov’s Post

🧠 State Management from a Frontend System Design (FSD) perspective 5 must-know principles every frontend developer should understand Most frontend state problems are design problems, not library problems. From an FSD lens, these are the fundamentals 👇 1️⃣ Local vs Global State (design first, library later) Not everything deserves global state. Local state → form inputs, toggles, modals Global state → user session, theme, cart, permissions 📌 FSD rule: Promote state to global only when multiple distant parts of the app truly need it. 2️⃣ UI State vs Server State (EXTREMELY important) This is where many apps go wrong. UI state → tabs, filters, loaders, open/close flags Server state → API data, lists, paginated results 📌 FSD rule: Server state is cached data, not app state. Treat it differently. (Think React Query / SWR vs Redux) 3️⃣ State ≠ Cache A common architectural mistake. State → represents current UI intent Cache → optimization layer for fetched data 📌 FSD rule: Don’t use Redux as an API cache. Don’t use cache to drive UI decisions. 4️⃣ Choose storage based on lifespan & scope State location is a design decision. In-memory → fast, temporary (React state) URL → shareable, restorable Cookies → server-aware, SSR IndexedDB → large, offline-first data. 📌 FSD rule: Ask “Who needs this state, and for how long?” before choosing the storage. 5️⃣ Avoid global state by default Global state increases: coupling debugging cost mental overhead 📌 FSD rule: Start local → lift up → global only if unavoidable. Most scalable apps use less global state, not more. 🧩 Final takeaway Good state management is about clear boundaries, not picking the “best” library. If you design state correctly, Redux, Context, React Query — all become implementation details. #frontend #systemdesign #reactjs #redux #javascript

🚀React (Performance & Architecture Focus) Mastering React for Scalable Frontend Applications 💡 In recent interviews, I was asked some deep questions around React architecture, rendering behavior, and performance optimization. Here are some key takeaways every React developer should know: 🔹 How React knows when to re-render React re-renders when state, props, or context changes. Under the hood, React Fiber compares the new virtual DOM tree with the previous one and updates only what changed. 🔹 Batching in React 18 React 18 introduced automatic batching — multiple state updates inside promises, timeouts, or native events are grouped into a single render for better performance. 🔹 Handling 10,000+ Records Efficiently Instead of rendering large lists directly: Use virtualization (react-window / react-virtualized) Use memoization (useMemo, React.memo) Use startTransition for non-urgent updates Paginate or lazy load data 🔹 API Fetching Strategies useEffect + fetch Axios TanStack Query (React Query) for caching, retries, background refetching Suspense for async rendering 🔹 State Management Approaches Context API (small global state) Redux (predictable centralized store) Zustand / Recoil Server state management using React Query 🔹 Object & Array Immutability Understanding shallow vs deep copy is critical when updating state to avoid unintended re-renders. Modern React is no longer just about components — it's about understanding rendering priorities, concurrency, and scalable architecture. Frontend performance is a design decision, not an afterthought. #React #ReactJS #FrontendDevelopment #React18 #WebPerformance #StateManagement #JavaScript #FrontendArchitecture #TechInterview #SoftwareEngineering

Day 5 :- “𝐘𝐨𝐮𝐫 𝐑𝐞𝐚𝐜𝐭 𝐀𝐩𝐩 𝐃𝐨𝐞𝐬𝐧’𝐭 𝐍𝐞𝐞𝐝 𝐌𝐨𝐫𝐞 𝐇𝐨𝐨𝐤𝐬 — 𝐈𝐭 𝐍𝐞𝐞𝐝𝐬 𝐚 𝐏𝐫𝐨𝐩𝐞𝐫 𝐀𝐏𝐈 𝐋𝐚𝐲𝐞𝐫.” Most React applications start like this: useEffect(() => {  fetch("/api/users")   .then(res => res.json())   .then(setUsers) }, []) Simple. Works. Ships fast. But as the app grows: • Multiple components call the same API • Response transformation logic gets duplicated • Error handling becomes inconsistent • Authentication headers are repeated • Retry logic is scattered • Caching becomes an afterthought 𝐍𝐨𝐰 𝐲𝐨𝐮 𝐝𝐨𝐧’𝐭 𝐡𝐚𝐯𝐞 𝐚𝐧 𝐀𝐏𝐈 𝐬𝐭𝐫𝐚𝐭𝐞𝐠𝐲. 𝐘𝐨𝐮 𝐡𝐚𝐯𝐞 𝐀𝐏𝐈 𝐜𝐡𝐚𝐨𝐬. 🧩 The Missing Layer in Most React Apps Frontend is not just UI rendering. It is an orchestration layer between: UI ↔ Business Logic ↔ Backend Services Yet most projects skip a dedicated API abstraction layer. Instead of this (inside component): axios.get("/users") Think in layers: 𝐂𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭 → 𝐇𝐨𝐨𝐤 → 𝐒𝐞𝐫𝐯𝐢𝐜𝐞 → 𝐇𝐓𝐓𝐏 𝐂𝐥𝐢𝐞𝐧𝐭 ✅ A Scalable API Structure Example: /services apiClient.js userService.js billingService.js apiClient.js Configured axios instance Base URL Interceptors Auth token injection Retry logic Global error handling userService.js getUsers() createUser() updateUser() useUsers.js Calls userService Handles loading Handles error Manages state Now: ✔ API logic is centralized ✔ Components stay clean ✔ Headers aren’t duplicated ✔ Backend changes affect one layer ✔ Testing becomes easier ✔ Refactoring becomes predictable 🧠 Why This Matters When React apps grow: Without API abstraction: • Business rules leak into UI • Refactors become risky • Multiple network layers emerge • Technical debt multiplies silently With proper layering: Frontend becomes maintainable under scale. 𝐓𝐡𝐢𝐬 𝐢𝐬𝐧’𝐭 𝐨𝐯𝐞𝐫-𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠. 𝐈𝐭’𝐬 𝐩𝐫𝐨𝐩𝐞𝐫 𝐟𝐫𝐨𝐧𝐭𝐞𝐧𝐝 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞. #ReactJS #FrontendArchitecture #SystemDesign #CleanCode #WebEngineering #SoftwareArchitecture #ScalableFrontend #EngineeringExcellence

⚛️ **Understanding Core Concepts of React** React has become one of the most popular libraries for building modern user interfaces. Its efficiency, flexibility, and component-based architecture make it a powerful tool for creating scalable web applications. Here are some fundamental React concepts every developer should understand: 1. Component-Based Architecture React applications are built using components. Each component represents a reusable piece of UI, making development more modular and maintainable. For example, a web application may contain components such as: * Navbar * Product Card * Chat Window * Payment Form By dividing the UI into components, developers can reuse code and maintain consistency across the application. 2. Virtual DOM React uses a Virtual DOM to improve performance. Instead of updating the real DOM directly, React first updates a virtual representation of the DOM and then efficiently updates only the parts of the real DOM that have changed. This makes React applications faster and more efficient. 3. State Management with `useState` State allows React components to manage and update dynamic data. When the state changes, React automatically re-renders the component. Example: const [count, setCount] = useState(0); This enables interactive UI elements such as counters, forms, and dynamic content. 4. Reusability and Maintainability One of React’s biggest advantages is the ability to reuse components across different parts of an application. This improves maintainability and keeps the codebase clean and organized. React simplifies the process of building dynamic and scalable user interfaces. By understanding core concepts like components, state, hooks, and the Virtual DOM, developers can build efficient and maintainable web applications. #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #SoftwareEngineering

💡 Common Interview Question: How do you manage large datasets for listing and searching in React / Next.js? Here’s the practical approach used in real production apps 👇 🔹 1️⃣ Server-Side Pagination / Chunking Instead of loading all records, fetch small chunks (e.g., 20–100 rows) from the API. This keeps initial load fast and reduces memory usage. 🔹 2️⃣ Virtualization Use libraries like react-window to render only the rows visible in the viewport. Even if you have thousands of records, the DOM stays lightweight → smooth scrolling 🚀 🔹 3️⃣ Lazy Loading Load data only when needed (on tab change, filter, or row expansion). Helps avoid unnecessary API calls and improves performance. 🔹 4️⃣ Infinite Scroll (Better UX) Fetch the next chunk automatically when the user scrolls near the bottom. Creates a seamless experience without pagination clicks. 🔹 5️⃣ With Next.js Use server components / API routes for data fetching and caching, so heavy processing happens on the server, not the client. ✅ Result: Fast load times Smooth UI performance Scalable architecture for large applications 👉 In short: Server-side pagination + virtualization + lazy loading + infinite scroll = scalable data handling in React & Next.js #React #NextJS #FrontendArchitecture #WebPerformance #InterviewPrep #JavaScript

💡 𝗛𝗼𝘄 𝗜 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗗𝗮𝘁𝗮 𝗙𝗲𝘁𝗰𝗵𝗶𝗻𝗴 𝗶𝗻 𝗠𝘆 𝗥𝗲𝗮𝗰𝘁 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗡𝗼𝘄 Earlier, I used to fetch data directly inside components. Everything in one place: API call. State. Loading. Error handling. UI rendering. It worked. But as features increased… components became messy. That’s when I changed how I structure things. 🚫 𝗕𝗲𝗳𝗼𝗿𝗲 Component → fetch → setState → render Big file. Mixed responsibilities. Hard to reuse. ✅ 𝗡𝗼𝘄 𝗜 𝗦𝗲𝗽𝗮𝗿𝗮𝘁𝗲 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 I divide things into 3 clear layers: • API Layer (pure data fetching) • Custom Hook (data logic) • UI Component (only rendering) 🧠 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗖𝗵𝗮𝗻𝗴𝗲𝗱 𝗠𝘆 𝗖𝗼𝗱𝗲 𝗤𝘂𝗮𝗹𝗶𝘁𝘆 ✔ Components became smaller ✔ Logic became reusable ✔ Easier to test ✔ Easier to scale ✔ Cleaner mental model Now when I build something, I ask: • Does this belong to UI? • Or is this data logic? • Or is this just an API function? That small shift improved how I design React apps. Frontend is not just about making things work. It’s about organizing them so they can grow. 👇 𝗦𝗶𝗺𝗽𝗹𝗲 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗜 𝗙𝗼𝗹𝗹𝗼𝘄 I’ve attached a screenshot below showing how I separate: 📁 API folder 📁 Hooks folder 📁 Components folder This simple structure made my projects much easier to maintain. How do you structure data fetching in your React projects? 👀 #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #CleanCode #LearningInPublic

If You’re Preparing for React LLD Rounds, These 10 Questions Are Non-Negotiable I’ve been working with React.js for years, but cracking Low-Level Design (LLD) interviews for top Product-Based Companies (PBCs) required a mindset shift. It’s not about APIs or syntax anymore. It’s about designing scalable, production-grade UI systems. Here are 10 React.js LLD questions you must prepare if you’re planning to switch to top PBCs. 10 Must-Know React.js LLD Questions: 1. Design a Toast Notification System in React How would you: • Manage global state • Queue notifications • Prevent overlapping toasts 2. Build a Nested Comment System (like Reddit) How would you: • Design recursive components • Normalize data • Optimize re-renders for deep trees? 3. Design a Responsive Sidebar Navigation How would you handle: • Mobile vs desktop behavior • Nested menus • Route-based active states? 4. Implement a Tab Component with Animations How would you: • Manage active tab state • Lazy render tab panels • Add smooth transitions without layout thrashing? 5. Build a Filterable, Sortable Data Table How would you: • Modularize headers • Handle pagination & sorting • Optimize for large datasets? 6. Implement a Like Button with Optimistic Updates How would you: • Update UI instantly • Handle API failures • Roll back state safely? 7. Design a Live Chat Feature in React Would you use: • WebSockets or polling? How would you manage: • Message queues • Typing indicators • Reconnection logic? 8. Throttle / Debounce User Actions to Avoid API Spam Would you: • Use lodash? • Write a custom hook? • Handle cleanup and stale closures? 9. Implement a Collapsible Accordion Component How would you: • Support single vs multiple open sections • Handle height animations efficiently? 10. Implement Dark / Light Mode Theming Would you: • Use CSS variables? • Context API? • Persist theme preferences across sessions? If you’re preparing for React LLD rounds, this is exactly the direction you should be thinking in. #frontend #mern #fullstack #systemdesign

Architectural lesson of the day: Never mix Server-Side and Client-Side pagination paradigms. Today, I went down a React state-management rabbit hole while building a financial data table with Next.js and TanStack React Table. The Goal: Minimize expensive database queries by fetching records in batches of 50, but displaying them in manageable chunks of 10 for a better UX. The Trap: I let the UI library handle the local pagination (10 rows), while Next.js and the URL handled the server batches (50 rows). The Nightmare: Two pagination systems fighting each other. Whenever a user hit refresh (F5), the local UI state evaporated, but the server page remained. The UI would jump back to the first 10 rows of the batch, completely losing the user's place. To fix it, I found myself writing hacky URL parameters (?startFromEnd=1) and complex useMemo/useEffect logic just to keep the UI and Server in sync. I realized I was building a fragile house of cards. The core issue? I was forcing a UI library to manage architectural state. The Refactor (Separation of Concerns): The Server: Still fetches the optimal batch of 50 rows to keep DB costs low. The Component State: Manages a simple manual slice of the array (data.slice(...)) based on local state or URL. The Table Library: Stripped of all its internal pagination logic (getPaginationRowModel()). It is now a "dumb" component that simply renders the 10 rows it is handed. The Result: I deleted dozens of lines of complex lifecycle code. No more useEffect sync issues, no more URL hacks, and the UI state is rock solid even on refresh. The Takeaway: UI libraries are incredibly powerful, but don't let them blur your architectural boundaries. Keep your source of truth single, clean, and determinable. How does your team handle the balance between UX (small pages) and DB costs (large batches)? Let me know below! 👇 #ReactJS #NextJS #WebDevelopment #SoftwareEngineering #Architecture #Frontend

𝗠𝗼𝘀𝘁 𝗳𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝘁𝗵𝗶𝗻𝗸 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗶𝘀𝘀𝘂𝗲𝘀 𝗮𝗿𝗲 𝗰𝗮𝘂𝘀𝗲𝗱 𝗯𝘆 “𝘁𝗼𝗼 𝗺𝗮𝗻𝘆 𝗿𝗲-𝗿𝗲𝗻𝗱𝗲𝗿𝘀.” That’s rarely the real problem. The real problem is uncontrolled data flow. I keep seeing React applications where: • Server state is mixed with UI state • Components fetch their own data randomly • Global state is used for everything • Caching strategy is an afterthought • Re-fetching logic is duplicated everywhere Then the team starts adding: • useMemo • useCallback • React.memo Trying to patch symptoms. But unnecessary renders are often a design smell, not the root issue. When data ownership is unclear, the component tree becomes unpredictable. When caching is inconsistent, network noise increases. When state is duplicated, synchronization bugs appear. Before optimizing rendering, ask: • Who owns this data? • Is this server state or UI state? • Should this live in React state at all? • Is the cache strategy defined intentionally? Performance improves dramatically when architecture improves. Optimization is not about memoization tricks. It’s about clarity of data boundaries. Most frontend performance issues are architectural, not micro-level. Are you optimizing renders — or fixing the wrong problem? #FrontendDevelopment #ReactJS #WebPerformance #SoftwareArchitecture #EngineeringLeadership

Most React performance problems aren’t “React problems” — they’re architecture mistakes: putting the wrong code on the wrong side. ⚖️⚡ React Server Components (RSC) vs Client Components is less about hype and more about boundaries. I use this decision pattern: ✅ Default to Server Components when: • fetching data + rendering UI can happen on the server • the component is mostly static or data-driven • you want smaller bundles + faster first paint Examples: dashboards, lists, detail pages, email/HR records, healthcare summaries 🏥 ✅ Use Client Components when you need: • interactivity (state, effects, subscriptions) • browser APIs (localStorage, media, geolocation) • realtime UX (drag/drop, charts with live updates) Examples: scheduling UI, triage workflows, energy monitoring controls ⚙️ Practical rule: keep the “shell” on the server, push only the “interaction island” to the client. 🌊 Watchouts I see in Next.js: • importing a client component too high forces big client bundles • mixing data fetching + heavy UI libraries in client components kills TTFB/JS cost • streaming is great, but only if your component graph stays server-first 🚀 If you’re designing a new feature: what is the smallest client surface area you can get away with? #react #nextjs #javascript #webperformance #frontend