React Hooks Execution Order Explained

🚀 Turning Code into Interaction: My Latest DOM Project I’ve just wrapped up a project that helped me truly understand the power of the Document Object Model (DOM). For this project—Toyo—I focused on creating a seamless, interactive user experience. While HTML/CSS provides the structure and skin, JavaScript is the brain that brings it all to life. Key things I learned/implemented: ✅ Dynamic element manipulation ✅ Efficient event handling for user interactions ✅ Managing UI states through JavaScript Building this was a great exercise in logic and problem-solving. It’s one thing to read about the DOM, but another thing entirely to build a functional UI with it! 🔗 Live Link: https://lnkd.in/gHq2Dqgt 💻 GitHub: https://lnkd.in/gsqR68x6 Special Thanks to - Sarthak Sharma Devendra Dhote Tanishq Sonwane Ritik Rajput #WebDevelopment #JavaScript #Frontend #DOM #CodingJourney #LearningToCode #WebDesign

Just finished building this animated clock using pure HTML & CSS ⏰ No libraries, no frameworks — just core frontend concepts and a lot of practice. Working on small projects like this helps me understand: ✔️ CSS animations ✔️ Positioning & transforms ✔️ UI detailing ✔️ How time-based logic visually represent hoti hai I’m sharing this to document my learning journey and to stay consistent. Learning in public really pushes you to do better every single day. If you’re also learning frontend development or web development in general, let’s connect and grow together 🚀 Your feedback is always welcome — suggestions are appreciated! #HTML #CSS #FrontendDevelopment #WebDevelopment #WebDev #Frontend #CodingJourney #LearningInPublic #BuildInPublic #100DaysOfCode #DeveloperLife #ProgrammerLife #UIUX #CSSAnimation #CodeNewbie #TechCommunity #SelfTaughtDeveloper #DailyCoding #CodeEveryday

𝐒𝐭𝐨𝐩 𝐏𝐫𝐨𝐩 𝐃𝐫𝐢𝐥𝐥𝐢𝐧𝐠! You have a user object at the top of your app, and you end up passing it through 5 different components—Layout, Page, Header, Sidebar—just so a tiny <Avatar /> at the very bottom can use it. By the time you're done, your middle components are "polluted" with props they don't even care about. It makes refactoring a nightmare and testing a chore. Before you reach for a heavy state management library like Redux or Zustand, try a simpler built-in pattern: 𝘊𝘰𝘮𝘱𝘰𝘯𝘦𝘯𝘵 𝘊𝘰𝘮𝘱𝘰𝘴𝘪𝘵𝘪𝘰𝘯. 𝐓𝐡𝐞 "𝐏𝐫𝐨𝐩 𝐃𝐫𝐢𝐥𝐥𝐢𝐧𝐠": <𝐀𝐩𝐩> → <𝐋𝐚𝐲𝐨𝐮𝐭 𝐮𝐬𝐞𝐫={𝐮𝐬𝐞𝐫}> → <𝐇𝐞𝐚𝐝𝐞𝐫 𝐮𝐬𝐞𝐫={𝐮𝐬𝐞𝐫}> → <𝐀𝐯𝐚𝐭𝐚𝐫 𝐮𝐬𝐞𝐫={𝐮𝐬𝐞𝐫} /> 𝐓𝐡𝐞 "𝐂𝐨𝐦𝐩𝐨𝐬𝐢𝐭𝐢𝐨𝐧" 𝐅𝐢𝐱: 𝐏𝐚𝐬𝐬 𝐭𝐡𝐞 𝐜𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭 𝐢𝐭𝐬𝐞𝐥𝐟 𝐚𝐬 𝐚 𝐩𝐫𝐨𝐩 𝐨𝐫 𝐮𝐬𝐞 {𝐜𝐡𝐢𝐥𝐝𝐫𝐞𝐧}. Instead of passing data down, you "lift" the child component up. This means your Header doesn't even need to know the user exists—it just renders whatever you put inside it. Why I've started leaning into this: 𝐂𝐥𝐞𝐚𝐧𝐞𝐫 𝐂𝐨𝐝𝐞: No more "pass-through" props clogging up your components. 𝐓𝐫𝐮𝐞 𝐑𝐞𝐮𝐬𝐚𝐛𝐢𝐥𝐢𝐭𝐲: Your Header is now truly generic. 𝐄𝐚𝐬𝐢𝐞𝐫 𝐓𝐞𝐬𝐭𝐢𝐧𝐠: You can test each piece in total isolation. React isn't just about building components; it's about how you compose them. Keep your components "dumb" and your architecture smart. I'm curious—how many layers of prop drilling do you hit before you force a refactor?  #ReactJS #WebDevelopment #SoftwareEngineering #CleanCode #JavaScript #FrontEnd

