lodash와 밑줄의 차이점 [닫힘]


1602

왜 누군가가 lodash.js 또는 underscore.js 유틸리티 라이브러리를 선호 합니까?

Lodash는 밑줄을 대체하는 것으로 보이며 후자는 더 오래되었습니다.

나는 둘 다 훌륭하다고 생각하지만, 그들이 교육 비교를하기 위해 어떻게 작동하는지에 대해 충분히 알지 못하며 차이점에 대해 더 알고 싶습니다.


2
github 페이지에 링크 된 lodash에 대한 일부 스크린 캐스트 를 살펴볼 수 있습니다. 개인적으로 underscore.js를 사용하고 있지만 그 이유는 내가 처음 시작한 것이기 때문에 더 오래되었습니다.
Jack

26
lodash그리고 underscore아래에 병합 스레드 지금
zangw

답변:


2022

배열, 문자열, 객체 및 arguments객체에 대해보다 일관된 교차 환경 반복 지원을 제공하기 위해 Lo-Dash를 만들었습니다 1 . 이후 Underscore의 상위 세트가되어보다 일관된 API 동작, 더 많은 기능 (AMD 지원, 딥 클론 및 딥 병합 등),보다 철저한 문서 및 단위 테스트 (노드, 링고, 코뿔소, 나르 왈, PhantomJS에서 실행되는 테스트)를 제공합니다. , 브라우저), 대규모 배열 / 객체 반복에 대한 전반적인 성능 및 최적화 향상, 사용자 지정 빌드 및 템플릿 사전 컴파일 유틸리티를 통한 유연성 향상 .

Lo-Dash는 Underscore보다 더 자주 업데이트 되므로 최신 안정적인 Underscore 버전과 호환되도록 lodash underscore빌드 가 제공 됩니다.

어느 시점 에서 LosDash가 30 개 이상의 문제를 제기 할 책임이 있기 때문에 Underscore에 대한 푸시 액세스 권한 도 부여되었습니다 . Underscore v1.4.x +의 랜딩 버그 수정, 새로운 기능 및 성능 향상.

또한 기본적으로 Lo-Dash를 포함하는 최소 3 개의 Backbone 상용구가 있으며 이제 Lo-Dash가 Backbone의 공식 문서에 언급되어 있습니다 .

Lo-Dash와 Underscore의 차이점에 대한 자세한 내용은 Kit Cambridge의 Post "Hello"to Lo-Dash 를 참조하십시오.

각주 :

  1. 밑줄은 배열, 문자열, 객체 및 arguments객체 를 일관되지 않게 지원 합니다. 최신 브라우저에서 Underscore 메소드는 배열의 구멍을 무시 하고 "Objects"메소드는 arguments객체를 반복 하고 문자열은 배열과 같이 취급되며, 메소드는 함수 ( "prototype"속성 무시)와 객체 ( "toString"과 같은 그림자 속성 반복)를 올바르게 반복합니다. "valueOf"), 이전 브라우저에서는 그렇지 않습니다. 또한 밑줄 방법 _.clone은 배열에 구멍을 유지하는 반면 다른 방법은 _.flatten그렇지 않습니다.

174
@Brian-Lo-Dash를 개발하는 동안 "LosDash에서 Underscore에 비해 부정적인 점으로 무엇을 지적 할 수 있습니까?"라는 질문을 계속했습니다. 그런 다음 해결하십시오. 그렇기 때문에 문서를 강화하고 사용자 지정 빌드를 추가했으며 소스를 더 읽기 쉽게 만들었습니다.
John-David Dalton

10
나는 벤치 마크를 게시하고 싶어하지만 지루해질 수 있습니다. 내가 실행하는 모든 벤치 마크가 Lo-Dash 가 밑줄보다 빠르다는 것이 입증되었다고 말할 수 있습니다 ( 많은 경우에 훨씬 빠름).
Wil Moore III

