Building Movie App Frontend with ReactJS

I wrote the same component 3 times before I realised I only needed to write it once. Days 43–45/100 — 3 days deep into React, and the foundations are finally locking in. Here's everything that clicked this week: 🔹 Fragments — the invisible wrapper React needs a single parent element. But wrapping everything in a <div> pollutes your DOM. <> </> groups your JSX with zero DOM footprint. Clean markup. No ghost divs. No unexpected CSS side effects. 🔹 Map method — lists without the pain In vanilla JS, rendering a list meant loops + manual DOM updates. In React — one .map() call and every item in your array becomes a component. Dynamic. Clean. Automatic. 🔹 Conditional Rendering — 3 tools, 1 goal Making React show the right thing at the right time: • if-else — for complex logic outside JSX • Ternary — clean inline decisions inside JSX • Logical && — show something only when a condition is true Your UI should respond to data — not just display it. 🔹 Passing data via Props Props are how components talk to each other. Parent has data → passes it down → child receives and uses it. Without props, every component is an island. With props, they become a system. 🔹 Destructuring Props Instead of props.name, props.age, props.email everywhere — const { name, age, email } = props. Cleaner. Less repetitive. Readable at a glance. The biggest realisation from these 3 days? A component isn't a fixed UI block. It's a template. Props are the variables. Conditions are the logic. Map is the engine. That's the foundation of almost every React app in production. Day 45 done. 55 to go. 🚀 #100DaysOfCode #ReactJS #MERNStack #WebDevelopment #LearningInPublic #JavaScript #BuildInPublic

 Stop Wasting Re-renders: Debounce vs Throttle Have you ever built a search bar that sends an API request on every keystroke? Or added a scroll listener that suddenly makes the UI feel laggy? If you’re not controlling how often a function runs, you’re leaving serious performance gains on the table. Let’s simplify two powerful techniques every frontend developer should know. 👇 ⏱️ Debouncing — “Wait until things stop” Debouncing delays execution until the user stops triggering the event. Think of it like an elevator. It waits for the last person to enter. If someone else jumps in, the timer resets. The elevator moves only when no one else is coming. Best used for: 🔍 Search inputs (run API call after typing stops) 💾 Auto-saving drafts 📏 Window resize handlers 🌊 Throttling — “Run at a steady rate” Throttling ensures a function runs at most once every X milliseconds, no matter how often the event fires. Think of a dripping faucet. No matter how much water pressure there is, it releases one drop at fixed intervals. Best used for: 📜 Infinite scroll checks 🎮 Game controls 🖱️ Mouse / scroll animations 🔍 Quick Comparison Feature Debounce Throttle Goal Run after activity stops Run at fixed intervals Best for Input-heavy events Continuous events Execution Once (after pause) Multiple times (spaced out) 🛠️ Pro Tip In production, don’t reinvent the wheel. Libraries like Lodash make this extremely simple: import { debounce, throttle } from "lodash"; Or build custom React hooks to keep your components clean and optimized. 💬 Question for developers: Which one do you use more in real projects — Debounce or Throttle? Drop your answer in the comments 👇 #WebDevelopment #ReactJS #JavaScript #FrontendDevelopment #PerformanceOptimization #CodingTips #SoftwareEngineering