🚀 𝐓𝐡𝐞 𝐌𝐨𝐦𝐞𝐧𝐭 𝐑𝐞𝐚𝐜𝐭 𝐂𝐨𝐧𝐭𝐞𝐱𝐭 𝐅𝐢𝐧𝐚𝐥𝐥𝐲 “𝐂𝐥𝐢𝐜𝐤𝐞𝐝” 𝐟𝐨𝐫 𝐌𝐞 I was building a simple dark/light theme feature. Sounds easy, right? Until my component tree started looking like this: App → Layout → Header → Toolbar → Button And I was passing theme through every single level. Even components that didn’t care about the theme had to accept it… just to pass it down. That’s when I realized — this isn’t scalable. This is prop drilling. 🧠 The Turning Point: React Context Instead of threading props manually through the tree, I used the Context API. Conceptually, Context works like a broadcast system: 1️⃣ createContext() → creates a shared container 2️⃣ <Provider> → supplies the value at a higher level 3️⃣ useContext() → consumes it anywhere below No more unnecessary prop forwarding. 🔬 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐃𝐞𝐭𝐚𝐢𝐥 𝐓𝐡𝐚𝐭 𝐌𝐨𝐬𝐭 𝐁𝐞𝐠𝐢𝐧𝐧𝐞𝐫𝐬 𝐌𝐢𝐬𝐬 React compares Provider values using Object.is. If you pass a new object literal like: <𝑃𝑟𝑜𝑣𝑖𝑑𝑒𝑟 𝑣𝑎𝑙𝑢𝑒={{ 𝑡ℎ𝑒𝑚𝑒: "𝑑𝑎𝑟𝑘" }} /> Every render creates a new reference → all consumers re-render. The better approach? Store the value in state Or memoize it This small detail makes a big difference in performance. 🎯 When Context Makes Sense ✔ Theme ✔ Auth state ✔ Language ✔ Global UI configuration But Context isn’t a replacement for props. It’s a tool for shared, cross-cutting state. The real lesson? Good React architecture isn’t about avoiding props. It’s about knowing when to elevate state and when to broadcast it. #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #SoftwareArchitecture #WebDevelopment

🧠 How useRef keeps the previous state value in React In React, components re-render when state changes, but not everything is recreated on every render. useRef gives you a persistent container whose value survives across renders without causing re-renders. 🔑 Important rules to remember useState Triggers a re-render when updated Values are recalculated on every render useRef Persists the same object between renders Updating .current does not trigger a re-render useEffect Runs after the render is committed to the DOM Never runs during rendering 🔄 Step-by-step render lifecycle Initial render count = 0 prevCountRef.current = undefined UI renders: Now: 0 Before: undefined After render useEffect runs prevCountRef.current = 0 After clicking the button setCount(1) is called React schedules a re-render Component re-renders: count = 1 prevCountRef.current = 0 (previous value) UI displays: Now: 1 Before: 0 After this render useEffect runs again prevCountRef.current = 1 (stored for next render) 🧩 Why this works Because the effect runs after rendering, the ref is updated after the UI has already used the old value. This timing allows the ref to act as a “memory” of the previous render. 💡 Mental model State = causes renders Render = reads refs Effect = writes refs ⚠️ Why not use state for this? Using state to store the previous value would: Trigger another re-render Risk infinite render loops Add unnecessary complexity useRef avoids all of that ✅ Final takeaway useRef persists data across renders without re-rendering, and useEffect updates it after render — making it perfect for tracking previous values. #React #ReactJS #JavaScript #ReactHooks #useRef #useEffect #useState #FrontendDevelopment #WebDevelopment #SoftwareEngineering

🎨 Week 6 Project – Dynamic Image Gallery ✨ Error Makes Clever For Week 6, I built a Dynamic Image Gallery using React, focusing on component reusability, state management, and responsive UI design. 🔗 Live Demo 👉 https://lnkd.in/gvm9aJKP ✨ What I built 🖼️ Dynamic image gallery using array of objects 🔁 List rendering with .map() 🧩 Reusable ImageCard component 🌗 Dark / Light theme toggle using useState 📱 Fully responsive grid layout ⚡ Lazy loading images for better performance ✨ Smooth hover effects & transitions 🧼 Clean and scalable React structure 🛠️ Tech Stack • React JS • JavaScript (ES6+) • CSS3 • Unsplash Images 📚 Key Concepts Practiced • Component Composition • Props (Parent → Child data flow) • React Hooks (useState) • Conditional Styling • Event Handling • Responsive Design Principles This project strengthened my understanding of real-world React architecture, reusable components, and UI performance optimization. More features coming soon: search functionality, image modal, filtering & infinite scroll 🚀 #ErrorMakesClever #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript

Headline: 🚀 Small Code, Big Impact: Playing with CSS Pseudo-classes! Body: I’ve been diving deeper into CSS transitions and the power of the :hover pseudo-class. It’s amazing how a few lines of code can turn a static layout into an interactive experience. In this project, I focused on: Layering: Using overflow: hidden to contain hidden elements. Smooth Motion: Implementing transition for that premium feel. Transformations: Utilizing translateX to slide content dynamically on hover. Web development is all about the details. What’s your favorite CSS trick for improving UX? #WebDevelopment #CSS #HTML #Frontend #CodingJourney #Programming #UIUX #LearningToCode #Amarjeet sir

React Props: Same Concept, Different Use Cases — My Revision Takeaways ⚛️ While revising React, I noticed something interesting 👇 Many props-related concepts look similar, but their intent and use cases are very different. Here’s how I now understand them: 🔹 Props The core way components receive data. Simple, predictable, and one-way (parent ➝ child). 🔹 Props Destructuring Improves readability and avoids repetitive props. usage. More than syntax sugar — it makes components cleaner and easier to reason about. 🔹 Destructuring with Rest (...rest) Useful when you don’t know all incoming props upfront. Common in reusable UI components where flexibility matters. 🔹 Default Props / Default Values Helps prevent undefined issues and makes components safer by design. In modern React, default parameters often replace defaultProps. 🔹 props.children A powerful pattern for composition. Instead of hardcoding structure, we let components wrap other components — very React-ish. 🔹 Passing Functions as Props This is where React stops being “just UI” and becomes interactive. It enables child → parent communication and keeps logic centralized. 💡 Big realization: These patterns aren’t competing with each other — they solve different problems. Modern React hasn’t removed them; it has simply made some of them cleaner and more expressive. Revising fundamentals like this reminds me that clarity > memorization. #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #LearningInPublic #ReactProps #CleanCode

I spent the last few days building a design system from scratch. Not because I needed one — but because I wanted to really understand how to structure it properly. The core question I wanted to explore: Can the visual language (tokens) be completely independent from the framework layer? So I built a small neo-brutalist component system inside a Turborepo monorepo: • Design tokens package — colors, typography, spacing, shadows exported as both TypeScript and CSS variables • Core utilities layer — framework-agnostic style helpers • React components package — Button, Card, TextInput, Alert, Toggle, Slider, Avatar • Demo portfolio app built in React, consuming the design system packages (included in the same monorepo) • Storybook documentation • CI/CD pipeline with GitHub Actions for automated builds and Storybook deployment • Strict TypeScript everywhere. Things that stood out while building this: • Enforcing build order (tokens → core → react) actually matters • Package exports ordering can break things in subtle ways • Extending native HTML attributes significantly improves developer experience • The gap between “nice-looking components” and a production-ready library is much bigger than expected (accessibility, testing, edge cases) This is still a learning project — no test suite yet — but I’m happy with how the architecture turned out. Next steps: • Add tests • Run an accessibility audit • Build more complex components (Select, Modal, Combobox) Links: Storybook - https://lnkd.in/gQj4f-G6 Repo - https://lnkd.in/gqVu_fGf #DesignSystem #ReactJS #TypeScript #DesignTokens

Strengthening my Frontend fundamentals by mastering the CSS Box Model Every HTML element is treated as a rectangular box consisting of Content, Padding, Border, and Margin — and truly understanding how these layers interact is key to building clean and responsive layouts. One of the most important takeaways is using box-sizing: border-box; — it ensures that width and height calculations include padding and border, preventing unexpected layout expansion and making designs more predictable. Frontend development isn’t just about writing code — it’s about understanding how structure, spacing, and alignment work behind the scenes. The stronger the fundamentals, the better the UI. Continuing to learn, build, and grow every day. #FrontendDevelopment #CSS #WebDevelopment #LearningJourney #CodingLife #UIUX #TechSkills #SoftwareDevelopment #100DaysOfCode #ResponsiveDesign