React Props: Understanding Intent and Use Cases

I’m wrapping up with my first big story on the new project. Everything is going well, but one thing keeps bothering me 🤔 >>> TL;DR React doesn’t have slots out of the box, but you can implement them quite easily. See the gist in the comments. The task is a redesign of the platform’s core video player. I already have a very similar experience - I reworked the Skyeng room with a new look - so I know in advance that this is a good chance to fix some #technicaldebt and do a moderate refactor. We, developers, love moments like this, just don’t tell anyone 🤫 One of my favorite approaches to organizing complex systems is splitting them into #smartdumb components. This helps to distribute logic between several autonomous parts and then compose them on the page using a layout component. In the simplest case, like on the first slide, layout elements can be passed directly via props or implemented with the render props pattern. But quite often this starts to look a bit messy, especially when JSX props are rendered conditionally or have many parameters. Someone may say that this hurts readability. Even though this is not a big problem for me personally, this approach just doesn’t feel right. I much prefer to pass template elements using content projection, via children, like on the second slide. To me, this looks more explicit and semantically correct and I recommend to use this architectural approach together with this trick, because it is clean, scalable and reads well In short, the whole implementation is based on the built-in Children API and the fact that a JSX element contains a reference to the function that created it. By accessing these objects, we can understand what’s inside and where exactly the content should be rendered. I described the implementation details in the attached gist. For production projects, you might prefer using existing libraries: - `@aiera-inc/react-slots` - `react-slots` All of them are based on the same concept shown in the example. At the same time, the mechanics are quite simple, so you can safely use a custom implementation as well. Especially since you already know this trick 😉 Alright, now you know the pattern - a comment from you on what you think about this #react #javascript #refactoring #pattern

🚀 𝐓𝐡𝐞 𝐌𝐨𝐦𝐞𝐧𝐭 𝐑𝐞𝐚𝐜𝐭 𝐂𝐨𝐧𝐭𝐞𝐱𝐭 𝐅𝐢𝐧𝐚𝐥𝐥𝐲 “𝐂𝐥𝐢𝐜𝐤𝐞𝐝” 𝐟𝐨𝐫 𝐌𝐞 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

Ever wondered what React is REALLY doing when you write <Component />? 👀⚛️ I’ve been building a custom React renderer to explore React internals from the inside out. Not a toy “mini React”, but the part that connects React’s reconciliation to a non-DOM target (think canvas, terminal UI, WebGL, native, even docs/diagram generation). A few practical takeaways that surprised me: 🔁 Reconciliation is target-agnostic. React decides “what changed” in a generic way; the renderer decides “how to apply it”. 🧠 The host config is the contract. Implement createInstance / appendChild / commitUpdate and you’re basically teaching React how to “draw” in your environment. ⏱️ Scheduling + batching matter more than you think. If your renderer commits too eagerly, performance falls off a cliff. If you batch intelligently, you get smooth updates even with heavy trees. 🧩 Effects aren’t magic. They’re coordinated around commit phases; understanding that makes debugging “why did this run twice?” issues much less mysterious. Why this matters beyond curiosity: custom renderers unlock UI patterns and industry tooling—internal devtools, healthcare visualization, aerospace dashboards, HR workflow surfaces—without fighting the DOM. 🛠️🚀 What non-DOM target would you render React to? 🤔 #react #javascript #frontend #webdev #engineering

🚀 Just Discovered: Oat — A Breath of Fresh Air for Frontend Development Really impressed by the simplicity and clarity of Oat. Great work by Kailash Nadh and team 👏👏👏 If you’ve ever felt weighed down by complex build systems, heavy frameworks, or endless dependencies — this might excite you. I came across Oat, an ultra-lightweight HTML/CSS UI component library that actually lives up to its name. At ~8KB (minified + gzipped), it gives you: 🔹 Semantic, zero-dependency UI components 🔹 No frameworks, no build tooling, no class pollution 🔹 Minimal JS (WebComponents) where needed 🔹 Styles native HTML elements contextually out of the box 💡 Perfect for: ✔ Developers who value semantic HTML ✔ Projects where performance really matters ✔ Anyone tired of bloated UI frameworks Check it out here 👉 https://oat.ink/� #FrontendDevelopment #WebDevelopment #UIEngineering #WebComponents #SemanticHTML #CSS #JavaScript #PerformanceMatters #MinimalismInTech

𝐒𝐭𝐨𝐩 𝐏𝐫𝐨𝐩 𝐃𝐫𝐢𝐥𝐥𝐢𝐧𝐠! 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

