The useEffect mistake I still see in every code review. Developers treating it like a lifecycle method instead of a synchronization tool. Common pattern I keep finding: useEffect(() => { if (user) { fetchUserData(user.id); } }, [user]); Looks harmless. But ask yourself: What is this synchronizing with? The component renders → user changes → data fetches. Fine. But what happens when the component mounts and user already exists? Fetch runs twice. What happens when user data is stale in cache? No way to know. Better approach: Separate the "what" from the "when." const fetchDataForUser = useCallback(async (userId) => { // fetch logic here }, []); // Call it when you actually need to useEffect(() => { if (user) { fetchDataForUser(user.id); } }, [user, fetchDataForUser]); Still not perfect. But now the fetch logic is reusable and testable. Even better: Use a data fetching library (React Query, SWR) that handles caching, refetching, and race conditions so you don't have to. What I tell juniors now: useEffect is a sharp tool. Don't reach for it first. Ask: Does this need to be in an effect? Could it be derived during render? Should it be in an event handler instead? The best useEffect is sometimes the one you don't write. What React pattern took you longest to unlearn? #reactjs #javascript #frontend #coding #webdev #bestpractices
Vasim Shaikh’s Post
More Relevant Posts
-
Day 5 ⚡ Async/Await in JavaScript — The Clean Way to Handle Async Code If you’ve struggled with .then() chains, async/await is your best friend 🚀 --- 🧠 What is async? 👉 Makes a function always return a Promise async function greet(){ return "Hello"; } greet().then(console.log); // Hello --- ⏳ What is await? 👉 Pauses execution until a Promise resolves function delay(){ return new Promise(res => setTimeout(() => res("Done"), 1000)); } async function run(){ const result = await delay(); console.log(result); } --- ⚡ Why use async/await? ✔ Cleaner than .then() chaining ✔ Looks like synchronous code ✔ Easier error handling --- ❌ Sequential vs ⚡ Parallel // ❌ Sequential (slow) const a = await fetchUser(); const b = await fetchPosts(); // ⚡ Parallel (fast) const [a, b] = await Promise.all([ fetchUser(), fetchPosts() ]); --- ⚠️ Error Handling try { const data = await fetchData(); } catch (err) { console.log("Error handled"); } --- 💡 One-line takeaway 👉 async/await = cleaner + readable way to handle Promises #JavaScript #AsyncAwait #WebDevelopment #Frontend #Coding #100DaysOfCode
To view or add a comment, sign in
-
🚀 Where to Use Spread (...) and Rest (...) Operators in JavaScript (Real Use Cases) Many developers know spread and rest… But the real question is 👉 Where should you actually use them? 🔹 Spread Operator (...) → “Expand Values” 👉 Use spread when you want to open / copy / merge data 1. Copy Arrays (Avoid Bugs) const arr = [1, 2, 3]; const copy = [...arr]; 👉 Without spread: const copy = arr; // ❌ same reference (danger) 2. Merge Arrays const a = [1, 2]; const b = [3, 4]; const result = [...a, ...b]; 👉 Very common in real apps 3. Update Objects (Immutability – VERY IMPORTANT in React) const user = { name: "Javascript" }; const updatedUser = { ...user, age: 21 }; 👉 Don’t mutate original object 4. Pass Array as Function Arguments const nums = [5, 10, 2]; Math.max(...nums); 5. Clone Objects const newUser = { ...user }; 👉 Used in state updates (React) 🔹 Rest Operator (...) → “Collect Values” 1. Functions with Unlimited Arguments function sum(...numbers) { return numbers.reduce((a, b) => a + b); } 👉 Flexible functions 2. Separate Values from Array const [first, ...rest] = [1, 2, 3, 4]; 👉 Extract first → collect remaining 3. Remove Properties from Object const user = { name: "Javascript", age: 21, city: "Hyd" }; const { name, ...others } = user; 👉 Useful for filtering data 4. Handling API Data const { id, ...userData } = response; 👉 Separate important fields >>>Spread = “Break it apart” >>> Rest = “Bring it together” “Both use ... , how do you differentiate?” It depends on context — >> If it’s expanding values → Spread >> If it’s collecting values → Rest Example: function demo(a, b, ...rest) { console.log(a, b, rest); } const arr = [1, 2, 3, 4]; demo(...arr); #JavaScript #WebDevelopment #Frontend #ReactJS #Coding #Developers #LearnJavaScript #100DaysOfCode
To view or add a comment, sign in
-
⚡ Day 8 — Callbacks vs Promises vs Async/Await If you’re learning JavaScript, understanding async patterns is a must 🚀 --- 🧠 1. Callbacks 👉 Functions passed as arguments function getData(cb) { setTimeout(() => cb("Data"), 1000); } ❌ Problem: Callback Hell 😵 👉 Hard to read and maintain when nested --- 🔗 2. Promises 👉 Better way to handle async operations fetchData() .then(res => process(res)) .catch(err => console.log(err)); ✔ Cleaner than callbacks ✔ Supports chaining ✔ Better error handling --- ⚡ 3. Async/Await 👉 Syntactic sugar over Promises async function getData() { try { const res = await fetchData(); console.log(res); } catch (err) { console.log(err); } } ✔ Looks like synchronous code ✔ Easier to read & debug ✔ Most commonly used today --- 🧠 Quick Comparison: Callbacks → Old, messy Promises → Better control Async/Await → Cleanest & modern --- 🔥 One-line takeaway: 👉 “Async/Await is just a cleaner way to write Promises.” --- If you master this, async JavaScript becomes much easier. #JavaScript #AsyncJS #WebDevelopment #Frontend #100DaysOfCode 🚀
To view or add a comment, sign in
-
Have you ever felt overwhelmed by JavaScript objects? The good news is that methods like Object.keys(), Object.values(), and Object.entries() can simplify how we interact with them. Which one do you find yourself using the most? ────────────────────────────── Demystifying Object.keys(), Object.values(), and Object.entries() Unlock the power of object methods in JavaScript with these simple techniques. #javascript #es6 #programming ────────────────────────────── Key Rules • Object.keys(obj) returns an array of the object's own property names. • Object.values(obj) returns an array of the object's own property values. • Object.entries(obj) returns an array of the object's own property [key, value] pairs. 💡 Try This const person = { name: 'Alice', age: 30, city: 'Wonderland' }; console.log(Object.keys(person)); // ['name', 'age', 'city'] console.log(Object.values(person)); // ['Alice', 30, 'Wonderland'] console.log(Object.entries(person)); // [['name', 'Alice'], ['age', 30], ['city', 'Wonderland']] ❓ Quick Quiz Q: What does Object.entries() return? A: An array of [key, value] pairs from the object. 🔑 Key Takeaway Using these methods can drastically improve your code's readability and efficiency! ────────────────────────────── Small JavaScript bugs keep escaping to production and breaking critical user flows. Debugging inconsistent runtime behavior steals time from feature delivery.
To view or add a comment, sign in
-
𝗦𝘁𝗼𝗽 𝘂𝘀𝗶𝗻𝗴 𝘁𝗵𝗲 𝗗𝗮𝘁𝗲 𝗼𝗯𝗷𝗲𝗰𝘁. 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗷𝘂𝘀𝘁 𝗴𝗿𝗲𝘄 𝘂𝗽. 🚀 If you’re in the web development space for more than a week, you’re probably aware of the pain: 1. Time zones that randomly shift. 2. Mutable dates that change when you least expect it. 3. The "Bundle Bloat" of including heavy libraries just to format a string. We’ve lived with Moment.js, date-fns, or Day.js for the past few years, thinking the "broken" native Date API would never be fixed. Well, that’s not the case anymore! Enter: 𝗧𝗵𝗲 𝗧𝗲𝗺𝗽𝗼𝗿𝗮𝗹 𝗔𝗣𝗜. 🧠 It’s not just an update; it’s an architectural shift in the way JavaScript handles time. Here’s why I think it’s the way to go for my next project: ✅ Immutability by Default: No more bugs because some helper library changed your original date object. ✅ Wall-Clock Time: Better separation of "exact time" (UTC) and "calendar time" (local). ✅ No More Timezone Math: It handles DST transitions and offsets natively. ✅ Cleaner Syntax: const today = Temporal.Now.plainDateISO(); – readable, predictable, and powerful. The Bottom Line for Teams: If you adopt the Temporal API, you get smaller bundle sizes, fewer "timezone bugs," and an easier onboarding experience for new team members. Standardising the hard stuff is how we scale as an industry. Are you still team date-fns, or are you ready to go native with Temporal? 👇 #JavaScript #WebDevelopment #Coding #SoftwareEngineering #TechTrends #Frontend #JavaScript #WebDevelopment #SoftwareEngineering #Frontend #Coding #TechTrends #Programming #TemporalAPI #CleanCode #FullStack #SoftwareArchitecture #Productivity
To view or add a comment, sign in
-
🚀 Async/Await in JavaScript — Write Asynchronous Code Like Synchronous! If Promises made async code cleaner, async/await made it beautiful. Let’s break it down 👇 🔹 What is async/await? • async makes a function return a Promise • await pauses execution until the Promise resolves 👉 It helps you write async code that looks and behaves like synchronous code. 🔹 Basic Example function fetchData() { return new Promise((resolve) => { setTimeout(() => resolve("Data received"), 2000); }); } async function getData() { const data = await fetchData(); console.log(data); } getData(); 🧠 Instead of chaining .then(), you write it step-by-step. 🔹 Error Handling Made Easy async function getData() { try { const data = await fetchData(); console.log(data); } catch (error) { console.error("Error:", error); } } ✅ No more messy .catch() chains ✅ Clean and readable error handling 🔹 Sequential vs Parallel Execution 👉 Sequential (waits one after another) await task1(); await task2(); 👉 Parallel (runs together) const [res1, res2] = await Promise.all([task1(), task2()]); ⚡ Use parallel execution for better performance when tasks are independent. 🔹 Common Mistakes to Avoid ❌ Using await outside async function ❌ Blocking loops with await unnecessarily ❌ Forgetting error handling 💡 Pro Tip: Async/await is just syntactic sugar over Promises — understanding Promises deeply makes async/await even more powerful. 🔥 Interview Question: What will be the output? async function test() { console.log("Start"); await Promise.resolve(); console.log("End"); } test(); console.log("Outside"); 👉 Comment your answer 👇 #JavaScript #AsyncAwait #WebDevelopment #Frontend #Coding #InterviewPrep
To view or add a comment, sign in
-
Are You Using Hooks or Misusing Them? Hooks made React cleaner but only if you respect the rules. In production environments, most bugs don't stem from complex business logic; they stem from subtle anti-patterns that degrade performance and scalability. If you’re aiming for senior-level code, here are the patterns you should stop today: ⚠️ 1. The useEffect Crutch If a value can be computed during render, it doesn’t belong in an effect. Effects are for synchronization with external systems, not for transforming data. Overusing them leads to unnecessary re-renders and "race condition" bugs. ⚠️ 2. Suppressing Dependency Arrays Disabling ESLint warnings is like ignoring a "Check Engine" light. If including a dependency breaks your logic, your logic is flawed, not the rule. Fix the stale closure; don't hide it. ⚠️ 3. Storing Derived State Storing data in useState that can be calculated from props or other state variables is a recipe for sync issues. Always maintain a Single Source of Truth. ⚠️ 4. Abstraction Fatigue (Custom Hook Overkill) Not every 3-line logic block needs a custom hook. Premature abstraction often makes code harder to follow than simple, localized duplication. Abstract for reusability, not just for "cleaner" looking files. ⚠️ 5. Using Hooks to Mask Architectural Debt Hooks are powerful, but they won't fix a poorly structured component tree. Clean architecture > "Clever" hook implementations. 💡 Senior Dev Mindset: Hooks are not just features; they are constraints that enforce predictable behavior. If your React codebase feels "fragile," it’s rarely a React problem it's usually a Hook implementation problem. 💬 Curious to hear from the community: Which of these "subtle" bugs have you spent the most time debugging lately? #ReactJS #FrontendArchitecture #WebDevelopment #JavaScript #SoftwareEngineering #CleanCode #ReactHooks #SeniorDeveloper #CodeQuality #ProgrammingTips
To view or add a comment, sign in
-
🚀 JavaScript Deep Dive: `this` Keyword (Most Confusing Yet Most Asked) If you think `this` always refers to the current object… You’re already making a mistake ❌ Let’s simplify it 👇 --- 💡 Rule: 👉 `this` depends on **HOW a function is called**, not where it is written. --- 💻 Example 1 (Implicit Binding): ```js const user = { name: "Rahul", greet() { console.log(this.name); } }; user.greet(); // Rahul ✅ ``` 👉 Here, `this` → `user` --- 💻 Example 2 (Losing Context): ```js const greetFn = user.greet; greetFn(); // undefined ❌ ``` 👉 `this` is now global (or undefined in strict mode) --- 💻 Example 3 (Arrow Function Trap): ```js const user = { name: "Rahul", greet: () => { console.log(this.name); } }; user.greet(); // undefined ❌ ``` 👉 Arrow functions don’t have their own `this` 👉 They take it from **parent scope** --- 💻 Example 4 (Explicit Binding): ```js function greet() { console.log(this.name); } const user = { name: "Rahul" }; greet.call(user); // Rahul ✅ ``` --- 🔥 4 Golden Rules of `this`: 1. Global → window (or undefined in strict mode) 2. Implicit → object before dot 3. Explicit → call/apply/bind 4. New → new object created --- 💥 Interview Trap: 👉 Question: Why arrow functions are not suitable for object methods? ✅ Answer: Because they don’t have their own `this`, leading to unexpected results. --- 🎯 One Line to Remember: 👉 `this` = “Who is calling me?” --- #javascript #webdevelopment #frontend #reactjs #codinginterview #learnjavascript #developers #100DaysOfCode
To view or add a comment, sign in
-
-
JavaScript is easy. Until it isn't. 😅 Every developer has been there. You're confident. Your code looks clean. You hit run. And then: " Cannot read properties of undefined (reading 'map') " The classic JavaScript wall. Here are 7 JavaScript mistakes I see developers make constantly and how to fix them: 1. Not understanding async/await ⚡ → Wrong: | const data = fetch('https://lnkd.in/dMDBzbsK'); console.log(data); // Promise {pending} | → Right: | const data = await fetch('https://lnkd.in/dMDBzbsK'); | 2. Using var instead of let/const → var is function scoped and causes weird bugs → Always use const by default. let when you need to reassign. Never var. 3. == instead of === → 0 == "0" is true in JavaScript 😱 → Always use === for comparisons. Always. 4. Mutating state directly in React → Wrong: user.name = "Shoaib" → Right: setUser({...user, name: "Shoaib"}) 5. Forgetting to handle errors in async functions → Always wrap await calls in try/catch → Silent failures are the hardest bugs to track down 6. Not cleaning up useEffect in React → Memory leaks are real → Always return a cleanup function when subscribing to events 7. Treating arrays and objects as primitives → [] === [] is false in JavaScript → Reference types don't compare like numbers — learn this early JavaScript rewards the developers who understand its quirks. 💡 Which of these caught YOU off guard when you first learned it? 👇 #JavaScript #WebDevelopment #Frontend #FullStackDeveloper #React #Programming #CodingTips #Developer #Tech #Pakistan #LearnToCode #JS #SoftwareEngineering #100DaysOfCode #PakistaniDeveloper
To view or add a comment, sign in
-
-
𝗠𝗲𝗺𝗼𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 "𝗳𝗿𝗲𝗲" 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝘄𝗶𝗻. ⚡ It’s tempting to wrap every calculation in useMemo or every function in useCallback. But in a large-scale React application, this can backfire. 𝗧𝗵𝗲 𝗖𝗼𝘀𝘁 𝗼𝗳 "𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻": Every time you use these hooks, you aren't just saving a calculation. You are: 1. 𝗜𝗻𝗰𝗿𝗲𝗮𝘀𝗶𝗻𝗴 𝗺𝗲𝗺𝗼𝗿𝘆 𝘂𝘀𝗮𝗴𝗲: React must store the previous value and the dependency array in memory. 2. 𝗔𝗱𝗱𝗶𝗻𝗴 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗼𝘃𝗲𝗿𝗵𝗲𝗮𝗱: On every render, React must run a shallow comparison on every dependency. If you are memoizing a simple .filter() on a 50-item list, the "optimization" overhead is often more expensive than the re-calculation itself. 𝗪𝗵𝗲𝗻 𝘁𝗵𝗲 𝘁𝗿𝗮𝗱𝗲-𝗼𝗳𝗳 𝗺𝗮𝗸𝗲𝘀 𝘀𝗲𝗻𝘀𝗲: ✅ 𝗛𝗲𝗮𝘃𝘆 𝗖𝗼𝗺𝗽𝘂𝘁𝗮𝘁𝗶𝗼𝗻: Expensive data processing (e.g., parsing large JSON or complex regex) that actually blocks the main thread. ✅ 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝘁𝗶𝗮𝗹 𝗜𝗻𝘁𝗲𝗴𝗿𝗶𝘁𝘆: When passing objects or functions to children wrapped in React.memo. Without it, the child re-renders on every parent update, defeating the purpose of React.memo. ✅ 𝗘𝗳𝗳𝗲𝗰𝘁 𝗦𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆: When the value is a dependency in a useEffect that triggers an API call or a heavy subscription. 𝗧𝗵𝗲 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆: Don't guess—measure. I’ve started using the 𝗥𝗲𝗮𝗰𝘁 𝗣𝗿𝗼𝗳𝗶𝗹𝗲𝗿 to identify "Wasted Renders" before reaching for a hook. Often, the better fix isn't memoization, but 𝘀𝘁𝗮𝘁𝗲 𝗰𝗼𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻 or 𝗺𝗼𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝘁𝗮𝘁𝗲 𝗱𝗼𝘄𝗻 the component tree. 𝗜𝗻 𝘆𝗼𝘂𝗿 𝗰𝘂𝗿𝗿𝗲𝗻𝘁 𝘀𝘁𝗮𝗰𝗸, 𝗮𝗿𝗲 𝘆𝗼𝘂 𝘀𝗲𝗲𝗶𝗻𝗴 𝗺𝗼𝗿𝗲 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗴𝗮𝗶𝗻𝘀 𝗳𝗿𝗼𝗺 𝗺𝗲𝗺𝗼𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗼𝗿 𝗳𝗿𝗼𝗺 𝗯𝗲𝘁𝘁𝗲𝗿 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗰𝗼𝗺𝗽𝗼𝘀𝗶𝘁𝗶𝗼𝗻? 👇 #ReactJS #WebPerformance #FrontendEngineering #JavaScript #ProgrammingTips #SoftwareDevelopment
To view or add a comment, sign in
-
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development