Next.js Fundamentals: File-Based Routing, Dynamic Routing & More

⚡ Day 4 of 30: Mastering useState – The Heartbeat of Interactive React Yesterday I learned how to pass data down. Today I learned how to make components remember and respond. Enter useState — the hook that gives functional components memory. 🧠 What I Internalized Today: 1️⃣ Props vs. State Props are read‑only configuration from parents. State is internal, mutable data the component owns. This distinction is fundamental to React's predictable data flow. 2️⃣ State Triggers Re‑renders Calling setState schedules a re‑render. React diffs the Virtual DOM and surgically updates only what changed. Efficient and elegant. 3️⃣ Immutability is Non‑Negotiable Direct mutation (array.push(), obj.name = 'x') will not trigger a re‑render. Always create a new reference using the spread operator (...) or methods like .map() / .filter(). 4️⃣ Multiple States > One Giant Object Following the Single Responsibility Principle: separate useState calls for independent values make code cleaner and re‑renders more predictable. 5️⃣ Functional Updates for Stale Closures When new state depends on previous state, use the callback form: setCount(prev => prev + 1). This ensures you're always working with the latest snapshot. 🛠️ Today's Builds (All Interactive): ✅ Counter App – Increment, decrement, reset. The classic. ✅ Color Toggler – Conditional styling based on boolean state (Light/Dark mode). ✅ Controlled Form – Inputs fully synchronized with React state. ✅ Cart Item Quantity Changer – Updating nested object state with the spread operator. ✅ Todo List (Mini Build) – Full CRUD operations on an array state (add, toggle complete, delete, remaining count). 📁 GitHub Streak: Day 4 ✅ Every day's code is committed, documented, and pushed. This repository is becoming a living portfolio of deliberate React practice. Next Up: Day 5 – Events & Handlers. Deepening interactivity! #ReactJS #useState #WebDevelopment #Frontend #JavaScript #30DaysOfReact #LearningInPublic #ReactHooks #CodeNewbie #StateManagement

🚀 Understanding useMemo vs useCallback in React — Simplified! If you're optimizing React performance, you've probably seen: 👉 useMemo 👉 useCallback They look similar… but solve different problems. 💡 What is useMemo? 👉 Memoizes a value const result = useMemo(() => { return expensiveCalculation(data); }, [data]); ✅ Recomputes only when dependencies change ✅ Avoids expensive recalculations 💡 What is useCallback? 👉 Memoizes a function const handleClick = useCallback(() => { console.log("Clicked"); }, []); ✅ Keeps function reference stable ✅ Prevents unnecessary re-renders ⚙️ Key Difference 🔹 useMemo → returns a value 🔹 useCallback → returns a function 👉 Think of it like: useMemo → “cache result” useCallback → “cache function” 🧠 Why it matters React re-renders can cause: Expensive calculations New function references Unnecessary child re-renders 👉 These hooks help optimize that 🧩 Real-world use cases ✔ useMemo: Heavy calculations Filtering/sorting large data ✔ useCallback: Passing functions to child components Preventing re-renders with React.memo 🔥 Best Practices (Most developers miss this!) ✅ Use only when needed (not everywhere) ✅ Combine with React.memo for optimization ✅ Keep dependencies accurate ❌ Don’t overuse (can hurt performance) ⚠️ Common Mistake // ❌ Overusing memoization const value = useMemo(() => count + 1, [count]); 👉 Not needed for simple calculations 💬 Pro Insight 👉 useMemo = Optimize computation 👉 useCallback = Optimize re-renders 📌 Save this post & follow for more deep frontend insights! 📅 Day 15/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #PerformanceOptimization #SoftwareEngineering #100DaysOfCode 🚀

Day 3 of my Next.js Journey 🚀 Today was all about understanding how data flows inside a Next.js application—and honestly, this is where things start to feel real. Here’s what I explored: • Data Fetching Flow Learned the complete lifecycle of how data moves from server to UI • Fetching Data in Server Components This was powerful—fetching data directly on the server without extra client-side complexity • JSON Server Setup Created a temporary backend using a JSON server to simulate real API data • Caching Strategies (SSR, SSG, ISR) Understood how different rendering methods impact performance and freshness of data • generateStaticParams Learned how Next.js pre-generates dynamic routes at build time • Verifying Static Generation Checked how static params actually work behind the scenes What really clicked today is how Next.js gives control over when and where data is fetched. It’s no longer just about calling APIs—it’s about optimizing performance, scalability, and user experience. This part feels a bit challenging, but also the most exciting because it connects frontend with backend thinking. Slowly moving from “just coding” to actually understanding how systems work ⚙️ #NextJS #DataFetching #WebDevelopment #LearningInPublic #SoftwareEngineering