186
나는 lo-dash를 좋아하고 그것을 사용하고 있으므로 bash를 생각하지 말고 새 라이브러리를 만드는 대신 밑줄에 기여하지 않는 이유는 무엇입니까?
Xananax 2013

133
@ Xananax-코멘트 스레드를 확인하십시오 : github.com/jashkenas/underscore/commit/…- 이것은 그 질문에 대한 답이 될 수 있습니다.
Rob Grant

41
lodash를 밑줄로 다시 병합하려는 노력이 있습니까?
가로등

186

Lo-Dash는 밑줄에서 영감을 얻었지만 요즘에는 탁월한 솔루션입니다. 당신은 할 수 있습니다 사용자 정의 빌드 이, 더 높은 성능을 , AMD를 지원하고있는 훌륭한 추가 기능 . 이 확인 밑줄 벤치 마크 대비 소호 - 대시를 ..이 jsperf에와 보라 - 대시에 대한 멋진 게시물 :

컬렉션으로 작업 할 때 가장 유용한 기능 중 하나는 속기 구문입니다.

var characters = [
  { 'name': 'barney', 'age': 36, 'blocked': false },
  { 'name': 'fred',   'age': 40, 'blocked': true }
];

// using "_.filter" callback shorthand
_.filter(characters, { 'age': 36 });

// using underscore
_.filter(characters, function(character) { return character.age === 36; } );

// → [{ 'name': 'barney', 'age': 36, 'blocked': false }]

( lodash 문서 에서 가져온 )


1
Kit Cambridge의 블로그 링크는 매우 유익합니다.
Brian M. Hunt

나는 이것이 틀렸다고 생각합니다 (뽑는 예). 마지막 업데이트 1.8.3부터 lodash와 같은 방식으로 pluck을 사용할 수 있습니다. 어쨌든 이전 버전의 경우 밑줄이 맵과 같은 기능을 노출한다고 생각하지 않습니다 (밑줄 예제는 맵 기능처럼 보입니다)
alexserver

7
filter2012 년 밑줄의 기능 github.com/jashkenas/underscore/issues/648 (이름입니다 where)
무하마드 Hewedy

Lo-Dash vs Underscore 벤치 마크 링크에서 오류 500이 발생합니다
Hylle

86

저와 같이 밑줄과 lodash의 사용법 차이 목록을 기대하고 있다면 밑줄에서 lodash로 마이그레이션하기위한 안내서가 있습니다.

