Prevent Lost Form Data with a Simple Hook

⚡ 𝐏𝐚𝐠𝐢𝐧𝐚𝐭𝐢𝐨𝐧 𝐯𝐬 𝐋𝐚𝐳𝐲 𝐋𝐨𝐚𝐝𝐢𝐧𝐠 — 𝐌𝐨𝐬𝐭 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐂𝐨𝐧𝐟𝐮𝐬𝐞 𝐓𝐡𝐞𝐬𝐞 They sound similar. They're not the same thing. Here's the difference every developer needs to understand 👇 📦 𝐏𝐚𝐠𝐢𝐧𝐚𝐭𝐢𝐨𝐧 — A Data Strategy Pagination is a backend/API concern. It divides data into chunks and controls how much data is fetched per request. The server decides how records are returned. 🖥️ 𝐋𝐚𝐳𝐲 𝐋𝐨𝐚𝐝𝐢𝐧𝐠 — A UI/UX Strategy Lazy loading is a frontend concern. It controls when content is loaded based on user behavior — scrolling, visibility, or interaction. The browser decides when to trigger the next fetch. 🤝 They Work Together — Not Against Each Other Instagram's infinite scroll = Lazy Loading (frontend detects scroll) + Cursor Pagination (backend returns next batch) 💡 Rule of Thumb: Use pagination to optimize your API. Use lazy loading to optimize your UX. Use both together to build production-ready apps. 🚀 Have you ever mixed these two up early in your career? Comment below 👇 #WebDevelopment #Frontend #BackendDevelopment #SoftwareEngineering #API #SystemDesign #JavaScript #ReactJS #Programming #100DaysOfCode #CodingTips #UIUXDesign #TechCommunity #Developer #CleanCode #mitprogrammer

𝗦𝗲𝗻𝗶𝗼𝗿 𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀 — 𝟬𝟯/𝟭𝟬   Optimistic UI = Local Transactions We don’t wait for the database. We predict it. When a user clicks “like”, “add to cart”, or “follow”  the UI updates instantly, before the server confirms anything. That’s optimistic UI. Under the hood, this behaves very similar to a local transaction: • apply change immediately (optimistic update)   • send request to server   • commit if success   • rollback if failure  If this sounds familiar, it should. This is conceptually similar to: • database transactions (commit / rollback)   • eventual consistency models   • client-side write buffering  But there’s one key difference: The user is watching every step. You’re not optimizing for correctness alone. You’re optimizing for perceived correctness. That creates a trade-off: • better UX → instant feedback   • higher complexity → rollback, conflicts, edge cases  And when it breaks, it breaks visibly. Optimistic UI is powerful. But it turns your frontend into a stateful system that must handle failure gracefully. Next → Eventual Consistency in the UI Curious: Where has optimistic UI bitten you the most — rollback logic or conflicting updates? #FrontendEngineering #SoftwareEngineering #SystemDesign  #UserExperience #DistributedSystems #JavaScript  #ReactJS #WebPerformance #SeniorFrontendPatterns

Web UI development might have just fundamentally changed. I just caught up on the latest Code Report, and Changlu (former React core team & Midjourney engineer) dropped something massive: Pretext. If you've ever built a text-heavy UI - like a virtualized list or a masonry layout - you know the classic performance bottleneck. Every time the browser needs to figure out how tall a paragraph is, it triggers a layout reflow. This is historically one of the most expensive operations a browser can perform. Pretext is a fast, accurate, and comprehensive text measurement library written in pure TypeScript that completely bypasses this issue. Here is why it is such a foundational shift: Zero DOM Reflows: It utilizes the Canvas API to calculate the exact pixel width of any string outside the DOM. Custom Line-Break Logic: It accurately calculates height by handling the complex line-break rules across all browsers and languages. Clean API: You simply use prepare to cache segment widths and layout to instantly get the total height and line count. As someone working deep in the AI space, what fascinated me most was how Changlu solved the near-impossible task of writing that cross-browser line-break algorithm. He deployed AI models in a recursive testing loop - having them write the logic, test it against actual text in real browsers, compare the results, and refine it over weeks until it was perfectly solid. It is a brilliant example of applying AI to solve complex, deterministic infrastructure problems to build better developer tools. The browser doesn't have to own text measurement anymore. I highly recommend checking out Pretext if you are building data-heavy interfaces! #WebDevelopment #Frontend #TypeScript #ArtificialIntelligence #SoftwareEngineering #WebPerformance #DeveloperTools #Pretext

