Underscore: __.union은 객체 배열에서 작동하지 않습니다.

나는 그것이 이미 비교 기능을 허용하지 않는다는 것에 놀랐습니다. :+1:

이것이 차이, 교차, 고유 등과 같은 다른 모든 배열 계산 함수에 적용된다는 점을 지적할 가치가 있습니다.

객체에 대해 다른 동등 비교기를 사용할 수 있도록 전체 배열 함수 제품군을 업데이트할 수 있다면 좋을 것입니다.

_.union() 함수에 전달할 수 있는 부울 매개변수 값을 기반으로 동등성을 비교하는 옵션이 있다면 더 쉽지 않을까요? true이면 해당 배열의 모든 객체를 자동으로 비교합니다.

예를 들어 _.union([1, 2, 3, 10, [{a:1}, {a:1}]], true) , 출력 [1,2,3,10, {a:1}]

@amiral84 아니요. 그건 관련이 없습니다. 그 동작을 원하면 flatten으로 union을 구성하십시오.

@michaelficarra 그럼 제가 이 주제의 요점을 놓쳤나요? :NS

@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 대신 === 컬렉션의 경우에 좋은하지 않습니다있다.

@dperrymorrow

사용해야 _.isEqual 대신 === 컬렉션의 경우에 좋은하지 않습니다있다.

동적 전환은 나쁜 생각처럼 들립니다. JS는 많은 것에 대해 === 또는 SameValueZero 비교를 사용합니다. 이러한 비교에서 벗어날 필요가 있는 경우 _.uniqWith 와 같은 것이 가능합니다.

@jdalton 덕분에 언급한 _opWith 함수는 내가 달성하려는 것에 절대적으로 완벽합니다. 출시를 통해 언제 사용할 수 있는지 알 수 있습니까?

@jdalton 비교에 대한 좋은 지적이지만 일반적으로 Underscore가 개체 간의 전체 차이를 감지하도록 하는 대신 컬렉션에서 고유한 키를 사용하지 않습니까?

다음은 @wilhen01 의 요청을 해결하지 않을까요 _(원하는 것보다 더 장황하긴 하지만)_

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

다음은 @wilhen01 의 요청을 해결하지 못할 것입니다(원하는 것보다 더 장황하긴 하지만)

_.uniq 이미 지원하고 있습니다.

네, 제 요점입니다. 위의 코드는 현재 게시된 대로 작동합니다.
결합 결과에 대한 키를 사용하여 uniq/unique를 호출할 수 없습니까?

@dperrymorrow 그 예에서 조금 벗어나서 다른 속성을 추가하십시오 .

알았어, 알았어, 미안... 난 호전적이지 않고 그냥 문제를 완전히 이해하고 싶었어. _.uniqWith 함수에 대한 pull 요청을 제출하고 싶습니다.

걱정마세요.

_.intersectionWith, _.differenceWith, _.unionWith 및 _.uniqWith

4개의 새로운 함수를 만드는 대신 비교 함수를 최종 인수로 선택적으로 전달할 수 있도록 하는 것이 API가 더 좋지 않을까요?

@jashkenas

4개의 새로운 함수를 만드는 대신 비교 함수를 최종 인수로 선택적으로 전달할 수 있도록 하는 것이 API가 더 좋지 않을까요?

예, 할 수 있지만 _.uniq 와 같은 메서드는 이미 iteratee 전달을 지원하고 바이너리/정렬된 검색 플래그 및 컨텍스트 매개변수에 대한 지원으로 과부하가 많이 걸리기 때문에 복잡합니다. 이것은 이 상황에 너무 영리하게 느껴지는 arity 스니핑을 도입하는 것을 의미합니다. 이것은 또한 구현을 단순화하고 별도의 방법으로 분할할 수 있는 단일 지점에 많은 선택적 기능을 번들로 제공하기 때문에 향후 모듈화 노력을 복잡하게 만듭니다.

맞습니다. 완전히 불행한 디자인 문제입니다. 그러나 비교기를 허용하기 위해 새로운 기능을 만드는 것도 올바른 솔루션처럼 느껴지지 않습니다.

자, 그럼 추가 비교 함수 매개변수가 여기로 가는 길입니까?
그렇다면 내 pull 요청을 업데이트할 수 있습니다.

내가 예상하는 유일한 까다로운 부분은 위에서 언급한 @jdalton 처럼 매개변수 구문 분석을 좀 더 털이 많은 것으로

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

아마도 isSorted _.isFunction 인지 확인하기 위해 추가 검사를 추가한 다음 이를 비교기로 처리할 수 있습니다.

@jashkenas

그러나 비교기를 허용하기 위해 새로운 기능을 만드는 것도 올바른 솔루션처럼 느껴지지 않습니다.

그것은 나쁜 상황에 대한 최선의 선택이 될 수 있습니다. 나는 최근에 과부하된 기능을 분리하기 시작했고 그 결과에 꽤 만족했습니다. API 표면을 증가시키지만 maxBy , uniqBy , pickBy 또는 uniqWith , unionWith 와 같은 유사한 주제의 메서드를 더 간단하게 구현하고 그룹화할 수 있습니다 uniqBy unionWith , zipWith 또는 sortedIndexBy , sortedIndexOf , sortedUniq . uniq 경우 현재 공유 기반 기능을 여전히 사용하고 있습니다.

이 pull request #2368을 업데이트했습니다. 감사합니다.

저는 :+1: uniqBy 또는 uniqWith 입니다. 나는 uniq 추가로 오버로딩하는 것에 대해 완전히 반대할 것입니다(현재 #2368이 제안됨)

:+1: @megawac , uniqBy .

Fwiw lodash는 uniqBy 를 _.uniq(array, iteratee) 의 분할 형식으로 사용하고 _.uniqWith 를 비교기 사용자 지정을 허용하는 형식으로 사용합니다.

예, 생각해보면 uniqWith 가 더 나은 이름입니다.

그렇다면 별도의 방법으로 Lodash에서 요청을 가져와야 합니까?
두 프로젝트가 합쳐진 줄 알았는데 착각인가요?

@dperrymorrow

그런 다음 별도의 방법으로 Lodash에서 요청을 가져와야합니까?

필요 없습니다. 이미 lodash의 edge master 브랜치에 있습니다.

두 프로젝트가 합쳐진 줄 알았는데 착각인가요?

아직. Lodash v4는 병합의 아이디어 중 일부를 증명합니다.

@jdalton 다른 반복자와 함께 _.uniqWith 구현에 대해 좀 더 자세히 설명해 주시겠습니까?

@파브니
확신하는. lodash/npm/_baseUniq 를 확인할 수 있습니다.
comparator 가 전달되면 arrayIncludes (Underscore의 contains ) 대신 arrayIncludesWith 도우미를 사용하여 검사를 수행합니다.

@jdalton 도움이 됩니다.