후손에 대한 현재 상태는 다음과 같습니다.

  • 밑줄 _.any은 Lodash입니다_.some
  • 밑줄 _.all은 Lodash입니다_.every
  • 밑줄 _.compose은 Lodash입니다_.flowRight
  • 밑줄 _.contains은 Lodash입니다_.includes
  • 밑줄 _.each은 반환하여 종료를 허용하지 않습니다false
  • 밑줄 _.findWhere은 Lodash입니다_.find
  • _.flatten기본적으로 밑줄 은 깊고 Lodash는 얕습니다.
  • Underscore _.groupBy는 매개 변수가 전달 된 iteratee를 지원하는 (value, index, originalArray)반면 Lodash에서는 iteratee _.groupBy가 단일 매개 변수 만 전달 (value)됩니다.
  • _.indexOf3 번째 매개 변수를 가진 밑줄 undefined은 Lodash입니다_.indexOf
  • _.indexOf3 번째 매개 변수를 가진 밑줄 true은 Lodash입니다_.sortedIndexOf
  • 밑줄 _.indexBy은 Lodash입니다_.keyBy
  • 밑줄 _.invoke은 Lodash입니다_.invokeMap
  • 밑줄 _.mapObject은 Lodash입니다_.mapValues
  • 밑줄 _.max은 Lodash _.max_.maxBy
  • 밑줄 _.min은 Lodash _.min_.minBy
  • 밑줄 _.sample은 Lodash _.sample_.sampleSize
  • 밑줄 _.object은 Lodash _.fromPairs_.zipObject
  • _.omit술어에 의한 밑줄 은 Lodash입니다._.omitBy
  • 밑줄 _.pairs은 Lodash입니다_.toPairs
  • _.pick술어에 의한 밑줄 은 Lodash입니다._.pickBy
  • 밑줄 _.pluck은 Lodash입니다_.map
  • 밑줄 _.sortedIndex은 Lodash _.sortedIndex_.sortedIndexOf
  • 밑줄 _.uniq로는 iterateeLodash입니다_.uniqBy
  • 밑줄 _.where은 Lodash입니다_.filter
  • 밑줄 _.isFinite이 정렬되지 않습니다 Number.isFinite
    (예 : 밑줄 에서 Lodash로 _.isFinite('1')반환 )truefalse
  • 밑줄 _.matches깊은 비교를 지원하지 않습니다 속기
    (예 _.filter(objects, { 'a': { 'b': 'c' } }))
  • 밑줄 ≥ 1.7 & Lodash _.template구문은
    _.template(string, option)(data)
  • Lodash _.memoize캐시는 Map객체와 같습니다
  • Lodash는 context많은 방법에 찬성론을 지지하지 않습니다._.bind
  • Lodash는 암시 적 체인 , 지연 체인 및 바로 가기 융합을 지원합니다
  • Lodash는 오버로드 분할 _.head, _.last, _.rest, _.initial속으로
    _.take, _.takeRight, _.drop, _.dropRight
    (즉, _.head(array, 2)밑줄이에 _.take(array, 2)Lodash에서)

1
마이그레이션 할 때 이러한 문제를 직접 겪었고 서로간에 (WIP) 교차 문서를 유지 관리하고 있습니다. 다른 사람들에게도 도움이 되길 바랍니다!
luxon

60

John의 답변 외에도 lodash (지금까지는 밑줄로 "나쁜"것으로 간주 됨)를 읽고 성능 테스트를보고 소스 코드를 읽고 블로그 게시물 을 읽습니다. 밑줄보다 훨씬 우수한 것은 다음과 같습니다.

  1. 속도의 일관성 에 관한 것이기 때문에 속도에 관한 것이 아닙니다.

    밑줄의 소스 코드를 살펴보면 처음 몇 줄에서 밑줄이 많은 함수의 기본 구현을 대체하는 것을 볼 수 있습니다. 이상적인 세계에서는 이것이 더 나은 접근 방법 일 것입니다. 이 슬라이드에 제공된 성능 링크 중 일부를 살펴보면 '기본 구현'의 품질이 브라우저마다 크게 다르다는 결론을 내리는 것은 어렵지 않습니다. 브라우저로. Firefox는 일부 기능에서 빠르며 일부 Chrome에서는 우세합니다. (IE가 지배 할 시나리오가있을 것이라고 생각합니다). 브라우저에서 성능 이 더 일관된 코드를 선호하는 것이 좋습니다 .

    앞서 블로그 게시물을 읽은 후 블로그를 믿지 말고 벤치 마크 를 실행하여 스스로 판단하십시오 . 난에 100~150% 빠른 밑줄보다 더 수행하는 lodash보고, 지금 기절하고 간단한 , 원시 등의 기능 Array.every크롬을!

  2. lodash 의 엑스트라 도 매우 유용합니다.

  3. Xananax의 높은 평가 의견은 밑줄 코드에 대한 기여를 제안합니다. GOOD 경쟁 을하는 것이 항상 낫습니다. 혁신을 계속 유지할뿐만 아니라 자신 (또는 라이브러리)을 좋은 모양으로 유지하도록 유도합니다.

lodash 의 차이점 목록은 다음과 같습니다. 밑줄 빌드는 밑줄 프로젝트를 대체하는 대체물입니다.


