Underscore: _. الاتحاد لا يعمل مع مصفوفات الكائنات

أنا مندهش من أنه لا يقبل بالفعل وظيفة المقارنة. : +1:

تجدر الإشارة إلى أن هذا ينطبق على جميع وظائف حساب المصفوفات الأخرى مثل الاختلاف والتقاطع والفريد وما إلى ذلك.

سيكون من الرائع أن يتم تحديث المجموعة الكاملة من وظائف الصفيف للسماح باستخدام مقارن مساواة مختلف للكائنات.

ألن يكون من الأسهل إذا كان لدينا خيار يقارن المساواة بناءً على قيمة المعلمة المنطقية التي يمكن تمريرها إلى دالة _.union ()؟ إذا كان هذا صحيحًا ، فسيتم مقارنة جميع الكائنات في تلك المصفوفة تلقائيًا.

على سبيل المثال ، سينتج _.union([1, 2, 3, 10, [{a:1}, {a:1}]], true) [1,2,3,10, {a:1}]

@ amiral84 رقم لا علاقة له. إذا كنت تريد هذا السلوك ، فقم بتكوين اتحاد مع تسطيح.

michaelficarra إذن هل

@ amiral84 يبدو كذلك. تم شرح طلب الميزة بشكل كامل وموجز في التعليق الأول.

يبدو أن المشكلة الأساسية موجودة في _.uniq حيث أن _.union مجرد وظيفة مجمعة لفريدة من نوعها ومسطحة.

_.union = restArgs(function(arrays) {
  return _.uniq(flatten(arrays, true, true));
});

ألهمني هذا الموضوع لإضافة _.intersectionWith ، _.differenceWith ، _.unionWith ، و _.uniqWith للتعامل مع تخصيص المقارنة في الكود الخاص بي.

var array = [ { 'a': 1, 'b': 2 }, { 'a': 1, 'b': 3 }, { 'a': 1, 'b': 2 } ];

_.uniqWith(array, _.isEqual);
// => [{ 'a': 1, 'b': 2 }, { 'a': 1, 'b': 3 }]

أو شيء على غرار _.isCollection لتحديد ما إذا كنت تتعامل مع مجموعة. في حالة التعامل مع مجموعة ، يجب أن تستخدم المقارنات _.isEqual بدلاً من === وهو أمر لا يجدي نفعاً في حالة المجموعة.

تضمين التغريدة

يجب استخدام _.isEqual بدلاً من === وهو ما لا يفيد في حالة المجموعة.

يبدو التبديل الديناميكي فكرة سيئة. يستخدم JS مقارنات === أو SameValueZero للعديد من الأشياء. إذا كانت هناك حاجة للخروج من هذه المقارنات ، فإن شيئًا مثل _.uniqWith سيفعله.

شكرًا لهذا jdalton ، وظائف _opWith التي ذكرتها مثالية تمامًا لما أحاول تحقيقه. هل لديك أي فكرة عن موعد توفرها عبر الإصدار؟

jdalton نقطة جيدة في المقارنات ، لكن ألا تستخدم عادةً مفتاحًا فريدًا في مجموعة بدلاً من إجبار الشرطة السفلية على اكتشاف الاختلاف الكامل بين الكائنات؟

ألن يحل ما يلي طلب @ wilhen01 _ (وإن كان مطولاً أكثر مما هو مطلوب) _

_.chain([{ a: 1 }]).union( [{a: 1}]).unique('a').value();
//=> [{a: 1}]

لن يحل ما يلي طلب @ wilhen01 (وإن كان مطولاً أكثر مما هو مطلوب)

_.uniq يدعم ذلك بالفعل.

صحيح ، هذه وجهة نظري ، الكود أعلاه يعمل حاليًا كما تم نشره.
ألا يمكنك فقط استدعاء uniq / فريد بمفتاح على نتيجة الاتحاد؟

dperrymorrow فكر قليلاً خارج هذا المثال وأضف خاصية أخرى .

حسنًا ، مسكتك ، آسف ... أنا لا أحاول أن أكون عدوانية ، أردت فقط أن أفهم المشكلة تمامًا. أحب إرسال طلب سحب على وظيفة _.uniqWith .

لا تقلق ، سيكون ذلك رادًا.

_. التقاطع مع _. الفرق مع _. الاتحاد مع و _. uniq مع

