标签：#array

TypeScript Compile Error TS2802: Resolved with Observer Pattern by Converting Set Spread to Array.from If you're stuck implementing the observer pattern due to TypeScript compile error TS2802, this post might help. I resolved the issue with a simple conversion: changing Set spread to Array.from() . Attempts and Pitfalls While implementing the observer pattern, I encountered TypeScript compile error TS2802 when trying to spread a Set. Initially, I suspected the Set's type might be the problem, so I tried various approaches. class Observer { private subscribers = new Set < () => void > (); subscribe ( callback : () => void ) { this . subscribers . add ( callback ); } notify () { // TS2802 error occurs here for ( const callback of [... this . subscribers ]) { callback (); } } } When attempting to spread the Set into an array using [...this.subscribers] as shown above, TypeScript failed to recognize it properly, throwing an error similar to TS2802: Cannot find module '...' or its corresponding type declarations. . At first, I thought it was a library configuration issue and spent a considerable amount of time lost. The Cause In the end, the problem lay with the Set spread syntax itself. When TypeScript applies the ... spread operator to a Set, there were instances where it couldn't accurately infer the types internally. This issue can be more pronounced in certain versions or environments. The Solution To resolve this, I used the method of explicitly converting the Set spread to an array using Array.from() . class Observer { private subscribers = new Set < () => void > (); subscribe ( callback : () => void ) { this . subscribers . add ( callback ); } notify () { // Resolved by converting with Array.from for ( const callback of Array . from ( this . subscribers )) { callback (); } } } By using Array.from(this.subscribers) , TypeScript clearly recognizes the Set as an array, allowing the loop to execute correctly. The Outcome The TypeScript compile error TS2802 was cleanl

There's been no shortage of debate lately about whether grinding Leetcode still makes sense in the age of AI. I think it does. AI is a powerful tool, but it was built by humans; which means it inherited our strengths, our blind spots, and our biases. Leaning on it entirely without understanding what's happening under the hood is a risk. A mentor once told me: those who refuse to use AI are not hireable. But neither are those who rely on it entirely. Learning deeply is how you stay on the right side of that line. This is my journey into just that - learning deeply. Day 1 Leetcode 88: Merge Sorted Array This is an interesting problem. You begin with 4 pieces of data — 2 arrays and 2 integers: nums1 : a sorted array whose length equals nums1.length + nums2.length . The first m elements are valid numbers; the remaining indexes hold 0 s as placeholders. nums2 : a sorted array containing only valid numbers, with a length of n . m : the count of valid numbers in nums1. n : the count of valid numbers in nums2. The objective is to merge both arrays into sorted order in place . Since nums1 is already sized to hold every valid element from both arrays, it's where the final sorted result will live. Approach 1: Naive (Splice + Sort) This solution is 2 lines of code. That's it. It's a testament to how much ES6 advanced JavaScript. nums1 . splice ( m , n , ... nums2 ); nums1 . sort (( a , b ) => a - b ); Here's how it works. We start by calling .splice() on nums1. While .splice() has many use cases, here's what each argument is doing in this context: m : the index where we start deleting elements. Since m is the count of valid numbers in nums1, starting at index m puts us right at the first placeholder 0 — exactly where we want to be. n : the number of elements to delete. Since n equals the length of nums2, we're deleting exactly as many placeholders as we have values to insert. ...nums2 : the values we want to insert in place of the deleted elements. The ... is the spread operato