6
어떤 경우에 "속도 일관성"이 값입니까? FF와 IE에서 100 %의 속도를 가진 메소드가 있고 기본 구현은 IE에서 80 %, FF (또는 다른 방식으로)에서 120 %의 속도를 갖습니다. 그런 다음 FF의 기본 구현과 IE의 자체 구현을 사용하는 것이 좋습니다. 나는 어떤 경우도 상상할 수 없다. IE와 같은 속도를 유지하기 위해 FF를 늦추 자. 모든 브라우저에서 코드 크기와 유지 관리 성 또는 평균 속도 저하가 논쟁의 여지가 있지만 속도의 일관성은?
stofl

2
"일관되게 빠른 속도"를 의미했습니다
kumarharsh

1
크기의 차이는 어떻습니까? 밑줄과 기능이 정확히 동일한 lodash를 사용하여 사용자 정의 빌드를 작성한다고 가정 해 봅시다. 그들 사이에 큰 차이가 있습니까? 다시 구현하면 사이트에 가중치가 추가되는 것 같습니다.
F Lekschas

5
나는 대부분의 경우 수용 가능한 성능을 가지고 있으며 라이브러리를 최신 상태로 유지할 걱정없이 브라우저 업데이트로 향상시킬 수 있기 때문에 브라우저의 기본 구현으로 대체하려고합니다.
orad

3
@KumarHarsh 어쩌면 잘 표현하지 못했을 수도 있습니다. 필자는 항상 자체 구현을 선호하지 않고 가능한 경우 기본적으로 기본 함수를 사용하는 라이브러리를 사용하는 경향이 있음을 의미했습니다.
orad

42

이것은 2014 년이며 몇 년이 너무 늦었습니다. 여전히 내 요점은 다음과 같습니다.

IMHO이 토론은 꽤 많은 비율에서 나왔습니다. 위에서 언급 한 블로그 게시물 인용 :

Underscore, Valentine 및 wu와 같은 대부분의 JavaScript 유틸리티 라이브러리는 "native-first dual approach"에 의존합니다. 이 접근 방식은 기본 구현을 선호하며 기본 동등 기능이 지원되지 않는 경우에만 바닐라 JavaScript로 돌아갑니다. 그러나 jsPerf는 흥미로운 경향을 보여주었습니다. 배열 또는 배열과 같은 컬렉션을 반복하는 가장 효율적인 방법은 간단한 루프를 선택하여 기본 구현을 완전히 피하는 것입니다.

마치 "단순 루프"와 "vanilla Javascript"가 Array 나 Object 메소드 구현보다 더 고유 한 것처럼. 헤이즈 ...

단 하나의 진실의 근원을 갖는 것이 좋을 것입니다. 다른 말을 들었더라도 내 사랑하는 바닐라 신은 없습니다. 죄송 해요. 실제로 유일하게 가정하는 것은 모든 주요 브라우저에서 우수한 성능을 목표로 Javascript 코드를 작성하고 있으며 모두 동일한 구현을 가지고 있다는 것을 알고 있습니다. 부드럽게 대처하는 것은 나쁜 일입니다. 그러나 그것은 당신이 좋아하든 아니든 전제입니다.

어쩌면 트위터 성능이 필요한 대규모 프로젝트를 진행하고 있기 때문에 지금 당 초당 목록에서 850,000 (밑줄)과 2,500,000 (lodash) 반복 의 차이를 실제로 볼 수 있습니다!

나는 한 사람이 아닙니다. 나는 성능 문제를 해결 해야하는 프로젝트를 수행했지만 결코 밑줄이나 Lo-Dash로 해결되거나 발생하지 않았습니다. 그리고 구현과 성능의 실제 차이점 (현재 C ++과 이야기하고 있음)을 반복하지 않으면 반복 가능 (객체 또는 배열, 희소 여부)에 대한 루프를 말할 수 있습니다. 이미 평가 된 벤치 마크 플랫폼의 결과에 근거한 주장 .