Built and deployed a Weather Dashboard. This project fetches real-time weather data using the Fetch API and displays it with a clean, responsive UI. Features: * Search weather by city * Current location using Geolocation API * Search history with localStorage * Loading states and basic animations * Error handling for invalid inputs Tech: JavaScript, Fetch API, HTML, CSS, Vite JASIQ Labs Live: https://lnkd.in/dJR2SX2h GitHub: https://lnkd.in/dpych_QJ This helped me improve my understanding of APIs, async JavaScript, and frontend UX. Feedback is welcome. #javascript #webdevelopment #frontend #project

Ever tried fixing something that looked like a simple UI issue… but turned into a full-stack puzzle? 😄 Recently, I faced one such problem with image aspect ratios in a market feed. 🎯 The Starting Point We had a clean setup: 👉 Admin selects ratio: 16:9, 4:3, 1:1, 9:16 👉 Frontend renders based on that Simple, right? --- 😅 Reality Hit Then came real-world images: - Charts 📊 - Screenshots 📱 - Random uploads And suddenly: - Important parts were getting cropped - Some images looked stretched - Feed consistency broke --- 🧠 First Thought “Okay, let’s calculate ratio on frontend using "Image.getSize()"” ✔ Works ❌ But async → slight flicker ❌ Not ideal for lists --- 🔄 Next Iteration (Better) “Let’s fix it at the source” 👉 On admin upload: - Used "img.onload" - Calculated actual ratio (width / height) - Sent that to backend Now new posts were perfect ✅ --- 🚨 Plot Twist Old posts already existed with: "9:16", "4:3" And not all images actually matched those ratios 😬 So now I had two worlds: - 🟢 New posts → correct ratio - 🟡 Old posts → unreliable ratio --- ⚖️ Final Strategy (The Real Solution) Instead of choosing one approach, I combined both: 👉 If backend gives valid numeric ratio → use it directly (fast, no flicker) 👉 If backend gives old string ratio ("9:16") → fallback to "Image.getSize()" (only when needed) --- 💡 What Changed - No more distorted images - Minimal flicker (fallback is conditional) - Backward compatibility maintained - System became smarter, not heavier --- 🧠 Biggest Learning «“Good systems don’t assume data is perfect — they adapt to it.”» Also: - Fix problems as early as possible (admin/backend) - Keep frontend efficient, not overloaded - Handle legacy data like a real product, not a side case --- What looked like a small UI fix turned into a lesson in: 👉 data flow 👉 backward compatibility 👉 performance trade-offs --- Curious — how do you handle image rendering inconsistencies in your apps? #reactnative #frontend #engineering #softwaredevelopment #mobiledev #learning #performance #buildinpublic

Not every assessment feels like a real product build — this one did. As part of a screening proces, I worked on a Finance Tracking Dashboard designed to go beyond basic CRUD and focus on a clean, intuitive user experience. Instead of just “making it work”, I focused on: • Structured and scalable component design • Smooth interactions and modern UI patterns • Meaningful insights from transaction data TechStack: React • Tailwind CSS • Context API The goal was simple — build something that feels like an actual dashboard, not just an assignment. A great experience blending logic with design. Github Link : https://lnkd.in/dNaAS8NS #React #FrontendDevelopment #UIUX #TailwindCSS #Zorvyn #BuildInPublic

🚀 Analyzed Performance of Appwrite Dashboard — Found a MAJOR Issue 🏷️ 🧠⚡💣 #Frontend #Performance #OpenSource 💥 I recently ran a Lighthouse audit on the dashboard of Appwrite(open-source backend platform) 👉 Result? ⚠️ Performance Score: 53 👉 Looks “okay” on surface… but the real story is deeper 👇 🔍 Key Findings 🟢 Good News ✔️ First Contentful Paint → 1.3s ⚡ ✔️ Largest Contentful Paint → 1.5s ⚡ ✔️ Layout Shift → 0.002 ✅ 👉 Page appears fast 🔴 Real Problem (CRITICAL) 💥 Total Blocking Time: 13,140 ms 💀 👉 This means: ❌ UI loads visually ❌ BUT becomes unresponsive for seconds 👉 In simple terms: 💬 “User sees the app… but can’t use it” 🧠 What’s Causing This? From deeper analysis 👇 🔥 Main thread work → 22.5 seconds 🔥 JS execution time → 8.6 seconds 🔥 20 long blocking tasks 👉 Translation: 💥 Too much JavaScript → blocking interaction ⚔️ Why This Matters 👉 This is NOT a cosmetic issue 💥 It directly affects: User experience 😤 Dashboard usability 📉 Perceived product quality 💔 🚀 What I’m Doing Next 👉 Breaking down: ⚡ Where JS time is going ⚡ Which components are heavy ⚡ What’s causing long tasks 👉 And then: 💥 Fixing it using Code splitting Render optimization Better task scheduling 🧠 My Focus 👉 I’m currently working on: 💥 Frontend Performance Optimization 💥 Debugging Real Production Issues 💥 Improving System Design 📢 Follow Along I’ll be sharing: 👉 What I fix 👉 How I fix 👉 Before vs After metrics 💬 If you’ve worked on performance-heavy dashboards, I’d love to hear what issues you’ve faced 👇 #️⃣ #React #WebPerformance #Lighthouse #FrontendEngineering #BuildInPublic