Day 17/100: Reflections on Building the Foundation of the Web The journey to becoming a Full-Stack Software Engineer is often described as a marathon, not a sprint. Over the past several weeks, I have been immersed in a rigorous 100-Day Full-Stack Challenge, and as I cross the threshold of Day 17, the importance of a "foundation-first" mindset has never been clearer. My focus has been split between two critical pillars: HTML5 and CSS3. While these are often viewed as "entry-level," mastering them at a Senior level requires a deep dive into semantic architecture, accessibility (A11Y), and performance optimization. Phase 1: HTML & Semantic Architecture I spent the first ten days deconstructing how we structure data for the browser. Beyond simple tags, I focused on SEO-friendly semantic elements and complex form handling. The highlight was Day 9’s mini-project, where I built a production-ready landing page that prioritized load speed and screen-reader compatibility. Phase 2: Modern CSS & Responsive Layouts Days 11 through 17 shifted the focus to the visual layer. Transitioning from the "Box Model" fundamentals to advanced CSS Grid and Flexbox implementations allowed me to create layouts that are fluid and resilient. I’ve spent significant time lately mastering CSS Specificity and Advanced Selectors—tools that are essential for maintaining large-scale, clean stylesheets in professional environments. The Road Ahead While I have hit a period of reflection after Day 17, the roadmap remains ambitious. The next immediate goal is to finalize the CSS phase with advanced animations and preprocessors before diving headfirst into JavaScript (ES6+). This upcoming 10-day block will be the true test of logic, as I move from static layouts to dynamic, functional web applications. Consistency is the greatest challenge in any #100DaysOfCode journey. Resuming this challenge means more than just writing code; it’s about documenting the "why" behind every technical decision. I’m looking forward to integrating these front-end skills with Node.js and MongoDB in the weeks to come. #FullStackDevelopment #WebDevelopment #BuildInPublic #HTML5 #CSS3 #CodingJourney #SoftwareEngineering #CareerGrowth #LearningChallenge

There is a distinct moment in every developer's career when they stop seeing TypeScript as an annoying chore and start seeing it as the ultimate safety net. I remember the early days of hunting down vague runtime errors that completely broke a user interface, simply because a database schema changed and the frontend was left guessing. When you are building and maintaining the entire architecture, relying on hope to sync your data isn't a sustainable strategy. That is why establishing strict, end-to-end type safety has become a non-negotiable part of my workflow. When your frontend and backend speak the exact same language, everything moves faster. Here is how that plays out in a modern stack: * **The Backend Contract:** Structuring an API with **NestJS** alongside a robust **SQL** database forces you to define your data rigidly. Whether I am using **PostgreSQL** for heavy production environments or spinning up **PGLite** for rapid local iteration, I know exactly what shape my data is in before it ever leaves the server. * **The Seamless Bridge:** By sharing those TypeScript interfaces across the stack, the gap between the server and the browser disappears. * **The Frontend Execution:** When **React** and **Next.js** catch data shape errors in the IDE before I even hit save, the development experience completely shifts. I can confidently design complex layouts using **Tailwind CSS** and **shadcn/ui**, knowing the props feeding those components are exactly what the interface expects. Type safety is rarely just about preventing bugs. It is about developer velocity. It gives you the confidence to refactor aggressively, update UI components, and scale features without the constant, lingering fear that you just broke an obscure page on the other side of the app. What is your current approach to keeping your backend and frontend types in sync? Are you using a monorepo structure to share types, or generating schemas dynamically? Let's talk architecture below. 👇 #TypeScript #FullStackDevelopment #Nextjs #NestJS #SoftwareEngineering #WebDevelopment #FrontendArchitecture

🚀 Introducing Fineact - a tiny reactive layer for React (and beyond) While building with React, I kept hitting the same friction points: • State updates feel heavier than necessary • Unnecessary re-renders affect performance • Simple reactive flows need extra boilerplate • Sharing state outside React is not straightforward React is great for UI, but fine-grained reactivity is not its core focus. 💡 That’s where Fineact fits in. Fineact is NOT a replacement for React. It is an addon - a lightweight reactive layer that works alongside React and can also be used completely outside of it. 🧠 What does it solve? Fineact enables fine-grained reactivity so that: • Only the exact parts depending on state update • Fewer unnecessary re-renders • Simpler and more predictable state flow • Ability to manage reactive state outside components ⚡ Inspiration Inspired by: • SolidJS - fine-grained reactivity • Preact - simplicity and performance 🔥 Where can it be useful? • Optimizing React state updates • Sharing state across components without prop drilling • Managing state in services or plain JavaScript • Event-driven or subscription-based logic • Lightweight alternative for simple state management needs • Performance-heavy UIs like dashboards or real-time apps • Building reusable libraries or SDKs 🎯 Goal Not to compete with React Not to replace your stack But to make state management simpler, more precise, and easier to reason about. 🔗 GitHub: https://lnkd.in/gtixUCrA 📦 npm: https://lnkd.in/geJs8Y8G 🤝 Open for contributions - feedback, ideas, and PRs are welcome! #reactjs #javascript #opensource #frontend #webdevelopment #npm #buildinpublic #programming