Rhino는 단 하나의 업데이트만으로도 단일 "중세 루프 방법이 더 우수하고 영원하며 성능이 우수하지 않다"는 사제가 모든 사실이 FF의 갑작스런 배열 방법은 자신이 생각한 것보다 훨씬 빠릅니다. 런타임 환경을 속여서 런타임 환경을 속일 수는 없습니다! 홍보 할 때 생각하십시오 ...

다용도 벨트

다음에

따라서 관련성을 유지하려면 :

  • 네이티브 ish를 희생하지 않고 편리하다면 Underscore를 사용하십시오.
  • 확장 기능 카탈로그 (딥 카피 등)가 편리하고 즉각적인 성능이 절실히 필요하고 네이티브 API가 나 오자마자 대안을 결정하지 않아도되는 경우 Lo-Dash를 사용하십시오. 의견이있는 해결 방법. 곧 일어날 것입니다. 기간.
  • 세 번째 해결책조차 있습니다. DIY! 환경을 알고 있어야합니다. 불일치에 대해 알아야합니다. ( John-DavidJeremy 의) 코드를 읽으십시오 . 일관성 / 호환성 계층이 실제로 필요한 이유를 설명 할 수없고이를 사용하지 말고 워크 플로를 향상 시키거나 앱의 성능을 향상 시키십시오. 완벽하게 작성할 수있는 간단한 폴리 필로 요구 사항이 충족 될 가능성이 큽니다. 두 라이브러리 모두 약간의 설탕이 들어간 바닐라입니다. 그들은 둘 다 누가 가장 달콤한 파이를 제공하는지 싸우고 있습니다. 그러나 결국 두 가지 모두 물로만 요리한다고 믿습니다. 바닐라 신이 없어서 바닐라 교황도 없어요?

귀하의 요구에 가장 적합한 방법을 선택하십시오. 평소와 같이. 나는 의견이 많은 런타임 치트에 대한 실제 구현에 대한 대체를 언제든지 선호하지만 요즘에는 맛의 문제 인 것 같습니다. http://developer.mozilla.comhttp://caniuse.com 과 같은 양질의 리소스를 사용 하면 괜찮을 것입니다.


Lukas를 게시 해 주셔서 감사합니다. 내장 기능을 더욱 최적화 할 수 있습니까? 나는 그것들이 라이브러리와 비교할 수있는 최적화를하지 못하게하는 표준에 의해 부과 된 제약 사항을 모았지만, 세부 사항이나 이것이 사실인지 여부를 알지 못합니다.
Brian M. Hunt

예를 들어 "99 % 사용 사례를 최적화함으로써 fast.js 메소드는 기본 애플리케이션보다 최대 5 배 더 빠를 수 있습니다." – github.com/codemix/fast.js
Brian M. Hunt

1
안녕 브라이언, 이것이 잘못되어 유감스럽게도, 그 라이브러리가 네이티브 라이브러리보다 훨씬 빠르지 않다는 말은 아닙니다. 성능 절실히 필요에 있다면 지금 그들이 빨리 표준 방법의 구현을 제공하는 것처럼, 당신은 아마 더 나은 오프 LoDash 또는 fast.js 같은 툴킷입니다. 그러나 기본 방법으로 돌아 가지 않는 라이브러리를 사용하기로 선택하면 내장 기능에 대한 향후 성능 최적화를 놓칠 수 있습니다. 브라우저는 결국 진화 할 것입니다.
Lukas Bünger

4
브라우저 "제조업체"는 브라우저 표준을 준수하는 데 어려움을 겪으며 성능이 훨씬 떨어집니다. 기본 구현에서 대부분의 성능 향상은 더 빠른 하드웨어의 결과입니다. "네이티브 구현은 따라 잡을 것"변명은 몇 년 동안 있었다. 년 = 인터넷에서 영원. 경우 기본 구현 이제까지 잡기, 라이브러리는이를 사용하도록 업데이트됩니다. 그것이 오픈 소스의 멋진 점입니다. 앱 개발자가 최신 라이브러리로 업데이트하지 않으면 앱 속도가 갑자기 느려지지 않고 속도가 빨라지지 않습니다.
앤드류 Steitz

