当前位置：首页 > 文章列表 > 文章 > 前端 > LeetCode 的 JavaScript 时代实际上填补了空白

LeetCode 的 JavaScript 时代实际上填补了空白

来源：dev.to 2024-12-22 11:43:02 0浏览收藏

哈喽！今天心血来潮给大家带来了《LeetCode 的 JavaScript 时代实际上填补了空白》，想必大家应该对文章都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习文章，千万别错过这篇文章~希望能帮助到你！

大多数编码挑战都会教你解决难题。 leetcode 的 30 天 javascript 学习计划做了一些不同的事情：它向您展示了拼图如何变成砖块，准备好构建现实世界的项目。

这种区别很重要。当您解决典型的算法问题时，您正在训练您的思维进行抽象思考。但是，当您实现去抖¹函数或构建事件发射器²时，您正在学习真正的软件是如何工作的。

我自己在应对挑战时发现了这一点。这种体验不太像解决脑筋急转弯问题，而更像考古学——揭示特定的现代 javascript 概念。每个部分都重点介绍 js 的另一项现代功能。

这个学习计划的奇特之处在于它不会教你 javascript。事实上，我相信您需要相当了解 javascript 才能从中受益。相反，它教的是如何使用 javascript 来解决实际的工程问题。

考虑 memoize³ 挑战。从表面上看，它是关于缓存函数结果的。但你真正学到的是为什么像 react 这样的库需要记忆来有效地处理组件渲染。或者以 debounce¹ 问题为例 - 这不仅仅是实现延迟；它还涉及延迟。它可以帮助您直接理解为什么每个现代前端框架、电梯以及基本上任何具有交互式 ui 的系统都需要这种模式。

这种对实用模式而不是语言基础知识的关注创造了一个有趣的限制；您需要处于以下两个位置之一才能受益：

您了解 cs 基础知识（尤其是数据结构和算法）并且熟悉 javascript
您的计算机科学理论很强，并且之前接触过一些 javascript

连接计算机科学和软件工程

学习计算机科学和实践软件工程之间会发生一些奇怪的事情。这种转变感觉就像学习了多年的国际象棋理论，却发现自己在玩一种完全不同的游戏 - 规则不断变化，而且大多数动作都不在任何书本中。

在计算机科学中，您将学习二叉树的工作原理。在软件工程中，您需要花费数小时调试 api，试图了解响应缓存不起作用的原因。从远处看，这些世界之间的重叠可能看起来比实际要大得多。其中存在差距，这常常会让计算机科学毕业生在开始职业生涯时感到震惊。不幸的是，大多数教育资源都无法弥补这一点。它们要么纯粹是理论性的（“这是快速排序的工作原理”），要么是纯粹的实用性（“这是如何部署 react 应用程序”）。

这个 javascript 学习计划的有趣之处并不是它设计得特别好 - 而是它在这些世界之间创建了联系。以记忆问题为例：2623。记忆³。用计算机科学术语来说，它是关于缓存计算值的。但实现它会迫使您应对 javascript 在对象引用、函数上下文和内存管理方面的特殊性。突然，
您不仅仅是在学习算法 - 您开始理解为什么像 redis 这样的东西存在。

这种风格在整个挑战中不断重复。 event emitter² 实现不仅仅是教科书观察者模式 - 您可以将其视为将 v8 引擎从浏览器中取出并围绕它构建 node.js 的原因，这实际上是有意义的。 promise pool⁴ 解决并行执行问题，也就是数据库需要连接限制的原因。

隐藏课程

本学习计划中的问题顺序不是随机的。它正在逐层构建现代 javascript 的心理模型。

它从闭包开始。并不是因为闭包是最简单的概念 - 它们非常令人困惑 - 而是因为它们是 javascript 管理状态的基础。

function createcounter(init) {
    let count = init;
    return function() {
        return count++;
    }
}

const counter1 = createcounter(10);
console.log(counter1()); // 10
console.log(counter1()); // 11
console.log(counter1()); // 12

// const counter1 = createcounter(10);
// when this^ line executes:
// - createcounter(10) creates a new execution context
// - local variable count is initialized to 10
// - a new function is created and returned
// - this returned function maintains access 
// to the count variable in its outer scope
// - this entire bundle 
// (function (the inner one) + its access to count) 
// is what we call a closure

这种模式是 javascript 中所有状态管理的种子。一旦你了解了这个计数器的工作原理，你就了解了 react 的 usestate 在幕后是如何工作的。您了解为什么模块模式出现在 es6 之前的 javascript 中。

然后计划转向功能转换。这些教你函数装饰——函数包装其他函数以修改它们的行为。这不仅仅是一个技术技巧；这就是 express 中间件的工作方式，react 高阶组件的工作方式，
以及 typescript 装饰器的工作原理。

当您遇到异步挑战时，您不仅学习了 promise，而且还发现了 javascript 最初需要它们的原因。 promise pool⁴ 问题并不是在教你一个创新的、古怪的 js 概念；而是在教你一个创新的、古怪的 js 概念。它向您展示了为什么每个数据库引擎中都存在连接池。

以下是学习计划各部分与现实世界软件工程概念的粗略映射：