ألن تكون واجهة برمجة تطبيقات أجمل للسماح فقط بتمرير وظيفة المقارنة اختياريًا كحجة أخيرة ، بدلاً من سك أربع وظائف جديدة؟

تضمين التغريدة

ألن تكون واجهة برمجة تطبيقات أجمل للسماح فقط بتمرير وظيفة المقارنة اختياريًا كحجة أخيرة ، بدلاً من سك أربع وظائف جديدة؟

نعم ، يمكن القيام بذلك ولكن هناك تعقيدات لأن طرقًا مثل _.uniq تدعم بالفعل تمرير تكرار ومثقل بشكل كبير بدعم إشارات البحث الثنائية / المصنفة ومعلمات السياق أيضًا. قد يعني هذا إدخال استنشاق الهواء الذي يبدو ذكيًا للغاية بالنسبة لهذا الموقف. سيؤدي هذا أيضًا إلى تعقيد جهود النمذجة المستقبلية لأنه يجمع الكثير من الوظائف الاختيارية في نقطة واحدة عندما يمكن تبسيط عمليات التنفيذ وتقسيمها إلى طرق منفصلة.

صحيح ، مشكلة تصميم مؤسفة تمامًا. لكن إنشاء وظائف جديدة فقط للسماح للمقارن لا يبدو أنه الحل الصحيح أيضًا.

حسنًا ، لذا فإن معلمات وظيفة المقارنة الإضافية هي السبيل للذهاب هنا إذن؟
إذا كان الأمر كذلك يمكنني تحديث طلب السحب الخاص بي.

الجزء الصعب الوحيد الذي أتوقعه هو جعل تحليل المعلمة أكثر كثافة بقليل مثل

_.uniq = _.unique = function(array, isSorted, iteratee, context) {
  if (!_.isBoolean(isSorted)) {
    context = iteratee;
    iteratee = isSorted;
    isSorted = false;
  }
//...

ربما يتم إضافة فحص إضافي لمعرفة ما إذا تم فرز _.isFunction ثم معاملته كمقارن.

تضمين التغريدة

لكن إنشاء وظائف جديدة فقط للسماح للمقارن لا يبدو أنه الحل الصحيح أيضًا.

قد يكون الخيار الأفضل لموقف سيء. لقد بدأت مؤخرًا في تقسيم الوظائف المثقلة بالأعباء وكنت سعيدًا جدًا بالنتيجة. على الرغم من أنه يزيد من سطح واجهة برمجة التطبيقات ، إلا أنه يسمح بتطبيقات أبسط وتجميع للطرق ذات الموضوعات المتشابهة مثل maxBy أو uniqBy أو pickBy أو uniqWith أو unionWith ، zipWith ، أو sortedIndexBy ، sortedIndexOf ، sortedUniq . في حالة uniq الرغم من أنني ما زلت أستخدم وظيفة أساسية مشتركة في الوقت الحالي.

تم تحديث طلب السحب هذا # 2368 شكرًا.

أنا: +1: مقابل uniqBy أو uniqWith . سأكون ضد التحميل الزائد على uniq إضافيًا (كما هو مقترح # 2368 حاليًا)

: +1: megawac ، uniqBy .

سوف يستخدم Fwiw Lodash uniqBy كنموذج تقسيم _.uniq(array, iteratee) و _.uniqWith كنموذج للسماح بتخصيص المقارنة.

نعم ، في المرة الثانية ، كان الفكر uniqWith هو اسم أفضل

هل يجب علي سحب الطلب على Lodash بالطريقة المنفصلة بعد ذلك؟
ظننت أن المشروعين تم دمجهما ، هل أنا مخطئ؟

تضمين التغريدة

هل يجب أن أسحب الطلب على Lodash بالطريقة المنفصلة بعد ذلك

لا حاجة ، هم بالفعل في فرع لوداش الرئيسي.

ظننت أن المشروعين تم دمجهما ، هل أنا مخطئ؟

ليس بعد. برهان Lodash v4 على بعض أفكار الدمج.

jdalton هل يمكنك من فضلك توضيح عنوان أكثر على تنفيذ _.uniqWith مع مكررات أخرى.

تضمين التغريدة
بالتأكيد. يمكنك التحقق من Lodash / npm / _baseUniq .
إذا كان comparator يتم تمرير أنه يستخدم arrayIncludesWith المساعد للقيام الاختيار بدلا من arrayIncludes (تسطير ل contains ).

jdalton هذا يساعدني.