Visualizing Revenue with JavaScript and Chart.js

👯♂️ "I changed the copy, why did the original update too?!" 😱 If you’ve ever screamed this at your monitor, you’ve fallen into the Shallow Copy Trap. 🪤 In JavaScript, objects and arrays are reference types. When you copy them, it matters how you do it. 1️⃣ The Shallow Copy (The "Surface" Clone) Methods like the spread operator [...] or Object.assign() only copy the first layer of data. - If your object has nested objects inside (like user.address.city), the copy points to the same memory location as the original. - Result: You change the copy's address, and the original user's address changes too. Bugs everywhere. 🐛 2️⃣ The Deep Copy (The "True" Clone) This creates a completely independent duplicate, including all nested levels. - The Old Way: JSON.parse(JSON.stringify(obj)) (Hack, but works for simple data). - The Modern Way: structuredClone(obj) (Native, fast, and handles dates/maps correctly). 🚀 Next time you are updating state in React or manipulating complex data, ask yourself: Do I need a clone, or do I need a twin? What is your go-to method for deep cloning these days? structuredClone or Lodash? 👇 #JavaScript #WebDevelopment #CodingTips #Frontend #ReactJS #SoftwareEngineering #Programming

Day 43/100 – An Important JavaScript Concept Many People Ignore Copying objects and arrays looks simple… Until bugs start appearing. 📌 Topic: Shallow Copy vs Deep Copy ✅ Shallow Copy Creates a new object, but nested objects still reference the original. Examples: Object.assign() Spread operator { ...obj } Problem: Changing nested data affects both copies. ✅ Deep Copy Creates a completely independent copy, including nested objects. Examples: structuredClone(obj) JSON.parse(JSON.stringify(obj)) 👉 Use deep copy when working with complex nested data. Understanding this saves you from painful debugging later. Learning the basics deeply, one day at a time. On to Day 44 🚀 #100DaysOfCode #JavaScript #WebDevelopment #LearningInPublic #Consistency #Frontend

Day-2 How does JavaScript manage function calls? 🤔 The answer is the Call Stack. JavaScript uses a stack data structure (LIFO) to manage execution contexts. 🔹 What happens when a function is called? function a() {   b();   console.log("A"); } function b() {   console.log("B"); } a(); 🔁 Execution Flow: Global Execution Context is created a() is called → Function Execution Context for a is pushed b() is called → Function Execution Context for b is pushed b() finishes → popped from stack a() finishes → popped from stack 🔹 Why Call Stack matters? ✅ Helps debug errors ✅ Explains stack overflow ✅ Foundation for understanding async JS #JavaScript #CallStack #ExecutionContext  #DailyLearning #Frontend

✅ Understanding undefined vs null Clearly This morning’s code was: let x; console.log(x); console.log(typeof x); x = null; console.log(x); console.log(typeof x); 💡 Correct Output undefined undefined null object Yes , the last line surprises many 😄 Let’s understand why. 🧠 Simple Explanation : 🔹 Line 1: console.log(x); let x; x is declared But no value is assigned So JavaScript automatically gives it: undefined ✔ Output: undefined 🔹 Line 2: console.log(typeof x); The type of undefined is: "undefined" ✔ Output: undefined 🔹 Line 3: x = null; Here, we explicitly assign null. Important rule 👇 👉 null means intentional absence of value So: console.log(x); ✔ Output: null 🔹 Line 4: console.log(typeof x); This is the classic JavaScript quirk 👀 Even though x is null: typeof null returns: "object" ✔ Output: object 📌 This is a known bug in JavaScript kept for backward compatibility. 🎯 Key Takeaways : undefined → variable declared, value not assigned null → value explicitly set to “nothing” typeof undefined → "undefined" typeof null → "object" ❌ (historical JS bug) 📌 That’s why many developers check null like this: x === null 💬 Your Turn Did you already know typeof null is "object"? 😄 Comment “Knew it 👍” or “Learned today 😮” #JavaScript #LearnJS #FrontendDevelopment #CodingInterview #Basics #TechWithVeera #WebDevelopment

