Choosing the Right Data Fetching Strategy

WHY STORING FILTERS IN useState IS A BAD IDEA : Filters look like simple UI state. But treating them as local state creates real problems in production apps. What usually happens: Filters are stored using useState Example: • search query • category • price range • page number It works… until users actually use the app. The real problems: 👉 Refresh the page → All filters reset 👉 Copy the URL → No filters included 👉 Share the link → Other user sees different data 👉 Navigate back/forward → State is inconsistent 👉 This breaks user experience in real products The core mistake: Treating filters as UI state But filters are NOT just UI 👉 They represent the current view of data That means: They should live in the URL The correct approach: 👉 URL = Single Source of Truth Instead of: useState → local state Use: URL query params → global state How this works in real apps (Next.js): Use built-in routing tools • useSearchParams() → read filters from URL • useRouter() → update query params Example URL: ?search=laptop&category=electronics&page=2 👉 This URL fully describes the UI state Why this is powerful: • Refresh safe → state persists • Shareable → exact same view • Bookmark friendly • SEO friendly (important for Next.js apps) • Works naturally with browser navigation Real production pattern: When filters change • Update URL params • Reset pagination (page = 1) • Trigger data refetch Where TanStack (React Query) fits: This is where things become clean. Query key depends on URL params Example: ["products", search, category, page] 👉 When URL changes → query key changes → auto refetch No manual state syncing needed Clean architecture flow: URL → Source of truth ↓ React reads params ↓ TanStack Query fetches data ↓ UI renders 👉 No duplicate state 👉 No inconsistencies Important mindset shift: The URL is not just navigation It is: • State • Memory • Shareable context Final Insight: useState is for temporary UI state (not for data that defines the page) If the state affects: • data fetching • navigation • sharing 👉 It belongs in the URL Once this pattern is clear → frontend architecture becomes much cleaner and predictable #ReactJS #NextJS #TanStackQuery #Frontend #WebDevelopment #SystemDesign

When your beautiful app has no soul (The Hardcoded Data Trap) POST 5: We had built something gorgeous. The Luclair Vision storefront was pixel-perfect. It had smooth animations, premium imagery, and an intuitive flow. It looked ready for production. But there was a massive problem. It was entirely fake. During an early demo, the UI was a massive hit—until people actually tried to use it: They clicked "Add to Cart" -> Nothing happened. They checked the "Customer Reviews" -> Every review was a hardcoded array of fake people. We checked the Admin Dashboard -> The revenue metric refreshed to a different, totally random number every time. (Math.random() is not a valid business strategy, it turns out). The users immediately asked: "Is this actually functional?" We had to admit it wasn't. Why we fell into the trap We started with a UI/UX-first approach, which is standard practice. But we got so hyper-focused on making the components look beautiful that we kept deferring the database. Mocking data was fast. Wiring up a backend was slow. "We’ll connect the real data later," became our famous last words. The Wake-Up Call That demo forced us to stop playing dress-up with our React state. A beautiful UI is only half the battle. We had to build the engine. Our roadmap completely shifted: Finalize a proper PostgreSQL database schema (which I covered in my last post). Connect our frontend to Supabase. Build out real, functional API endpoints. Painfully gut our mocked data, component by component. The Lesson Mocked data is essential for visualizing UI development, but it is technical debt. If you don't have a strict timeline for replacing those hardcoded arrays with real database calls, your "platform" is just a PowerPoint presentation with buttons. Build your data-fetching architecture in parallel with your components, not as an afterthought. Have you ever fallen into the "mocked data forever" trap? How long did it take you to dig your way out? Let me know below 👇 #WebDevelopment #NextJS #SoftwareEngineering #TechFounders #ReactJS #FrontendArchitecture #LessonsLearned

💲 I built a simple Data Analytics Dashboard that shows a software company how much money it's making, which products are doing well or badly, which countries are growing and what actions to take next- all in one screen. Here I took fake data set ,and i used Component-based architecture- each UI block is its own isolated file. This individual project taught me ✅ How to build a real-world app layout (header, cards, charts, tables, footer) ✅ How to use Recharts to draw interactive charts from data ✅ How to make live updating UI ✅ How to style a dark themed professional dashboard with Tailwind CSS This is how real companies use to make decisions by looking at conversion rate , growth via a Live Dashboard. Check this out ⭕ GitHub Link: https://lnkd.in/gkkN-6gZ ⭕ Google Drive Link : https://lnkd.in/gfiRkeYQ #DataAnalytics #WebDevelopment #ReactJS #FrontendDevelopment #DataVisualization #DashboardDesign #SoftwareEngineering #SoftwareArchitecture #Projects #LearningJourney

