Underscore: _.chain и _.each не играют вместе?

Правильно. В отличие от map , each не имеет возвращаемого значения , поэтому вызов value для него ничего не дает. Если вам нужно передать измененный массив по цепочке, лучше всего придерживаться map .

хорошо, карта, как насчет _.chain (). tap (function (values) {values.forEach (function (current) {};});
не кажется элегантным, но кажется логичным ...

Да, выглядит хорошо мной:

_.chain([1,2,3,4])
 .tap(_.bind(console.log, console))
 .map(function(val) { return val * 2 })
 .value(); // [2,4,6,8]

Было бы неплохо упомянуть, что каждый из них не возвращает значение в документации.

@xixixao each следует семантике Array # forEach, которая также не возвращает никакого значения. Если вам нужно что-то вернуть, просто используйте map .

Я не вижу ничего, что мешало бы Underscore сделать цепочку _.each . Он нарушает собственную семантику для других методов. Есть тонкие различия с предложением _.map как будто он не возвращает тот же массив и требует возвращаемого значения в обратном вызове.

Почему каждый должен быть связан? Вы никоим образом не изменяете массив (как с чем-то вроде карты или фильтра), поэтому нет никаких ожиданий, что значение будет повторно использовано.

Почему каждый должен быть связан?

Почему бы не разрешить цепочку, что может повредить? Это удобно для таких случаев, как _(collection).each(intermediateActions).filter(...) .

Я бы сделал метод неопределенным в контексте обернутого объекта.

@ dw40, но что вы делаете в тех промежуточных действиях, которые лучше не обрабатывать с помощью карты?

но что вы делаете в тех промежуточных действиях, которые не могут быть лучше обработаны картой?

На самом деле не имеет значения, что такое промежуточный шаг, это может быть несколько вещей, преимущество _.each chaining заключается в том, что промежуточный обратный вызов не должен возвращать значение, и ему не нужно создать новый массив.

@ dw40 хотите быстро потянуть? Вы говорите о специальной оболочке each как о части смешивания, верно?

@ akre54 Я знаю, что each следует за forEach , я буквально имел в виду, что было бы неплохо упомянуть поведение в документации.

Тем не менее, я согласен с тем, что каждый должен просто возвращать исходную коллекцию для связывания (всегда, независимо от синтаксиса, с которым вызывается each ).

Вы говорите о специальных оболочках как части смеси, верно?

Проще, чем это. Просто получите _.each return obj . Не нужно особого случая.

Но тогда вы нарушаете соответствие спецификации. Это не то, что делает each .

Но тогда вы нарушаете соответствие спецификации. Это не то, что делает each .

Я ранее писал:

Я не вижу ничего, что мешало бы Underscore сделать _.each цепочкой. Он нарушает собственную семантику для других методов.

Я не считаю это большим делом. Подчеркивание уже частично связано со специфицированным поведением для улучшения удобства использования разработчика несколькими методами. Например, в edge _.keys(...) не генерирует, если переданный аргумент не является объектом, а такие методы, как _.every и _.some работают, если вы не передаете iterator .

Я не думаю, что это большое изменение, но определенно неожиданно, что each вернет что-нибудь, не говоря уже о переданном значении (и гораздо больший разрыв спецификации, чем проверка нулевых аргументов).

Чтобы было ясно, вы говорите об этом изменении, верно?

diff --git a/underscore.js b/underscore.js
index 7a30b0a..2b56536 100644
--- a/underscore.js
+++ b/underscore.js
@@ -74,7 +74,7 @@
   // Handles objects with the built-in `forEach`, arrays, and raw objects.
   // Delegates to **ECMAScript 5**'s native `forEach` if available.
   var each = _.each = _.forEach = function(obj, iterator, context) {
-    if (obj == null) return;
+    if (obj == null) return obj;
     if (nativeForEach && obj.forEach === nativeForEach) {
       obj.forEach(iterator, context);
     } else if (obj.length === +obj.length) {
@@ -87,6 +87,7 @@
         if (iterator.call(context, obj[keys[i]], keys[i], obj) === breaker) return;
       }
     }
+    return obj;
   };

Чтобы было ясно, вы говорите об этом изменении, верно?

Правильно.

Мне все равно, так или иначе, но было бы хорошо услышать от большего количества людей о реальных вариантах использования за или против этого перед слиянием.

Я думаю, ты справишься. Было бы немного полезнее.

На мой взгляд, по крайней мере, при работе в связанном контексте выполнение _.each возвращаемого значения является ожидаемым поведением, поэтому +1 :)

@LeonFedotov @ dw40 , попробуйте.

@ akre54 Замечательно .

@ akre54 отлично, спасибо!

Что интересно, мы вернулись к поведению до версии 1.1.3.

Следующее дополнение к примечаниям к выпуску 1.1.3 было сделано в 3b916a2cf788a4588f08323c39786b6fb5ddbca6:

_.each больше не возвращает повторяющуюся коллекцию для улучшения согласованности с forEach ECMA5.

Ха. Я знал, что это мне показалось знакомым. Хорошее место.
1 февраля 2014 г. в 23:23 "Дэвид Чемберс" на [email protected] написал:

Что интересно, мы вернулись к поведению до версии 1.1.3.

Следующее дополнение к примечаниям к выпуску 1.1.3 было сделано в 3b916a2 https://github.com/jashkenas/underscore/commit/3b916a2cf788a4588f08323c39786b6fb5ddbca6
:

_.each больше не возвращает повторяющуюся коллекцию для улучшения
согласованность с ECMA5 forEach.

Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/jashkenas/underscore/issues/1391#issuecomment -33883825
.

Есть ли теперь альтернативный метод, который можно связать в цепочку и который позволяет изменять элементы массива на месте? Я искал что-то вроде peek :

_.chain(myArray)
    ...
    .peek(e -> e.craftedVar = e.otherVar * 2)
    ...
    .value();