2
...하지만 당신이 그들에게 물어 보면 Array.from아마 그들이 무엇을해야할지 모를 것입니다. JS "유틸리티 벨트 (utility belt)"사람들은 너무 일반적인 해결책을 홍보하는 데 너무 많은 관심을 가지고있는 것으로 보인다. 기능이 필요하지 않으므로 브라우저 "제조업체"에 대한 부담이 없습니다. 재미있는 사실 : 4 개의 주요 브라우저 중 2 개는 오픈 소스 프로젝트 ( 1 , 2 )를 기반으로 합니다.
Lukas Bünger

20

나는 여기에 언급 된 대부분의 것에 동의하지만 단지 underscore.js에 찬성하는 주장을 지적하고 싶습니다 : 라이브러리의 크기.

특히 모바일 장치에서 주로 사용하려는 앱이나 웹 사이트를 개발하는 경우 결과 번들의 크기와 부팅 또는 다운로드 시간에 미치는 영향이 중요한 역할을 할 수 있습니다.

비교를 위해,이 크기는 이온 서브를 실행 한 후 소스 맵 탐색기에서 발견 된 크기입니다.

lodash: 523kB
underscore.js: 51.6kb

2020 년 2 월 수정 :

BundlePhobia 를 사용 하여 Lo-DashUnderscore 의 현재 크기를 확인할 수 있습니다.


1
Peter에게 감사합니다. 여기에 주목할만한 가치가 있습니다. gist.github.com/alekseykulikov/5f4a6ca69e7b4ebed726을 포함한 다른 곳에서 더 많은 토론이 있습니다 . (이 답변은 다른 토론 중 일부를 연결하고 관련 비트를 인용하여 향상시킬 수 있습니다.) lodash의 하위 섹션과 트리 쉐이킹 lodash를 선택하면 크기 차이를 줄일 수 있습니다. 🕷
Brian M. Hunt

Thx @BrianM. 귀하의 회신에 대해, lodash의 하위 섹션을 포함시킬 수 있다는 것을 몰랐습니다. 최근 이온 네이티브와 함께, 이오니아는 네이티브 라이브러리에 대해서도 그와 같은 길을갔습니다. 더 많은 앱 크기에 대해 더 많은 관심이 있습니다.
David Dal Busco

1
523kB를 어디서 얻었는지 궁금하십니까? lodash.com24kB 만 압축되어 있다고 말합니다. 다운로드는 단지 74kB입니다
Martian2049

1
내 게시물은 2017 년 4 월에 작성되었습니다. 제가 언급 한 것처럼source-map-explorer after running ionic serve
David Dal Busco

5
년 3 월 2018 년 - lodash.min.js은 72,5 킬로바이트와 밑줄-min.js이 16,4 KB입니다입니다
결합

10

그것이 OP가 무엇인지 확실하지는 않지만 밑줄에서 lodash로 마이그레이션 할 때 명심 해야하는 문제 목록을 검색했기 때문에이 질문에 맞서게되었습니다.

누군가가 그러한 차이점의 전체 목록이있는 기사를 게시 한 경우 정말 감사하겠습니다. 어려운 방법으로 배운 것들, 즉 프로덕션에서 코드가 폭발하게 된 것들로 시작하겠습니다.

  • _.flatten밑줄은 기본적으로 깊고 두 번째 인수로 true를 전달하여 얕게 만듭니다. lodash에서는 기본적으로 얕고 두 번째 인수로 true를 전달하면 깊어집니다! :)
  • _.last밑줄은 원하는 요소 수를 나타내는 두 번째 인수를 허용합니다. 에서 lodash이러한 옵션이 없습니다. 당신은 이것을 모방 할 수 있습니다.slice
  • _.first (같은 문제)
  • _.template밑줄에서 여러 가지 방법으로 사용할 수 있습니다. 그중 하나는 템플릿 문자열과 데이터를 제공하고 HTML돌아 오는 것입니다 (또는 적어도 얼마 전에 작동했던 방식입니다). 에서 lodash당신이 그런 다음 데이터를 공급해야하는 함수를받을 수 있습니다.
  • _(something).map(foo)밑줄로 작동하지만 lodash에서는로 다시 작성해야했습니다 _.map(something,foo). 아마도 그것은 단지 문제 TypeScript였습니다.