🌙 Evening Post — Explanation & Answer ✅ Why This Map Has Two Entries This morning’s code was: const map = new Map(); map.set({}, "first"); map.set({}, "second"); console.log(map.size); 💡 Correct Output 2 Yes — two entries, not one 😄 Here’s why 👇 🧠 Simple Explanation : 🔹 Objects are compared by reference, not by value Even though both keys look like {}: {} !== {} Each {} creates a new object in memory. So JavaScript sees this as: Key 1 → one object reference Key 2 → another object reference They are completely different keys. 🔹 How Map works Map allows any type as a key Keys are matched by reference Different object references → different entries So: map.size // 2 🎯 Key Takeaways : Map keys are compared by reference {} and {} are never the same key Objects are not value-equal by default This behavior is different from plain objects 📌 To use the same key, you must reuse the same reference: const key = {}; map.set(key, "first"); map.set(key, "second"); 💬 Your Turn Did you expect the size to be 1 or 2? 😄 Comment “Got it wrong 😅” or “Knew this 👍” #JavaScript #LearnJS #FrontendDevelopment #CodingInterview #Maps #TechWithVeera #WebDevelopment

map, filter, reduce — small methods, big impact 🚀 Most developers use them. Few actually understand them. 🧠 map → transform data 🧹 filter → select data ♻️ reduce → accumulate data No magic. Just loops + callbacks + clean thinking. arr .filter(x => x.active) .map(x => x.value) .reduce((sum, v) => sum + v, 0); This mindset turns messy logic into readable, scalable code. Learning them deeply (including polyfills) made me write better React & JS. Which one confused you the most at first? 👇 #JavaScript #Frontend #ReactJS #CleanCode #LearningInPublic #InterviewPrep

