Tehillah K.’s Post

React confused me today… for a simple .push() 😅 I was updating an array in state and did this: items.push(newItem) setItems(items) Pretty normal JavaScript, right? But the UI didn’t update. That’s where I got stuck. Then I realized what was actually happening. Arrays in JavaScript are stored by reference. So .push() doesn’t create a new array — it just modifies the existing one. React compared the old state and new state… and saw the same reference. So it thought: “Nothing changed.” 💡 The way I understand it now: Using .push() → same box 📦 Using spread → new box 📦✨ React only reacts when the box changes, not just what’s inside it. So the correct way: setItems(prevItems => [...prevItems, newItem]) Small thing, but it cleared up a lot for me. One more step forward 🚀 #ReactJS #JavaScript #Frontend #LearningInPublic

Most React developers know this rule: “Don’t call hooks inside loops or conditions.” But far fewer understand why. React doesn’t track hooks by variable name or location. It tracks them purely by call order during render. So internally, it’s closer to this mental model: • First useState → slot 0 • Second useState → slot 1 • Third useState → slot 2 Each hook call is mapped based on its position in the sequence. Now imagine this: if (isLoggedIn) { useState(...) } On one render the hook is called, on another it’s not. That shifts the entire sequence. React will still read: • “2nd hook → slot 1” But now it’s actually reading the wrong state. I built a minimal useState implementation (attached) to demonstrate this. You’ll notice: • Hooks are stored in an array • Each call consumes the next index • The index resets on every render • Everything depends on consistent ordering That’s the real rule: It’s not about avoiding conditions It’s about keeping hook calls in the same order every render Once that order changes, state association breaks. #React #JavaScript #Frontend #SoftwareEngineering

Why do we need to call 'super(props)' in the constructor of a React component? JavaScript classes aren't magic. They are just syntactic sugar over prototypes. If you are still using (or have used) Class Components in React, you have likely typed 'super(props)' a thousand times. But do you actually know what happens if you forget it? In JavaScript, you cannot use the keyword 'this' in a constructor until you have called the parent constructor. Since your component extends 'React.Component', calling 'super()' is what actually initializes the 'this' object. If you try to access 'this.state' or 'this.props' before that call, JavaScript will throw a ReferenceError and crash your app. But why pass 'props' into it? React sets 'this.props' for you automatically after the constructor runs. However, if you want to access 'this.props' inside the constructor itself, you must pass them to 'super(props)'. If you just call 'super()', 'this.props' will be undefined until the constructor finishes execution. Most of us have moved to Functional Components where this isn't an issue. But understanding these fundamentals is what separates a developer who just writes code from one who understands the runtime. #ReactJS #Javascript #SoftwareEngineering #WebDevelopment #Coding #ProgrammingTips

Why do we specifically pass 'props' into 'super(props)' in a React component constructor? It is one of those things many developers do out of habit without realizing the actual mechanism behind it. While calling 'super()' is a JavaScript requirement to initialize the 'this' keyword, passing 'props' is a very specific React requirement for the constructor phase. The reason is simple: visibility. When you call 'super(props)', you are telling the parent 'React.Component' class to initialize 'this.props' for you immediately. If you only call 'super()' without the argument, 'this.props' will be undefined inside the constructor. React eventually assigns props to the instance anyway, but that happens after the constructor has finished running. If your logic requires you to access a property or compute a state based on a prop right inside the constructor, forgetting the 'props' argument will crash your logic. You would be trying to read from a variable that hasn't been wired up to the instance yet. Even though modern React code bases have shifted to Functional Components where this ceremony is gone, the underlying logic of when data becomes available to an instance is a core part of the library’s history. It is a small detail that perfectly illustrates how React works under the hood. #ReactJS #Javascript #SoftwareEngineering #FrontendDevelopment #WebDev #CodingTips

Nobody told me this when I started React. I used it for over a year without really getting it. I could build things. Components, hooks, state — all of it. But something was always slightly off. Like, I was constantly fighting the framework instead of working with it. I'd update the state and then immediately try to read it. I'd wonder why my UI wasn't reflecting what I just changed. I'd add more useEffects, trying to force things to sync. More code. More confusion. Then I came across three characters that broke it all open for me. UI = f(state) That's it. React has one rule. Your UI is not something you control directly — it's the output of a function. You give it your data. It gives you back what the screen should look like. You don't say "update this element." You say, "here's the data." React handles the screen. I know that sounds simple. But I genuinely wasn't thinking this way. I was still mentally treating React like jQuery — find the element, change it, done. That mental model works fine for jQuery. In React it fights you every step. The moment I stopped thinking about updating UI and started thinking about describing UI — everything got easier. My components got smaller. My bugs got fewer. My useEffects stopped multiplying. Because I finally understood: my only job is to get the state right. React's job is everything else. #React #JavaScript #Frontend #ReactJS #WebDevelopment #Programming #100DaysOfCode #SoftwareDevelopment