🪟 Next.js Parallel Routes — render multiple pages in one layout. Most devs don't use this. Here's why you should 👇 Traditional routing swaps the whole page on navigation. Parallel Routes let multiple route segments live side by side — independently loading, independently erroring, independently streaming. How it works: Prefix folders with @ → they become slots. app/ ├── layout.js ├── @analytics/page.js └── @team/page.js Code Your layout receives them as props: export default function Layout({ children, analytics, team }) { return ( <div> {analytics} {team} </div> ); } Js Each slot streams independently — no slot blocks another. Real-world wins: → 📊 Analytics + team metrics on one dashboard — each fetches its own data → 🗂️ Inbox + message thread — split-view, URL-driven → 🔔 Modal overlays via Intercepting Routes (Parallel Routes' best friend) → 🔄 Per-slot loading.js & error.js — granular UX control The mindset shift: Stop thinking "one URL = one page". Start thinking "one layout = multiple independent route segments". This is what makes Next.js App Router genuinely different from pages/. Are you using Parallel Routes in production? Drop your use case 👇 https://lnkd.in/g7G4bmTs #Nextjs #React #AppRouter #Frontend #WebDev #AIEngineering

I’m excited to share my latest project: a high-performance Campaign Management System designed for modern advertising agencies. Building digital products for agencies requires a balance of speed, security, and intuitive UX. For this assessment, I focused on creating a scalable Full-Stack solution that handles live campaign metrics and AI-driven creative workflows. Key Technical Highlights: * Full-Stack Architecture: Built with React 18, Node.js, and PostgreSQL. * Data Visualization: Integrated interactive 30-day performance trends using Recharts. * AI-Assisted Workflows: Developed a multi-step Brief Builder with a simulated AI service for rapid creative direction. * Security & Integrity: Implemented JWT Authentication, API Rate Limiting, and Soft Deletes to protect sensitive agency data. * Performance: Optimized rendering using custom hooks (useDebounce) and React optimization patterns. I’m always looking for ways to bridge the gap between complex data and user-friendly interfaces. GitHub Repository: [https://lnkd.in/dJd8nFpH] Ameen Alam Junaid Ali Hafiz Ali Ahmed Faisal Ilyas Faisal ilyas Bilal Fareed Fahad Khan #FullStackDeveloper #ReactJS #NodeJS #WebDevelopment #AIIntegration #PostgreSQL #SoftwareEngineering #Portfolio

🚀 From Idea to Interface—Progress You Can See. #Day2 of building DataVault—and today’s milestone feels real. Alhamdulillah, I’ve successfully converted the entire UI into working code using React and Tailwind CSS. What started as a concept is now a fully functional front-end with a working dashboard. 💻 What’s done: • Complete UI implementation using React + Tailwind CSS • Clean, responsive design now fully interactive • Dashboard functionality is up and running smoothly This is a big step—because now DataVault isn’t just an idea or a design… it’s something you can actually use. 🔐 What’s next: My next focus is implementing authentication to make the platform secure and accessible for real users. The goal is to ensure anyone can safely use DataVault to manage their data with confidence. ⏳ The 7-Day Challenge continues… I’m confident that within the next 2 days, this will evolve into a fully working application. 🤝 I’d love your input: If you have suggestions, features you’d like to see, or feedback—please share. Your insights can help shape this into something truly valuable. Let’s keep building in public. Day 7 is getting closer. 🚀 #BuildInPublic #WebDevelopment #ArtificialIntelligence #SaaS #ReactJS #TailwindCSS #JWT #DataSecurity #Developers #TechJourney #NodeJS #Typescrit #JavaScript #vercel #framermotion

🚀 How to Optimize API Calls in React (Properly Explained) Many React apps become slow not because of UI… But because of inefficient API calls ⚠️ Let’s fix that 👇 ❌ Without Optimization • Multiple unnecessary API calls • Same data fetched again & again • Slow UI & poor performance • High server load ✅ With Optimization • Only required API calls • Cached & reused data • Faster UI response • Better user experience 🧠 Best Practices to Optimize API Calls 🧩 1. Fetch Only What You Need → Avoid large payloads ✔ Request specific fields only ⚡ 2. Use Caching (React Query / SWR) → Don’t refetch same data ✔ Automatic caching & background updates 🔁 3. Avoid Duplicate Requests → Store data globally (context/store) ✔ Prevent unnecessary API calls ⌛ 4. Debounce & Throttle Inputs → Reduce API calls while typing ✔ Perfect for search & filters 📄 5. Pagination / Infinite Scroll → Load data in chunks ✔ Better performance & UX ❌ 6. Cancel Unnecessary Requests → Abort old requests when new ones trigger ✔ Saves bandwidth 🔗 7. Batch API Requests → Combine multiple calls into one ✔ Faster & efficient 🎯 8. Conditional Fetching → Call API only when needed ✔ Avoid useless calls 🔄 9. Background Refetching → Keep UI fast + data fresh ✔ Show cached data instantly ⚡ 10. Use Proper HTTP Methods → Follow REST best practices ✔ Efficient API design 🔥 Real Impact ✔ Faster applications ✔ Better UX ✔ Reduced server cost ✔ Scalable frontend 🧠 Golden Rule: 👉 Don’t fetch more. Fetch smarter. 💬 Which technique improved your app performance the most? #React #Frontend #WebPerformance #API #JavaScript #WebDevelopment #Coding #SoftwareEngineering

🚀 Dashboard Creation in  Next-Gen Data Visualization SaaS Application 😊 What if you could build dashboards with a lightweight SaaS product — just drag, resize, plug in APIs, and fully configure each panel your way? That’s exactly what I’ve been building. 👇 🎥 Watch this in action (drag, resize, real-time updates) ⚡ What this platform can do 🌐 Create dashboards using multiple REST APIs 📊 Multiple chart types (Line · Area · Bar · Pie · Radar · Table) 🖱️ Drag & drop panels freely 📐 Resize panels — charts adapt instantly 🎯 Dynamic field mapping (X/Y) 🔄 Seamless edit mode ↔ view mode ⚡ Performance upgrades : ⚡ Next.js PPR (Partial Pre-Rendering) ⚡ Streaming with Suspense ⚡ Smart caching 👉 Instant dashboard shell load 👉 Progressive data streaming 👉 Smooth interactions 🧠 Why this matters Dashboards shouldn’t feel slow or rigid. The goal is: 👉 Instant feedback 👉 Smooth UX 👉 Real-time feel 🧰 Tech Stack : Next.js (App Router + PPR) · React · TypeScript Prisma · PostgreSQL · Redux · Context API Recharts · react-grid-layout · Tailwind · shadcn/ui · Zod 🔮 What’s next : 🔐 Authentication & authorization (Better-Auth) 💾 Persist dashboards per user 🔌 More data sources 🎨 Advanced customization 🌍 Public launch Still building. Not stopping. 💪 Drop a 🔥 if you want early access or a live demo of Nextlytics #NextJS #SaaS #BuildInPublic #React #Dashboard #DataVisualization #WebDevelopment #Performance #FullStack #Nextlytics

I thought my cart logic was fine…until it started breaking everything. While building my ecommerce project, I made a very common mistake: I stored the entire product object inside the cart. At first, it felt easy and intuitive. But as the app grew, problems started piling up. 💥 What went wrong? • Same product duplicated multiple times • Cart data became outdated when product info changed • localStorage got unnecessarily heavy • Updating quantity turned into messy logic At that moment, I realized: I wasn’t designing a system — I was just storing data. 🧠 The turning point I refactored my cart to a normalized structure: { productId, quantity } And everything changed. ✅ What improved instantly • Clean, minimal state • No duplication • Always synced with latest product data • Simpler, predictable logic ⚡ Then I hit a performance issue… To render the cart, I needed product details again. My first approach: products.find(p => p.id === item.productId) Looks harmless, right? But inside .map() → O(n²) 🔥 The upgrade I introduced a product lookup map: const productMap = Object.fromEntries( products.map(p => [p.id, p]) ); Now rendering becomes: const cartWithDetails = cart.map(item => ({ ...productMap[item.productId], quantity: item.quantity })); 👉 O(1) lookup 👉 Faster rendering 👉 Cleaner separation of logic 🐞Bonus bug I faced I started seeing {} inside my wishlist. After debugging: 👉 I was accidentally passing undefined instead of productId Fix: • Added input validation • Cleaned localStorage • Enforced strict structure 📌 Biggest lesson Don’t store what you can derive. This small architectural change made my project feel much closer to real-world systems. Still learning. Still building. 🚀 If you’ve worked on cart systems before— how did you structure yours? #CodingJourney #WebDevelopment #FrontendDevelopment #JavaScript #NextJS

I made a classic frontend mistake… and it cost me time. While building a student performance dashboard, I created separate components for different data (ERP, OEP, etc.). It worked… until I added performance graphs. Suddenly: Logic had to be duplicated Every new feature needed multiple implementations Maintenance became messy That’s when I realized: 👉 The problem wasn’t my components 👉 The problem was my data So I changed the approach. Instead of adapting UI for every data, I thought of a normalization layer. Now: All data is converted into a common format One component handles everything Features like charts work universally Result: ✔ Less code duplication ✔ Cleaner architecture ✔ Easier scalability Big takeaway: Don’t build multiple UIs for multiple data formats Build one UI and normalize the data Sometimes you don’t learn something new… You just understand it properly. #Frontend #ReactJS #CleanCode #SystemDesign #WebDevelopment