Lodash reduce with Include或orderBy iteratee用例

Question

从reduce的lodash文档中：

_.reduce(collection, [iteratee=_.identity], [accumulator])

将集合减少为一个值，该值是通过iteratee运行集合中每个元素的累积结果，其中每个后续调用都提供了前一个元素的返回值。如果未给出累加器，则使用集合的第一个元素作为初始值。iteratee由四个参数调用：（累加器、值、索引|键、集合）。

许多lodash方法被保护为像x这样的方法的迭代对象。减少。右减速器，和。使改变

受保护的方法有：assign、defaults、defaultsDeep、includes、merge、orderBy和sortBy

我可以看到减少如何应用于大多数其他方法，因为它们大致遵循方法签名。例如，分配和默认值的形式（在非正式的TypeScript类型的伪代码中）：

_.assign and _.defaults: (object: object, sources: collection) => object
                          ^ accumulator   ^ value                 ^ same type as accumulator

类似地，sortBy也有意义：

_.sortBy: (collection: object, iteratees: sort_fn[]) => object
           ^ accumulator       ^ value                  ^ same type as accumulator

我可以看到这些有用的用例，例如：

console.log('reduce',
    _.reduce([{a: 2, b: 4}, [123, 52], {a: 5}], _.assign),
    _.reduce([{a: 2, b: 4}, [123, 52], {a: 5}], _.defaults),
    _.reduce([[e => e.a], [e => e.b]], _.sortBy,
      [{a: 3, b: 2}, {a: 3, b: 3}, {a: 2, b: 15}, {a: -2, b: 3}])
);

<script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.15/lodash.min.js"></script>

但是，我不确定这将如何用于orderBy和includes。即。，

_.orderBy: (collection: object, iteratees: sort_fn[], orders: ('asc' | 'desc')[]) => object
            ^ accumulator       ^ value               ^ index???                     ^ same type as accumulator

查看源代码并跟踪一些方法调用，似乎仍然可以工作，尽管第三个参数是'asc'|'desc'值的数组（由于保护，它特别对待它）。最终，通过保护，它似乎将所有的顺序默认为asc，所以它的行为就像sortBy。

console.log('reduce',
    _.reduce([[e => e.a], [e => e.b]], _.orderBy,
      [{a: 3, b: 2}, {a: 3, b: 3}, {a: 2, b: 15}, {a: -2, b: 3}])
);

html lang-html prettyprint-override"><script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.15/lodash.min.js"></script>

因此，如果以这种方式使用，保护似乎不是很有用，只是使其成为sortBy的替代，有效地使订单参数变得无用。

对于includes，我甚至不确定如何将其用作reducer函数，因为其返回类型（布尔值）与其第一个参数不同，例如：

_.includes: (collection: object, value: any) => boolean
             ^ accumulator       ^ value        ^ not same type as accumulator?

我的问题是：有没有任何方法（有效地）使用_. orderBy和_。包括作为_。减少或_。转换迭代？如果不是的话，那为什么lodash留档把它列为可以这样使用的受保护函数呢？

_{如果这听起来有点像两个问题，我很抱歉，但我认为他们之间有足够的关联，所以他们属于一起}

Answer 1

我的猜测是，在_的情况下。包括，它从来没有被保护用于_。减少，相反，这要么是多年前的一个失误仍然存在或者需要更好地澄清文档的这一部分。

相反，他们添加guard参数的目的是使其可用于。每个，\。部分应用时，一些等。

像这样：

_.every([1, 2], _.partial(_.includes, [1, 2, 3, 4])) // => true
_.every([1, 5], _.partial(_.includes, [1, 2, 3, 4])) // => false

我试图替换我的代码的特定部分，用一些丑陋的_. filters，_. clones和！_包含更优雅的东西。

然后，我试着，就像我在这些情况下通常做的那样，扫描洛塔什文档，试图提升我大脑中的创造力。

然后我在你提到的文档中找到了同样的一行，在玩了一点\ux之后。减少和\。包括，得出与您相同的结论。这毫无意义。

考虑到我可能错了，我在谷歌上搜索了一下，希望能找到一些聪明的例子，最后就到了这里。

很高兴看到我在这个世界上没有疯，或者至少没有一个人疯，但是它仍然没有触及我大脑中的痒，因为这个问题没有答案（截至我写这篇文章的时候）。

所以我去了剩下的最后一个地方，在那里我可以试着挖掘一些信息：源代码。

在一次又一次的指责之后，我终于找到了导致这种改变的promise。

其中最有趣的部分是添加到中的测试。包括测试的部分：

      strictEqual(_.includes([-0], 0), true);
    });

+   test('should work as an iteratee for methods like `_.reduce`', 1, function() {
+     var array1 = [1, 2, 3],
+         array2 = [2, 3, 1];
+
+     ok(_.every(array1, _.partial(_.includes, array2)));
+   });
+
    test('should be aliased', 2, function() {
      strictEqual(_.contains, _.includes);
      strictEqual(_.include, _.includes);

但是，仔细看，您会发现它不会测试与相关的任何内容。完全减少！

所以下一站，我去了测试套件，试图找到任何与该功能相关的额外测试，这些测试可以在提交后添加，有趣的是，我发现恰恰相反！

显然，有一天，整个测试套件都发生了巨大的变化，将使用与实际测试功能无关的lodash函数的所有地方替换为使用第二个旧（稳定）lodash实例，可能是为了避免一个可能使测试无法捕获的错误，而这个错误可能使测试无法捕获可能。。。

在这一变化中，有人被迫实际关注测试套件中的每一位，，并可能意识到对特定测试的描述根本没有意义。

于是他们改变了它：

       assert.strictEqual(_.includes([0], -0), true);
     });

-    QUnit.test('should work as an iteratee for methods like `_.reduce`', function(assert) {
+    QUnit.test('should work as an iteratee for methods like `_.every`', function(assert) {
       assert.expect(1);

       var array1 = [1, 2, 3],
           array2 = [2, 3, 1];

-      assert.ok(_.every(array1, _.partial(_.includes, array2)));
+      assert.ok(lodashStable.every(array1, lodashStable.partial(_.includes, array2)));
     });
   }(1, 2, 3, 4));

最后，但并非最不重要的一点是，我试着阅读\ux的源代码。每个功能都是在提交之前在中添加保护的功能。包括函数，但这并没有给我预期的快速答案，所以我得到了3.5版。CDN中的0（这是最后一个在\uu.includes功能中没有更改的版本），直接包含在

瞧，它不起作用。

所以我得出的结论是，最初的意图可能是让这个案例（使用_。每个函数）工作，但是在文档中，他们意外地将其添加到与<--plhd一起使用的受保护函数列表中减少函数。或者，他们只是依赖于短语中的“方法”，并认为把它放在那里就足够了，因为从技术上讲，它并没有具体地与_。减少函数联系在一起。

无论如何，我在lodash回购协议中提出了一个问题，试图引起人们的注意。