Most React Native codebases become a mess by month 3. Not because the developer was bad. Because nobody agreed on a structure from day one. Here's the folder structure I use on every project 👇 src/ ├── components/  → reusable UI only ├── screens/   → one file per screen ├── navigation/  → all route config here ├── hooks/    → useAuth, usePlayer, useBooking ├── store/    → Redux slices ├── services/   → ALL API calls live here ├── utils/    → helpers & constants ├── types/    → TypeScript interfaces └── assets/    → images & fonts 3 rules I never break: 🔴 API calls never go inside components 🟡 Every colour lives in theme.ts — nowhere else 🟢 Types folder grows with the project — never skip it Junior me put everything in /components. 6 months later it had 60 files and zero logic separation. Never again. Save this before your next project 👇 #ReactNative #TypeScript #CleanCode #MobileDev #JavaScript #2026

most React developers have too many useEffects. i did too. until i read this rule and couldn't unsee it: if you're using useEffect to sync state with another state you don't need useEffect. here's what i mean. (the pattern 1 .. i see everywhere) but pattern 2 give same result . no effect. no extra render cycle. useEffect is for syncing React with something outside React. - fetching data from an API - setting up a subscription - manually touching the DOM not for calculating values you could just... calculate. every unnecessary useEffect is a hidden render cycle your users pay for. before you write useEffect ask one question: am i syncing with something outside React, or am i just doing math? if it's math delete the effect. #reactjs #typescript #webdevelopment #buildinpublic #javascript

🚀 Understanding Functional vs Class Components in React — Simplified! In React, everything revolves around components. But there are two types: 👉 Functional Components 👉 Class Components So… which one should you use? 💡 What are Functional Components? 👉 Simple JavaScript functions that return JSX function Greeting() { return <h1>Hello, React!</h1>; } ✅ Cleaner syntax ✅ Easier to read ✅ Uses Hooks (useState, useEffect) ✅ Preferred in modern React 💡 What are Class Components? 👉 ES6 classes that extend React.Component class Greeting extends React.Component { render() { return <h1>Hello, React!</h1>; } } 👉 Uses lifecycle methods instead of hooks ⚙️ Key Differences 🔹 Functional: Uses Hooks Less boilerplate Easier to maintain 🔹 Class: Uses lifecycle methods More complex syntax Harder to manage state 🧠 Real-world use cases ✔ Functional Components: Modern applications Scalable projects Cleaner architecture ✔ Class Components: Legacy codebases Older React apps 🔥 Best Practices (Most developers miss this!) ✅ Prefer functional components in new projects ✅ Use hooks instead of lifecycle methods ✅ Keep components small and reusable ❌ Don’t mix class and functional patterns unnecessarily ⚠️ Common Mistake 👉 Overcomplicating simple components with classes // ❌ Overkill class Button extends React.Component { render() { return <button>Click</button>; } } 👉 Use functional instead 💬 Pro Insight React today is built around: 👉 Functions + Hooks, not classes 📌 Save this post & follow for more deep frontend insights! 📅 Day 7/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #WebDevelopment #SoftwareEngineering #100DaysOfCode 🚀

🚀 Day 6 of My MERN Stack Journey — Hands-On DOM: How I Built a Task Manager in Plain JS Today I moved beyond basics and built a dynamic Task Manager using JavaScript and DOM. What I learned: ✅ Arrays and objects for managing data ✅ .push(), .pop(), .map(), .filter() in real use ✅ DOM manipulation to display tasks ✅ Event handling using addEventListener ✅ Building a functional UI from scratch 💡 Biggest takeaway: Connecting JavaScript logic with the DOM made everything feel real. This is where frontend development actually starts making sense. Next step: Improving the project with better UI and local storage. 🔗 GitHub: https://lnkd.in/dSw73q63 Read More: https://lnkd.in/ddfkuhWa #MERNStack #JavaScript #WebDevelopment #LearningInPublic #FrontendDevelopment