关闭 → 状态管理
基本数组变换 → 基本技能（辅助）；实际示例：数据操作
函数转换 → 中间件模式
承诺和时间 -> 异步控制流程
json -> 基本功（辅助）；实例：数据序列化、api通信
类（特别是在事件发射器的上下文中）→消息传递系统
奖励（高级锁定）-> 可能包含在上述部分中的更难挑战的混合； promise pool⁴ 是本节中我最喜欢的一个

模式识别，而不是解决问题

让我们剖析一些问题，以展示该学习计划的真正价值。

记忆 (#2623)

考虑 memoize 挑战。我喜欢它的原因是（我能想出的）最好的解决方案
非常简单，就好像代码本身在温和地告诉您它的作用（不过，我添加了一些注释）。

无论如何，这并不会让 #2623 成为一个简单的问题。我之前需要两次迭代才能使它变得如此干净：

/**
 * @param {function} fn
 * @return {function}
 */
function memoize(fn) {
    // create a map to store our results
    const cache = new map();

    return function(...args) {
        // create a key from the arguments
        const key = json.stringify(args);

        // if we've seen these arguments before, return cached result
        if (cache.has(key)) {
            return cache.get(key);
        }

        // otherwise, calculate result and store it
        const result = fn.apply(this, args);
        cache.set(key, result);
        return result;
    }
}

const memoizedfn = memoize((a, b) => {
    console.log("computing...");
    return a + b;
});

console.log(memoizedfn(2, 3)); // logs "computing..." and returns 5
console.log(memoizedfn(2, 3)); // just returns 5, no calculation
console.log(memoizedfn(3, 4)); // logs "computing..." and returns 7


// explanantion:
// it's as if our code had access to an external database

// cache creation
// const cache = new map();
// - this^ uses a closure to maintain the cache between function calls
// - map is perfect for key-value storage

// key creation
// const key = json.stringify(args);
// - this^ converts arguments array into a string
// - [1,2] becomes "[1,2]"
// - we are now able to use the arguments as a map key

// cache check
// if (cache.has(key)) {
//     return cache.get(key);
// }
// - if we've seen these arguments before, return cached result;
// no need to recalculate

反跳 (#2627)

想象一下你在电梯里，有人疯狂地反复按“关门”按钮。

按按按按按

没有去抖：电梯会在每按一次门时尝试关门，导致门机构工作效率低下，甚至可能损坏。

防抖：电梯会等待，直到人停止按下一定时间（假设 0.5 秒），然后才真正尝试关门。这样效率就高多了。

这是另一种情况：

假设您正在实现一个搜索功能，可以在用户键入时获取结果：

没有去抖动：

// typing "javascript"
'j' -> api call
'ja' -> api call
'jav' -> api call
'java' -> api call
'javas' -> api call
'javasc' -> api call
'javascr' -> api call
'javascri' -> api call
'javascrip' -> api call
'javascript' -> api call

这将进行 10 次 api 调用。其中大多数都没用，因为用户仍在打字。

带去抖动（300 毫秒延迟）：

// typing "javascript"
'j'
'ja'
'jav'
'java'
'javas'
'javasc'
'javascr'
'javascri'
'javascrip'
'javascript' -> api call (only one call, 300ms after user stops typing)

去抖就像告诉你的代码：“等到用户停止做某事 x 毫秒后再实际运行这个函数。”

这是 leetcode #2627 的解决方案：

/**
 * @param {Function} fn
 * @param {number} t milliseconds
 * @return {Function}
 */
var debounce = function (fn, t) {
  let timeoutID = null;
  return function (...args) {
    clearTimeout(timeoutID); // MDN reference: https://developer.mozilla.org/en-US/docs/Web/API/Window/clearTimeout
    timeoutID = setTimeout(() => {
      fn.apply(this, args);
    }, t);
  };
};

// tests
const log = debounce(console.log, 100);

console.log("Starting tests...");

setTimeout(() => log("Test 1"), 50); // should be cancelled
setTimeout(() => log("Test 2"), 75); // should be cancelled
setTimeout(() => log("Test 3"), 200); // should be logged at t=300ms

setTimeout(() => {
  console.log("Tests completed.");
}, 400);

// Explanantion:
// - we create a closure where timeoutID persists between calls
// - timeoutID starts out as null
// - we return the debounced version of the initial function

// const log = debounce(console.log, 100);
// - this^ creates a new closure with its own timeoutID
// - log is now the inner function

// setTimeout(() => log("Test 1"), 50);  // at t=50ms
// setTimeout(() => log("Test 2"), 75);  // at t=75ms
// setTimeout(() => log("Test 3"), 200); // at t=200ms

// t=50ms: 
// - log("Test 1") called
// - clears timeoutId (null, so nothing happens)
// - sets new timeout to run at t=150ms

// t=75ms: 
// - log("Test 2") called
// - clears previous timeout (cancels "Test 1")
// - sets new timeout to run at t=175ms

// t=200ms:
// - log("Test 3") called
// - clears previous timeout (cancels "Test 2")
// - sets new timeout to run at t=300ms

// t=300ms:
// - finally executes fn("Test 3")


// why this works:
// - the closure keeps timeoutId alive between calls
// - every new call cancels the previous timeout
// - only the last scheduled timeout actually runs

现实世界中其他常见的去抖动用例（搜索栏除外）：