🚀 𝐃𝐚𝐲 2/30 – 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐒𝐞𝐫𝐢𝐞𝐬: 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 (𝐓𝐡𝐞 𝐇𝐞𝐚𝐫𝐭 𝐨𝐟 𝐍𝐨𝐝𝐞.𝐣𝐬) If you understand this, you understand Node.js. Most developers say Node.js is single-threaded… 👉 But still wonder: “How does it handle multiple requests?” The answer = 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 🔁 💡 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩? It’s a mechanism that: ➡ Continuously checks if tasks are completed ➡ Moves completed tasks to execution ➡ Ensures Node.js doesn’t block 🧠 𝐇𝐨𝐰 𝐢𝐭 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐰𝐨𝐫𝐤𝐬 (𝐬𝐢𝐦𝐩𝐥𝐢𝐟𝐢𝐞𝐝): Call Stack → Executes code Web APIs / System → Handles async tasks (I/O, timers, API calls) Callback Queue → Stores completed tasks Event Loop → Pushes them back to stack when ready 🔁 𝐑𝐞𝐚𝐥-𝐰𝐨𝐫𝐥𝐝 𝐟𝐥𝐨𝐰: 𝘤𝘰𝘯𝘴𝘰𝘭𝘦.𝘭𝘰𝘨("𝘚𝘵𝘢𝘳𝘵"); 𝘴𝘦𝘵𝘛𝘪𝘮𝘦𝘰𝘶𝘵(() => { 𝘤𝘰𝘯𝘴𝘰𝘭𝘦.𝘭𝘰𝘨("𝘛𝘪𝘮𝘦𝘰𝘶𝘵 𝘥𝘰𝘯𝘦"); }, 0); 𝘤𝘰𝘯𝘴𝘰𝘭𝘦.𝘭𝘰𝘨("𝘌𝘯𝘥"); 👉 Output: Start End Timeout done ❗ Even with 0ms, it waits — because Event Loop prioritizes the call stack first. ⚡ Why this matters in real projects Let’s say: 100 users hit your API Each API calls DB + external service Without event loop: ❌ Requests block each other With Node.js: ✅ Requests are handled asynchronously ✅ System stays responsive 🔥 From my experience: In production systems, long-running operations (like file processing, invoice parsing, etc.) should NOT sit in the event loop. 👉 We offloaded them to async queues (Service Bus / workers) Why? ✔ Keeps event loop free ✔ Avoids blocking requests ✔ Improves scalability ⚠️ Common mistake developers make: while(true) { // heavy computation } ❌ This blocks the event loop → entire app freezes ✅ Takeaway: Event Loop is powerful, but: ✔ Keep it light ✔ Offload heavy tasks ✔ Design async-first systems 📌 Tomorrow (Day 3): Callbacks → Why they caused problems (Callback Hell) #NodeJS #EventLoop #JavaScript #BackendDevelopment #SystemDesign #FullStack

🚫 Stop treating Next.js and NestJS as competitors This confusion is everywhere — and it leads to poor system design. Here’s the reality 👇 🔷 **Next.js** Built for the **frontend layer** • React-based framework • SSR / SSG / ISR for performance • SEO-friendly apps • Handles UI + light backend (API routes) 🔶 **NestJS** Built for the **backend layer** • Node.js framework for scalable APIs • REST / GraphQL support • Clean architecture (Controllers, Services, Modules) • Handles business logic, auth, data flow --- 💡 **The Real Difference** 👉 Next.js = What users see 👉 NestJS = What powers everything behind the scenes --- ⚡ **When to use what?** Use Next.js when: • You’re building UI-heavy apps • You need SEO (web apps, SaaS, dashboards) Use NestJS when: • You’re building scalable backend systems • You need structured architecture & complex logic --- 🔥 **Best Stack for Production** Next.js + NestJS Frontend + Backend = Fast ⚡ Scalable 📈 Maintainable 🧠 --- At **SKN Software Labs**, this is our go-to stack for building real-world, high-performance applications. 💬 What’s your stack preference — monolithic or structured backend? #NextJS #NestJS #FullStackDevelopment #WebDevelopment #JavaScript #NodeJS #ReactJS #BackendDevelopment #FrontendDevelopment #SoftwareArchitecture #TechStack #Developers #CleanCode #SKNSoftwareLabs

The Go ecosystem has been missing a first-class Inertia.js adapter. We noticed, so we built one. 🏎️ oullin/inertia-go started as internal infrastructure for a production client project. It solved a real problem — building a modern, reactive frontend on a Go backend without spinning up a separate API and frontend application. Once it worked in production, open-sourcing it was the obvious call. The Go community has given us a lot. This is our contribution back. 🚀 The library is framework-agnostic, fully compliant with the Inertia protocol, and ships with a working port of the official Inertia Kitchen Sink demo — the same app the Inertia.js team uses to showcase every protocol feature. Run it yourself with a single make demo. 🔗 https://lnkd.in/grSVv9ux 🌟 Thanks to Jonathan Reinink and the Inertia.js team for the reference implementation, and to the Laravel community for proving this pattern works at scale. #go #inertiajs #framework #agnostic #laravel #renaissance

✅ We built an Inertia.js adapter for Go, with full protocol compliance, and production-tested it, which started as an internal client project. 🏃🏼➡️ Run the full Kitchen Sink demo locally: `make demo` https://lnkd.in/gJe5gk2e h/t @reinink and the @inertiajs team 🙏 #go #inertia #laravel