🧱 SOLID Principles in React & Next.js — And Why They Actually Matter After years of writing React components that turned into "god components" (we've all been there 😅), I started applying SOLID principles to my frontend code. Game changer. Here's a quick breakdown: S — Single Responsibility: Each component does ONE thing. A <UserCard /> renders user info. It doesn't fetch data, handle auth, AND format dates. Split them up. O — Open/Closed: Build components that are open for extension but closed for modification. Use props, composition, and render props instead of editing core components every sprint. L — Liskov Substitution: If you swap <Button /> for <IconButton />, your UI shouldn't break. Design your component contracts carefully. I — Interface Segregation: Don't pass a massive user object to every component. Give components only the props they need — nothing more. D — Dependency Inversion: Your components shouldn't depend on concrete implementations. Pass services, fetch functions, or hooks as abstractions. This makes testing a joy 🙌 In Next.js specifically, this maps beautifully: → Server Components = pure data-fetching responsibility → Client Components = interaction & UI responsibility → Custom hooks = abstracted business logic Clean code isn't a luxury — it's how teams ship fast and stay sane. What SOLID principle do you find hardest to apply in React? Drop it below 👇 #React #NextJS #CleanCode #SoftwareEngineering #FrontendDevelopment #SOLID #WebDev

https://lnkd.in/d4ZvdajQ — Most people overcomplicate tipping logic, but as a Senior Frontend Engineer, I see it as a masterclass in edge-case handling. 🚀 Building this with TypeScript and Next.js 15 reminded me that even 'simple' tools deserve a robust architectural foundation. 💻 I remember being at a group dinner where 8 people spent five minutes arguing over who owed what. It was awkward and honestly, a solved problem. 🍽️ I built this Tip Calculator to end that friction. Here is a mini-dive into the logic behind it: 1. Input Sanitization: We use controlled components to ensure users don't break the math with non-numeric characters. ⚙️ 2. Real-time Precision: I leveraged Tailwind CSS and shadcn/ui to build a UI that updates as you type, providing instant visual feedback. 3. The Math: Handling floating-point math in JavaScript is notoriously tricky. I implemented rounding strategies to ensure the total is accurate to the cent. 4. Performance: I ran the calculation logic through Vitest using Bun to ensure that edge cases—like zero splitters—don't crash the site. 🧪 5. Workflow: Using Cursor helped me refactor the state management logic for the percentage sliders in record time. 🛠️ It’s not just about the numbers; it’s about making sure the user never has to think twice when the bill arrives. 📈 Everything is optimized for speed because no one wants to wait for a tip calculation to load. ✨ Building tools like this is a great way to keep my fundamental skills sharp while providing real utility. 💡 How do you handle decimal precision and rounding in your own frontend projects? 💬 #TipCalculator #FrontendEngineer #TypeScript #ReactJS #Nextjs #TailwindCSS #WebDev #SoftwareEngineering #Coding #JavaScript #UIUX #CleanCode #DeveloperLife #ProductivityTools #Calculators

🚀 Day 11/30 – useRef Hook (Deep Dive) Today I learned one of the most underrated React Hooks ⚡ 👉 useRef Today I learned: ✅ useRef stores a mutable value that persists across renders ✅ Updating useRef does NOT trigger re-render ✅ Mostly used for DOM access & storing values 💻 Example: import { useRef } from "react"; function InputFocus() { const inputRef = useRef(); const focusInput = () => { inputRef.current.focus(); }; return ( <> Focus </> ); } 🔥 What actually happens behind the scenes: 1️⃣ Component renders → ref object is created 2️⃣ React attaches it to DOM → inputRef.current 3️⃣ Value stays same across renders 👉 No re-render happens when ref changes 💡 useRef vs useState (Important Difference): useState → triggers re-render 🔁 useRef → does NOT trigger re-render ⚡ 💡 Real Use Cases: Focus input fields Store previous values Access DOM elements Avoid unnecessary re-renders ⚡ Advanced Insight: useRef is like a “box” that React does NOT track for rendering. 🔥 Key Takeaway: useRef is not for UI updates — it’s for storing values & accessing DOM without re-render. Are you using useRef or still confused? 👇 #React #useRef #Hooks #FrontendDevelopment #JavaScript #LearnInPublic #CodingJourney

Last quarter I rewrote a major component using Composition API and the code clarity surprised even me. Managing intricate UI states felt like juggling too many balls with the Options API. Data, computed props, watchers all tangled up in one huge file. Switching to the Composition API let me break logic into smaller, focused functions. I created reusable state hooks and kept side effects neatly organized. This made features easier to add and debug without accidentally breaking unrelated parts. For example, I handled multiple async calls and UI loading states by co-locating reactive state and handlers. The component became far more readable and eliminated a bunch of duplicate code. Deploying this in production showed a clear performance bump and reduced bugs reported by QA. If you’re still wrestling with complex UI state in Vue, try moving pieces to composables — it’s a game changer. How have you tackled growing state complexity in your Vue apps? Would love to hear your approaches! 👇 #VueJS #JavaScript #FrontendDev #WebDev #CompositionAPI #CodingTips #CleanCode #DeveloperExperience #CloudComputing #TechDevelopment #VueJS #CompositionAPI #FrontendDevelopment #WebDevelopment #Solopreneur #DigitalFounders #ContentCreators #Intuz

🚀 A clean frontend structure makes a project easier to build, manage, and scale. Here’s a simple frontend folder breakdown 👇 📡 API — Handles requests and communication with the backend. 🖼️ Assets — Stores static files like images, icons, and fonts. 🧩 Components — Contains reusable UI elements used across the app. 🌐 Context — Manages shared global state without prop drilling. 📂 Data — Keeps static data, constants, and mock content. 🪝 Hooks — Holds reusable custom React logic. 📄 Pages — Represents the main screens or routes of the application. 🔄 Redux — Manages complex global state in a predictable way. ⚙️ Services — Contains business logic and app-related operations. 🛠️ Utils — Includes helper functions used in different places. A good folder structure improves readability, teamwork, and scalability. 💡 #Frontend #WebDevelopment #ReactJS #JavaScript #Coding #SoftwareDevelopment #Developer

Day 13 of my 21-day challenge. Today, I took a major leap from Vanilla JS to React and built a dynamic Product Page. This project was all about moving away from monolithic code and embracing the power of components. Live Link: https://lnkd.in/eErxzk3D GitHub: # What it does: 1. Component-Based Architecture: The page is broken down into reusable pieces, making the code clean and scalable. 2. Prop Drilling in Action: Successfully passed data from the main App component down to individual Product components to render details dynamically. 3. Modular Styling: Each component has its own dedicated CSS file, keeping styles scoped and organized (no more CSS spaghetti!). 4. Responsive Design: Used modern CSS techniques to ensure the product grid looks great on both desktop and mobile. # Concepts I practiced: 1. React Functional Components: Understanding how to structure a UI into independent, reusable pieces. 2. Props & Data Flow: Mastering "Prop Drilling" to send data from parent to child components. 3. CSS Modules/Separation: Managing separate stylesheets for better maintainability. 4. Mapping through Data: Using .map() to render a list of products efficiently from an array. 5. Mobile-First Styling: Implementing media queries to ensure a seamless responsive experience. The shift from manual DOM manipulation to React’s declarative approach feels like getting a superpower. It’s no longer about "how" to change the UI, but "what" the UI should look like based on the data. 🚀 Building, breaking, and learning—one component at a time. 💻 #reactjs #frontenddevelopment #webdev #componentbaseddesign #propdrilling #css #responsivewebdesign #learninginpublic #SheriyansCodeSchool

I used to think NestJS decorators were just “fancy syntax”. @Controller @Get @Post Looked clean… but I had no idea what was actually happening behind the scenes. Then I started digging deeper. And things finally started clicking. Decorators in NestJS are not just for readability. They define how your application behaves. @Controller → Turns a class into a route handler @Get → Maps HTTP requests @Injectable → Registers a class for Dependency Injection And that’s where it gets interesting. Dependency Injection is what makes everything work smoothly. Instead of manually creating objects, NestJS does it for you. No tight coupling Better structure Easier testing At first, it felt confusing. “Where is this instance coming from?” “Who is creating this service?” But once you understand DI… You stop writing messy code You start designing systems Now when I see a decorator, I don’t just see syntax. I see architecture. Still learning… but this shift changed how I look at backend development. If you’re learning NestJS, don’t just use decorators. Understand them. That’s where the real power is. #nestjs #nodejs #backend #webdevelopment #softwareengineering #learning

⚛️ 𝗣𝗿𝗲𝘃𝗲𝗻𝘁𝗶𝗻𝗴 𝗨𝗻𝗻𝗲𝗰𝗲𝘀𝘀𝗮𝗿𝘆 𝗥𝗲-𝗿𝗲𝗻𝗱𝗲𝗿𝘀 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁 — 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗨𝘀𝗲 𝗼𝗳 𝗺𝗲𝗺𝗼 & 𝘂𝘀𝗲𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸 In React applications, performance issues often come from repeated re-renders rather than heavy logic. This becomes more noticeable when passing functions as props. 𝗖𝗼𝗺𝗺𝗼𝗻 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 <ChildComponent onClick={() => handleClick(id)} /> A new function is created on every render, causing child components to re-render. 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗙𝗶𝘅 Use useCallback: const handleItemClick = useCallback((id) => { handleClick(id) }, []) Then: <ChildComponent onClick={handleItemClick} /> 𝗖𝗼𝗺𝗯𝗶𝗻𝗲 𝘄𝗶𝘁𝗵 𝗥𝗲𝗮𝗰𝘁.𝗺𝗲𝗺𝗼 export default React.memo(ChildComponent) Now child re-renders only when props actually change. 𝗪𝗵𝗲𝗻 𝗧𝗵𝗶𝘀 𝗛𝗲𝗹𝗽𝘀 𝗠𝗼𝘀𝘁 • Large lists • Dashboard UI • Reusable components • Expensive child rendering • Deep component trees 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗡𝗼𝘁𝗲 Avoid over-optimizing: • Use memo only where needed • Measure before optimizing • Keep code readable Small memoization changes can improve UI responsiveness significantly. 💬 Curious — Do you use memoization by default, or only after noticing performance issues? #ReactJS #Frontend #Performance #JavaScript #WebDevelopment #SoftwareEngineering #DevCommunity