𝗪𝗲𝗹𝗰𝗼𝗺𝗲 𝘁𝗼 𝗗𝗮𝘆 𝟵 Have you ever updated one variable… and another one changed automatically? 𝙋𝙖𝙪𝙨𝙚 𝙛𝙤𝙧 𝙖 𝙨𝙚𝙘𝙤𝙣𝙙 — 𝙬𝙤𝙪𝙡𝙙 𝙮𝙤𝙪 𝙚𝙭𝙥𝙚𝙘𝙩 𝙩𝙝𝙞𝙨 𝙘𝙤𝙙𝙚 𝙩𝙤 𝙢𝙪𝙩𝙖𝙩𝙚 𝙗𝙤𝙩𝙝 𝙫𝙖𝙡𝙪𝙚𝙨? { 𝚕𝚎𝚝 𝚞𝚜𝚎𝚛𝟷 = { 𝚗𝚊𝚖𝚎: "𝙰𝚕𝚎𝚡" }; 𝚕𝚎𝚝 𝚞𝚜𝚎𝚛𝟸 = 𝚞𝚜𝚎𝚛𝟷; 𝚞𝚜𝚎𝚛𝟸．𝚗𝚊𝚖𝚎 = "𝙹𝚘𝚑𝚗"; 𝚌𝚘𝚗𝚜𝚘𝚕𝚎．𝚕𝚘𝚐(𝚞𝚜𝚎𝚛𝟷．𝚗𝚊𝚖𝚎); // "𝙹𝚘𝚑𝚗" } Why did user1 change? Because: • Both variables point to the same memory address • No copy was created • Only the reference was shared 𝘛𝘩𝘪𝘴 𝘪𝘴 𝘑𝘢𝘷𝘢𝘚𝘤𝘳𝘪𝘱𝘵’𝘴 𝘝𝘢𝘭𝘶𝘦 𝘷𝘴 𝘙𝘦𝘧𝘦𝘳𝘦𝘯𝘤𝘦 𝘣𝘦𝘩𝘢𝘷𝘪𝘰𝘳 — 𝘢𝘯𝘥 𝘪𝘵’𝘴 𝘥𝘦𝘦𝘱𝘭𝘺 𝘵𝘪𝘦𝘥 𝘵𝘰 𝘮𝘦𝘮𝘰𝘳𝘺. 𝙏𝙝𝙚 𝙈𝙚𝙣𝙩𝙖𝙡 𝙈𝙤𝙙𝙚𝙡 (𝙈𝙚𝙢𝙤𝙧𝙮 𝙁𝙞𝙧𝙨𝙩) JavaScript mainly uses two memory areas: -> Stack Memory • Stores primitive values • Fixed size • Fast access -> Heap Memory • Stores objects, arrays, functions • Dynamic size • Accessed via references 𝙒𝙝𝙚𝙣 𝙥𝙖𝙨𝙨𝙚𝙙 𝙗𝙮 𝙫𝙖𝙡𝙪𝙚: A copy of the actual value is passed. Primitives (number, string, boolean, null, undefined, symbol) are always passed by value. 𝙒𝙝𝙚𝙣 𝙥𝙖𝙨𝙨𝙚𝙙 𝙗𝙮 𝙧𝙚𝙛𝙚𝙧𝙚𝙣𝙘𝙚: A memory address (reference) is passed, not the object itself. Objects & arrays live in heap memory. #JavaScript #JSFundamentals #MemoryManagement #FrontendDevelopment #ReactJS #BugFixing #InterviewPrep #LearningInPublic

Reversing a string in JavaScript can be done in more than one way. I revisited this problem today and tried three approaches, each with a different mindset: // 1. Using built-in methods const reverse1 = (str) => str.split("").reverse().join(""); // 2. Using a loop (more control) function reverse2(str) {  let result = "";  for (let i = str.length - 1; i >= 0; i--) {   result += str[i];  }  return result; } // 3. Using reduce (functional style) const reverse3 = (str) =>  str.split("").reduce((acc, char) => char + acc, ""); console.log(reverse1("hello")); //"olleh" console.log(reverse2("hello")); //"olleh" console.log(reverse3("hello")); //"olleh" Methods I used: • Built-in methods → concise and readable • Loop → full control and clarity • reduce → functional and expressive This reminded me that in real projects, how you think about a problem matters as much as the answer itself. Still learning, still building, still showing up. #JavaScript #FrontendDevelopment #LearningInPublic #JuniorDeveloper

😍 Recently আমি একটি real-world project এ searching, filtering & pagination feature implement করেছি 🚀 🔹 Keyword-based search 🔹 Multiple dynamic filters 🔹 Efficient & user-friendly pagination এই feature গুলো implement করেছি Prisma ORM ব্যবহার করে, যা আমাকে দিয়েছে— ✨ Clean & type-safe queries ✨ Better performance ✨ Scalable data handling Small features, but a big impact on user experience 💡 Still learning by building real products 💪 👉 You are currently working on which feature? #WebDevelopment #FullStack #JavaScript #React #Backend #LearningByDoing

I've been very impressed, so far, with Datastar (https://data-star.dev/), a tiny JavaScript library; I've been switching a side-project from using Svelte for its UI to Datastar, and as amazing as Svelte is, Datastar has impressed me more. Its essential concept is for the client to shift virtually all logic and markup rendering back to the server; event handlers can succinctly call server endpoints, which return markup, and the markup is morphed into the running DOM. The server-side is the system of record. Datastar has a nice DSL, based on `data-` attributes, allowing you to do nearly anything you need to do in the client, declaratively. Alternately, the server can start an SSE (server sent event) stream and send down markup to morph, or JavaScript to execute, over any period of time. For example, my app has a long running process and it was a snap to create a modal progress dialog and keep it updated as the server-side process looped through its inputs. Their mantra is to trust the morph and browser--it's surprisingly fast to update even when sending a fair bit of content. It feels wasteful to update a whole page just to change a few small things (say, mark a button as disabled) but it works, and it's fast, and it frees you from a nearly all client-side reactive updates (and all the related edge cases and unforseen consequences). The server side is not bound to any language or framework (they have API implementations for Clojure, Java, Python, Ruby, and many others) ... and you could probably write your own API in an afternoon. I especially like side-stepping the issue of needing more representations of data; the data lives server-side, all that is ever sent to the client is markup. There's no over-the-wire representation, and no parallel client-side data model. All that's ever exposed as endpoints are intentional ones that do work and deliver markup ... in other words, always use-case based, never schema based. There's a minimal amount of reactive logic in the client, but the essence of moving the logic to server feels like home; Tapestry (way back in 2005) had some similar ideas, but was far more limited (due to many factors, including JavaScript and browser maturity in that time). I value simplicity, and Datastar looks to fit my needs without doing so much that is magical or hidden. I consider that a big win!