📑 Knowledge Base Platform XX 🐦🔥 Public Articles Pagination In this stage I implemented pagination for public articles to improve performance and user experience when working with large datasets. The goal was to improve pagination logic to the backend and keep the frontend lightweight and scalable. On the backend, I extended services and controller with page and limit parameters to support paginated queries. On the frontend, I introduced a PaginatedResponse type including total, page, and pages, along with ArticleQueryParams to handling query parameters. Store Logic was updated to include pagination metadata and pass query params to the API during filtering. I also created a reusable BasePagination component with navigation controls (previous, next, page number) and integrated it into the articles page. Pagination state is synchronized with the URL, ensuring consistency between navigation, filters, and data fetching. Result: Scalable pagination system for public articles: ➜ Backend-driven pagination using page and limit; ➜ Fully synchronized with filters and URL; ➜ Reusable pagination component; ➜ Improved performance and structured data handling. 📎 Repo: https://lnkd.in/dnuCveCa Here are the previous parts:  🦜 Admin Dashboard Summary Cards https://lnkd.in/d8wKMbTt 🪻 Hashtag Filtering & URL Sync  https://lnkd.in/dcUhgbdi #frontend #vue #pinia #javascript #webdevelopment #fullstack #pagination #ux #developer #opentowork 

Lately I’ve been cleaning up how I handle filters in my React dashboards, and this small pattern made a big difference. Instead of keeping filters only in state, I started syncing them with the URL (query params)… and honestly, it just feels right. 🔹 You can refresh the page and keep your filters 🔹 You can share the exact view with someone 🔹 Back/forward navigation actually works But there’s one catch - if you update the URL on every keystroke… things get messy fast. So the trick is simple: 💡 Debounce the input, not the URL What I’m doing now With React Router: const [input, setInput] = useState(""); const debounced = useDebounce(input, 500); useEffect(() => { setSearchParams({ search: debounced }); }, [debounced]); Or with use-query-params (which I like more for complex filters): const [query, setQuery] = useQueryParam("q", StringParam); const [input, setInput] = useState(query || ""); const debounced = useDebounce(input, 500); useEffect(() => { setQuery(debounced); }, [debounced]); Why this feels better Before, every single keystroke was updating the URL, which meant a flood of API calls and a UI that felt a bit jumpy and unstable. It worked, but it never really felt smooth. Now, typing feels much more natural. The URL stays clean and only updates when it actually matters, and overall state management is just easier to reason about. It’s one of those subtle changes that makes the whole experience feel more polished. It’s one of those small improvements that makes your dashboard feel much more polished. Curious if others are doing something similar or using a different approach #React #Frontend #WebDevelopment #JavaScript #UX #Performance #SoftwareEngineering #ReactJS #FrontendDevelopment #CodingTips #DevTips #WebApps

🚀 React Suspense — Handle Loading UI Like a Pro You’ve implemented lazy loading… 👉 But what happens while the component is loading? That’s where React Suspense comes in. 💡 What is Suspense? Suspense lets you: 👉 Show a fallback UI 👉 While waiting for something to load ⚙️ Basic Example import React, { Suspense, lazy } from "react"; const Dashboard = lazy(() => import("./Dashboard")); function App() { return ( <Suspense fallback={<div>Loading...</div>}> <Dashboard /> </Suspense> ); } 👉 Displays fallback until component loads 🧠 How it works ✔ Component is lazy-loaded ✔ Suspense “waits” for it ✔ Shows fallback UI ✔ Renders component when ready 🧩 Real-world use cases ✔ Lazy loaded routes ✔ Large dashboards ✔ API data (with frameworks) ✔ Component-level loading states 🔥 Why Suspense Matters 👉 Without Suspense: ❌ Blank screen or broken UI 👉 With Suspense: ✅ Smooth loading experience ✅ Better UX ⚠️ Common Mistake // ❌ Forgetting fallback <Suspense> <Dashboard /> </Suspense> 👉 Causes rendering issues 🔥 Best Practices ✅ Always provide meaningful fallback UI ✅ Use skeleton loaders (better UX) ✅ Combine with lazy loading ❌ Don’t overuse nested Suspense unnecessarily 💬 Pro Insight (Senior-Level Thinking) 👉 Suspense is not just for loading… 👉 It’s a foundation for async UI in React 📌 Save this post & follow for more deep frontend insights! 📅 Day 28/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #PerformanceOptimization #WebDevelopment #SoftwareEngineering #100DaysOfCode 🚀