4
lodash에서 chaining은 lazy iterator를 통과하고와 같은 엔드 포인트가 필요합니다 _(something).map(foo).value().
Brian M. Hunt

예를 들어 collection.first (5) 당신에게 처음 5 개 요소를 제공하지 않습니다, 오히려 첫 번째 : - 당신은 백본이 라이브러리에 프록시 호출 컬렉션 사용하는 경우이 모두가 당신을 공격 할 수
qbolec

8

http://benmccormick.org/2014/11/12/underscore-vs-lodash/

Ben McCormick의 두 기사를 비교 한 최신 기사 :

  1. Lo-Dash의 API는 Underscore의 상위 집합입니다.

  2. 후드 아래 [Lo-Dash]가 완전히 다시 작성되었습니다.

  3. Lo-Dash는 확실히 Underscore보다 느리지 않습니다.

  4. Lo-Dash는 무엇을 추가 했습니까?

    • 사용성 개선
    • 추가 기능
    • 성능 향상
    • 체이닝을위한 속기 구문
    • 필요한 것만 사용하는 커스텀 빌드
    • 시맨틱 버전 관리 및 100 % 코드 적용

6

나는 방금 나에게 중요한 한 가지 차이점을 발견했다. 밑줄과 호환 _.extend()되지 않는 lodash 버전은 클래스 레벨 정의 특성 또는 메소드를 복사 하지 않습니다 .

CoffeeScript에서 이것을 보여주는 Jasmine 테스트를 만들었습니다.

https://gist.github.com/softcraft-development/1c3964402b099893bd61

다행히도 lodash.underscore.js모든 상황을 복사하는 Underscore의 동작을 유지하므로 상황에 따라 원하는 동작이 이루어졌습니다.


4

lodash밑줄_.mapValues() 과 동일한 것을 가지고 _.mapObject()있습니다.


0

대부분 밑줄은 lodash의 하위 집합입니다. 때로는 현재 밑줄처럼 lodash에는 mapObject와 같은 멋진 작은 기능이 있습니다. 이로 인해 프로젝트 개발에 많은 시간을 절약했습니다.


당시, 우리는 _.mapValues이
crapthings

@crapthings-이 게시물을 작성할 당시 mayValues ​​및 mapKeys에 대해 알고 있었지만 mapObject와 동일하지 않습니다. 어쩌면 하나를 다른 것에 적용하는 경우가 있지만 mapObject는 자체 기능입니다.
rashadb

0

Lodash 가 인수하면서 꽤 유사합니다 ...

둘 다 JavaScript에서 유틸리티의 세계를 차지하는 유틸리티 라이브러리입니다 ...

Lodash 가 더 정기적으로 업데이트되고 있으므로 최신 프로젝트에서 더 많이 사용되는 것 같습니다 ...

또한 Lodash 는 몇 KB로 더 가벼워 보입니다 ...

둘 다 좋은 API와 문서가 있지만 Lodash 하나가 더 낫다고 생각합니다 ...

다음은 배열의 첫 번째 값을 얻는 각 문서의 스크린 샷입니다.

밑줄:

밑줄

lodash : 대쉬

상황이 수시로 업데이트 될 수 있으므로 웹 사이트도 확인하십시오.

대쉬

밑줄

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.