Day 17 of #100DaysOfCode: Refactoring & The Art of "Unpacking" 📦 Today was a refactoring day. I took my Shopping List code from earlier this week and cleaned it up using modern JavaScript patterns. Two big changes I forced myself to make: Destructuring: Instead of writing item.name and item.price ten times, I learned to unpack them directly in the function arguments: const calculate = ({ price, qty }) => ... It cuts the noise and makes the code so much more readable. No forEach for logic: I set a strict rule: forEach is ONLY for printing to the console. Need a new array? Use map. Need a subset? Use filter. Need a total? Use reduce. DSA Update: Didn't get to DSA today. I got lost in the refactoring process, but getting the syntax right feels like a win. #JavaScript #WebDevelopment #CleanCode #100DaysOfCode #Refactoring
Refactoring Shopping List Code with Modern JavaScript
More Relevant Posts
-
Debounce and throttle solve different problems. Most people use the wrong one. Debounce: Waits until you stop, then executes once Throttle: Executes at regular intervals while you continue Think of it like: 1. Debounce = elevator door (waits for people to stop entering) 2. Throttle = traffic light (lets cars through at fixed intervals) ``` // Search input - wait until done typing let debouncedSearch = debounce(searchAPI, 300); // Scroll handler - update while scrolling let throttledScroll = throttle(updatePosition, 100); ``` Quick decision: 1. Want it to run WHILE the event happens? → Throttle 2. Want it to run AFTER the event stops? → Debounce Common mistake: using debounce for scroll events. Your UI won't update until scrolling stops. Use throttle instead - it updates periodically while you scroll. Full comparison with implementations: https://lnkd.in/dN7B7TQN Thanks to Akshay Saini 🚀 for the clear breakdown. Which one do you confuse more often? Let me know if I missed anything - happy to improve it. #JavaScript #WebDev #Coding #LearningInPublic #100DaysOfCode
To view or add a comment, sign in
-
Day 184: Moving Nodes and Counting Words I am now on Day 184! Today, I practiced more Linked List logic and started working with Strings. Here is what I did today in very simple steps: 1. Rotate List (LeetCode 61) 🔄 I learned how to take the end of a list and move it to the front. How? First, I find the length of the list. Then, I find the right place to "cut" the list and connect the end back to the start. 2. Swap Nodes in Pairs (LeetCode 24) 🤝 I learned how to swap every two nodes. For example, 1 -> 2 -> 3 -> 4 becomes 2 -> 1 -> 4 -> 3. The Trick: I used a "Sentinel" node to keep track of the head. I also tried a Recursive version, which made the code very short and clean! 3. Length of Last Word (LeetCode 58) 📏 I moved to Strings! I had to find the length of the very last word in a sentence. Manual Way: Instead of using easy shortcuts, I started from the end of the string, skipped the empty spaces, and counted the letters until I hit another space. It is a great way to practice loops. My takeaway: Whether it is cutting a list or counting letters backward, logic is all about finding the right starting point! #JavaScript #Coding #Programming #WebDevelopment #DataStructures #Algorithms #SoftwareEngineer #Logic #SimpleLearning #StringManipulation #LinkedList #TechCommunity #DailyCoding #ProblemSolving #CareerGrowth #CodeNewbie
To view or add a comment, sign in
-
It's 5:45 am & I am still looking at my dreams. Today[2/28/2026] is day 23 of learning javascript Today & tommorow i will learn are: 1. Difference between let, const & var 2. How to use the default parameter 3. Template string, Multiline string, Dynamic string 4. Arrow Function Syntax, params 5. Spread Operator, Array Max, Copy Arrays 6. Object & Array destructuring 7. Keys, Values, Entries, Delete, Seal, Freeze 8. Accessing Object Data: Nested Object, Optional Chaining 9. Looping Object 10. Primitive Type, Non Primitive Type 11. Null Vs Undefines 12. Truthy & Falsy Values 13. ==, === , implicit conversion 14. Block Scope, Global Scope, Simple Unders. of Hoisting 15. Closure 16. Callback Function & pass different function 17. Function Arguments, pass by ref. pass by value 18. Map, ForEach 19. Filter, Find, Reduce #letsconnect #programmer #frontenddeveloper #mernstakedeveloper #Coding
To view or add a comment, sign in
-
In WASM, the painful part isn’t when it crashes. It’s when it crashes silently. When 🦀 Rust crosses into WebAssembly, you get a new frontline: the error and type boundary between Rust and JavaScript. If that boundary isn’t disciplined, bugs turn into “something went wrong” with no context, no repro path, and no way to debug quickly. In a small Rust↔JS module, I try to keep that boundary in shape with three simple moves: • Safe execution — wrap calls with `catch_unwind` so a panic becomes `Result<_, JsValue>` with context instead of undefined behavior in JS. • Safe deserialization — decode any incoming `JsValue` into a Rust type via `serde_wasm_bindgen` and return failures as labeled `JsValue` errors. • Transparent debug logging — when a debug flag is on, log decoded/result values; otherwise, stay quiet. This isn’t “perfect architecture”. It’s a pragmatic contract: errors should be returnable, labeled, and diagnosable. Curious how others handle this in Rust↔JS/WASM: do you prefer string messages at the boundary (simple), or structured error objects (more work, but a stable contract)?
To view or add a comment, sign in
-
Understanding encapsulation beyond the textbook definition has made OOP much clearer to me. Encapsulation isn’t about hiding everything. It’s about protecting internal state and controlling how an object is used. In modern JavaScript, we now have true private class fields using #. The properties and methods we write using #, cannot be accessed outside the class. It forces anyone using the object to interact with it only through the methods we expose. That’s where public methods come in. Public methods define the safe interface of the object. They’re like the “buttons” we’re allowed to press. Also there are static methods and fields. These methods and fields belong to the class itself, not to individual instances. They’re useful for helper functions or class-level logic that doesn’t depend on a specific object. What really clarified everything for me was understanding the difference between encapsulation and abstraction. Encapsulation is about protecting and structuring data inside a class. Abstraction is about hiding complexity and exposing only what’s necessary to the user. Encapsulation protects the inside, while, abstraction simplifies the outside. All of these helps refine how I think about my code. #JavaScript #WebDevelopment #TechJourney #SoftwareEngineering #Growth
To view or add a comment, sign in
-
-
When Division Is Not Allowed: Thinking in Prefix and Suffix 📊 Solved LeetCode 238 – Product of Array Except Self today. The naive solution would use division, but the constraint pushes you to think differently. The elegant approach: - Build a prefix product array (product of elements to the left) - Build a suffix product pass (product of elements to the right) - Combine them in O(n) time without extra division No nested loops. No division. Linear time. Key takeaway: Many array problems become simple when you think in terms of precomputed cumulative information. 💡 Practical insight: Whenever you see “for each element, compute something excluding itself”, think: - Prefix - Suffix - Two-pass strategy This pattern shows up in range queries, cumulative sums, and DP optimizations. #LeetCode #DSA #Arrays #JavaScript #Algorithms #ProblemSolving #LearnInPublic
To view or add a comment, sign in
-
✅ Solved LeetCode: Binary Tree Postorder Traversal (145) Implemented an iterative Postorder Traversal in JavaScript using two stacks, following the sequence: Left → Right → Root. The strategy works as follows: - Use the first stack (s1) to process nodes in a modified preorder fashion (Root → Left → Right). - Push each popped node into a second stack (s2). - After traversal, pop nodes from s2 to get the correct Postorder sequence. This approach effectively simulates recursion while maintaining the correct traversal order. ⏱ Time Complexity: O(n) — each node is processed once 🧠 Space Complexity: O(n) — due to the use of two stacks A neat stack-based trick to achieve Postorder without recursion! 🌳
To view or add a comment, sign in
-
-
Today I worked on auto-arranging nodes using Dagre and ELK. Both are JavaScript graph layout libraries. Dagre: https://lnkd.in/eREEGZ8E ELK: https://lnkd.in/ej9H-6V5 They automatically position nodes (devices) and edges (connections), which sounds simple until you try it. The goal is to create infrastructure diagrams that arrange themselves cleanly. Different layout constraints produce different results. Overlapping connections' spaghettification is a harder problem than I expected.
To view or add a comment, sign in
-
-
I thought I understood map(), filter() and reduce()… until I wrote their polyfills. We use these methods daily in JavaScript. But I wanted to understand what actually happens behind the scenes. Building polyfills is one of the best ways to master: 1️⃣ Prototypes: How inheritance actually works in JS. 2️⃣ Execution Context: Mastering the behavior of this. 3️⃣ Edge Cases: Handling reduce() accumulators without an initial value. I’ve put together a deep dive into these internals. What’s inside: The logic behind Array.prototype. Step-by-step custom implementations. The "hidden" index logic in .reduce(). Which polyfill was the hardest for you to learn? Let’s discuss below! #Javascript #Chai aur Code #Polyfills
To view or add a comment, sign in
-
🔍 How JavaScript REALLY executes your code — a quick breakdown Most of us write JS every day, but rarely think about what happens before our code runs. Here's the journey V8 takes with every JS file: 1. Tokenization — raw text is broken into tokens (keywords, literals, operators) 2. AST Generation — tokens form an Abstract Syntax Tree, a hierarchical map of your code's structure 3. Ignition (Bytecode) — the AST is compiled into bytecode. Code starts running immediately — no need to wait for full machine code compilation 4. TurboFan (Machine Code) — hot functions (called repeatedly) get compiled into optimized native machine code But here's the part that matters for performance 👇 If TurboFan assumes a function always receives a number, and suddenly you pass a string — it deoptimizes. Falls back to the interpreter. Your any types in TypeScript aren't just a code smell — they're a V8 performance problem. And then there's the Event Loop: Call Stack → Microtask Queue → Task Queue Promises resolve before setTimeout, always Microtasks spawning microtasks can starve your render pipeline — real cause of UI freezes you can't explain Small things compound at platform scale. #JavaScript #WebPerformance #FrontendEngineering #StaffEngineer #V8 #PlatformEngineering
To view or add a comment, sign in
Explore related topics
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