💡 What is DOM? (And Why Every Frontend Developer Must Truly Understand It) When we write HTML, we’re not just creating a webpage. We’re creating a structure that the browser converts into something powerful: the DOM (Document Object Model). 📌 So what exactly is the DOM? The DOM is a programming interface that represents your HTML document as a tree of objects (nodes). Every: <html> tag <body> tag <div> <button> even text inside elements … becomes a node inside a structured tree. This allows JavaScript to: ✔ Read content ✔ Modify elements ✔ Change styles ✔ Add or remove nodes ✔ Respond to user events Without the DOM, JavaScript couldn’t dynamically update a webpage. 🧠 How It Actually Works Behind the Scenes 1️⃣ Browser parses HTML 2️⃣ It creates a DOM tree in memory 3️⃣ JavaScript interacts with this tree 4️⃣ When changes happen, the browser repaints the UI Every DOM manipulation has a performance cost — especially large or frequent updates. This is exactly why libraries like React introduced the concept of a Virtual DOM — to minimize direct DOM operations and optimize rendering. ⚡ Why Understanding DOM is Important (Even If You Use React) Even if you work with modern frameworks: Re-renders are still tied to DOM updates Performance optimization depends on understanding repaint & reflow Debugging UI issues often requires DOM inspection Event bubbling & capturing are pure DOM concepts If you truly understand the DOM, you understand frontend at a deeper level. #WebDevelopment #FrontendDevelopment #JavaScript #HTML #DOM #Programming #Coding #ReactJS #FrontendEngineer #SoftwareEngineering #WebDev #LearnToCode #DeveloperLife #CodingJourney #TechCommunity #ContinuousLearning

⚛️ React Performance: Why Optimization Often Backfires React performance issues are rarely about React being slow. Most of the time, they come from how components are structured and re-rendered. A few things that matter more than people think: Unnecessary re-renders Components re-render because state or props change, not because React feels like it. Poor state placement is usually the root cause. useCallback & useMemo Helpful in specific cases, but overusing them adds complexity and memory overhead. Memoization without a re-render problem is not an optimization it’s noise. React.memo It prevents re-renders only when props are referentially equal. If you pass new objects or functions every render, it does nothing. Keys in lists Keys are not just for avoiding warnings. Bad keys break reconciliation and cause unnecessary DOM updates. Component composition > premature memoization Smaller, well-isolated components naturally limit re-render boundaries and often outperform heavy memo usage. Engineering takeaway: Optimize structure first, memoize second. Good component design solves most performance issues before hooks are even needed. #ReactJS #FrontendEngineering #PerformanceOptimization #JavaScript #WebDevelopment #EngineeringInsights

𝗜 𝗥𝗲𝗯𝗶𝗹𝗱 𝗠𝘆 𝗟𝗮𝗻𝗱𝗶𝗻𝗴 𝗣𝗮𝗴𝗲 𝗨𝘀𝗶𝗻𝗴 𝗥𝗲𝗮𝗰𝘁 I rebuilt one of my old landing pages using React. I thought it would be simple. But structuring components properly showed me how powerful React can be. I made some key changes: - Converted sections into reusable components - Improved folder structure - Optimized images - Used Tailwind CSS for faster styling - Focused on mobile-first responsiveness React forces you to think in components, not pages. This mindset shift helped me clean up my old layout. Performance improved after removing unused CSS and splitting components logically. The biggest challenge was managing layout spacing. I solved it by creating shared container and section wrapper components. The result is a cleaner UI. If you're learning React, try rebuilding an old project. You will learn more than starting something new. Source: https://lnkd.in/dS9Qw4sP

React Isn’t Slow. You Just Don’t Understand Re-renders. One thing that genuinely improved my React code quality was properly understanding how re-renders actually work. Here’s the simple version. A component re-renders when: • Its state updates • Its parent re-renders • Its props change • Its context value changes That’s it. But here’s the part many developers misunderstand: A re-render does not automatically mean the DOM updates. What actually happens: React runs the component again → Creates a new virtual tree → Compares it with the previous one → Updates the real DOM only if something changed. If nothing changed after comparison, the browser DOM isn’t touched. So why do apps still feel slow sometimes? From what I’ve seen in real-world projects, it’s usually architecture: • State lifted higher than necessary • Passing new object/function references every render • Components handling too many responsibilities • Weak separation of concerns Small example: Creating a new object inside render and passing it as a prop changes its reference every time → child re-renders. That’s not React being slow. That’s design decisions. The order I try to follow now: 1️⃣ Fix component boundaries 2️⃣ Keep state as local as possible 3️⃣ Stabilize props where necessary 4️⃣ Then think about memoization Performance issues are rarely solved by adding hooks randomly. They’re solved by thinking clearly about structure. Day 1/100 — sharing practical frontend lessons from production experience. Curious — what was the most confusing re-render bug you’ve faced? #ReactJS #FrontendEngineering #WebPerformance #SoftwareDevelopment #JavaScript

🚀 Building Reactive UI with Zero Effort: A pawaJs Sneak Peek I’ve been experimenting with pawaJs, and the developer experience is incredibly smooth! Check out how easily we can manage state and create reactive components. In this example, I’m building a simple counter that demonstrates the core strengths of the framework: Reactive State: Using state-count="0" directly in the HTML to initialize data. Computed Values: Notice how the doubleCount automatically tracks and multiplies the base state—reactivity handled for you! Custom Components: I registered a <compo></component> component with RegisterComponent in just a few lines of code. Directives: Clean, attribute-based event handling like on-click="count.value++". What I love most is how pawaJs keeps the logic readable and the boilerplate to an absolute minimum.it feels like a framework built for modern performance. The web is evolving, and tools like this make building interactive interfaces feel like a breeze again. 🍦 #pawaJs #WebDevelopment #JavaScript #Frontend #OpenSource #WebDev #Programming #TechInnovation