Câu hỏi Sự khác biệt giữa lodash và gạch dưới


Tại sao một người nào đó thích hoặc là lodash.js hoặc là underscore.js thư viện tiện ích khác?

Lodash có vẻ như là một sự thay thế drop-in cho gạch dưới, sau này đã được lâu hơn.

Tôi nghĩ cả hai đều rực rỡ, nhưng tôi không biết đủ về cách họ làm việc để so sánh với giáo dục, và tôi muốn biết thêm về sự khác biệt.


1405
2017-12-09 17:08


gốc


Bạn có thể muốn xem xét một số màn hình-phôi về lodash được liên kết với trang github của nó. Cá nhân tôi đã sử dụng underscore.js, nhưng nhiều hơn bởi vì đó là những gì tôi bắt đầu với và khi bạn nói nó được xung quanh lâu hơn. - Jack
lodash và underscore dưới hợp nhất thread hiện nay - zangw
FYI: Miếng đệm đầu của gạch lót & Lodash - user2875289


Các câu trả lời:


Tôi đã tạo Lo-Dash để cung cấp hỗ trợ lặp lại môi trường chéo nhất quán hơn cho mảng, chuỗi, đối tượng và arguments các đối tượng1. Từ đó trở thành phần mở rộng của Underscore, cung cấp hành vi API nhất quán hơn, nhiều hơn Tính năng, đặc điểm (như hỗ trợ AMD, bản sao sâu và hợp nhất sâu), kỹ lưỡng hơn tài liệu và kiểm tra đơn vị (các thử nghiệm chạy trong Node, Ringo, Rhino, Narwhal, PhantomJS và trình duyệt), hiệu suất tổng thể tốt hơn và tối ưu hóa cho mảng lớn / lặp lại đối tượng và linh hoạt hơn với các bản dựng tùy chỉnh và các tiện ích biên dịch mẫu trước.

Bởi vì Lo-Dash được cập nhật thường xuyên hơn Underscore, một lodash underscore xây dựng được cung cấp để đảm bảo tính tương thích với phiên bản mới nhất của Underscore.

Tại một thời điểm, tôi thậm chí còn được đẩy truy cập để nhấn mạnh, một phần vì Lo-Dash chịu trách nhiệm nâng cao hơn 30 vấn đề; các bản sửa lỗi đích, tính năng mới và lợi ích hoàn hảo trong Underscore v1.4.x +.

Ngoài ra có ít nhất 3 nồi hơi Backbone bao gồm Lo-Dash theo mặc định và Lo-Dash hiện được đề cập trong chính thức của Backbone tài liệu.

Hãy xem bài đăng của Kit Cambridge, Nói "Xin chào" với Lo-Dash, để biết chi tiết hơn về sự khác biệt giữa Lo-Dash và Gạch dưới.

Chú thích:

  1. Dấu gạch dưới có sự hỗ trợ không nhất quán đối với mảng, chuỗi, đối tượng và arguments các đối tượng. Trong các trình duyệt mới hơn, phương thức Underscore bỏ qua lỗ trong mảng, "Đối tượng" phương pháp lặp arguments các đối tượng, các chuỗi được xử lý như mảng, và các phương thức lặp lại các hàm một cách chính xác (bỏ qua thuộc tính "nguyên mẫu") và các đối tượng của chúng (lặp các thuộc tính được tô bóng như "toString" và "valueOf"), trong khi các trình duyệt cũ thì không. Ngoài ra, các phương pháp Underscore như _.clone bảo vệ lỗ hổng trong mảng, trong khi những người khác thích _.flatten không.

1780
2017-12-16 05:34



@Brian - Trong khi phát triển Lo-Dash tôi vẫn tiếp tục đặt câu hỏi "Điều gì có thể có ai đó chỉ ra, trong Lo-Dash, như một tiêu cực so với Underscore?" và sau đó giải quyết chúng. Đây là lý do tại sao tôi đã tăng cường tài liệu, thêm các bản dựng tùy chỉnh và làm cho nguồn dễ đọc hơn. - John-David Dalton
Tôi yêu lo-dash và tôi đang sử dụng nó, vì vậy xin đừng nghĩ rằng tôi đang bashing, nhưng tại sao không góp phần nhấn mạnh thay vì tạo ra một thư viện mới? - Xananax
@Xananax - kiểm tra chuỗi nhận xét: github.com/jashkenas/underscore/commit/… - điều này có thể trả lời câu hỏi đó. - Robert Grant
Đã có bất kỳ nỗ lực để hợp nhất lodash trở lại vào gạch dưới? - streetlight
Oh chính trị. Tôi chỉ muốn một thư viện. - ooolala


Lo-Dash được lấy cảm hứng từ dấu gạch dưới, nhưng ngày nay là giải pháp vượt trội. Bạn có thể làm cho các bản dựng tùy chỉnh, có một hiệu suất cao hơn, hỗ trợ AMD và có tính năng bổ sung tuyệt vời. Kiểm tra điều này Lo-Dash vs Điểm chuẩn Underscore trên jsperf và .. cái này bài đăng tuyệt vời về lo-dash:

Một trong những tính năng hữu ích nhất khi bạn làm việc với các bộ sưu tập, là cú pháp viết tắt:

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 }]

(được lấy từ tài liệu lodash)


165
2017-12-13 21:51



Liên kết đến blog của Kit Cambridge rất thông tin. - Brian M. Hunt
Tôi nghĩ rằng điều này là sai (ví dụ pluck). Kể từ lần cập nhật cuối cùng 1.8.3, bạn có thể sử dụng cách nhổ giống như lodash. dù sao cho các phiên bản trước, tôi không nghĩ rằng gạch dưới sẽ lộ ra một hàm giống với một bản đồ (ví dụ gạch dưới của bạn có vẻ giống như một hàm bản đồ) - alexserver
filter tính năng gạch dưới từ năm 2012 github.com/jashkenas/underscore/issues/648 (tên của nó là where) - Muhammad Hewedy


Ngoài câu trả lời của John, và đọc lên trên lodash (mà tôi đã từng coi là "tôi-quá" để gạch dưới), và nhìn thấy các bài kiểm tra hiệu suất, đọc mã nguồn, và bài đăng trên blog, vài điểm khiến cho lodash vượt trội hơn nhiều so với gạch dưới là:

  1. Nó không phải về tốc độ, vì nó là về Tính nhất quán tốc độ (?)

    Nếu bạn nhìn vào mã nguồn của gạch dưới, bạn sẽ thấy trong một vài dòng đầu tiên nhấn mạnh sự quay trở lại về việc triển khai thực hiện của nhiều hàm. Mặc dù trong một thế giới lý tưởng, đây sẽ là một cách tiếp cận tốt hơn, nếu bạn nhìn vào một số liên kết tuyệt vời được đưa ra trong các trang trình bày này, thật không khó để rút ra kết luận rằng chất lượng của những 'triển khai bản địa' này thay đổi rất nhiều trình duyệt đến trình duyệt. Firefox khá nhanh trong một số chức năng, và trong một số Chrome thống trị. (Tôi tưởng tượng sẽ có một số kịch bản mà IE sẽ thống trị quá). Tôi tin rằng tốt hơn nên chọn một mã có hiệu suất nhất quán hơn trên các trình duyệt.

    Do đọc bài đăng trên blog trước đó, và thay vì tin tưởng nó vì lợi ích của nó, thẩm phán cho chính mình bằng cách chạy điểm chuẩn. Tôi choáng váng ngay bây giờ, thấy một lodash thực hiện nhanh hơn 100-150% so với gạch dưới đơn giản, tự nhiên các chức năng như Array.every trong Chrome!

  2. Các tính năng bổ sung trong lodash cũng khá hữu ích.

  3. Đối với bình luận rất cao của Xananax cho thấy sự đóng góp vào mã của gạch dưới: Nó luôn luôn tốt hơn để có TỐT cạnh tranh, không chỉ nó tiếp tục đổi mới, mà còn thúc đẩy bạn giữ cho mình (hoặc thư viện của bạn) trong hình dạng tốt.

Đây là danh sách sự khác biệt giữa lodash, và underscore-build của nó là một thay thế drop-in cho các dự án gạch dưới của bạn.


57
2017-08-18 14:18



Trong trường hợp nào là "tính nhất quán của tốc độ" một giá trị? Hãy nói rằng, tôi có một phương pháp có tốc độ 100% trong FF và trong IE và việc thực hiện bản địa sẽ có tốc độ 80% trong IE và 120% trong FF (hoặc vòng khác). Sau đó, tôi sẽ nói nó sẽ là tốt để sử dụng việc thực hiện bản địa trong FF và thực hiện riêng trong IE. Tôi không thể tưởng tượng bất kỳ trường hợp nào, nơi tôi sẽ nói: Hãy làm chậm FF chỉ vì lý do có tốc độ tương tự như trong IE. Kích thước của mã và bảo trì hoặc chậm lại trung bình trong tất cả các trình duyệt sẽ là đối số, nhưng sự nhất quán của tốc độ? - stofl
Ý tôi là, "tốc độ liên tục nhanh hơn" - kumar_harsh
Một chiếc xe đi 20kmph trong một ngày sẽ không được sử dụng nhiều :) - kumar_harsh
Tôi nghiêng về dự phòng gốc của trình duyệt đơn giản bởi vì trong hầu hết các trường hợp, nó có hiệu suất chấp nhận được và có thể cải thiện với bản cập nhật trình duyệt mà không phải lo lắng cập nhật thư viện. - orad
@ KumarHarsh Có lẽ tôi đã không cụm từ nó tốt. Tôi có nghĩa là tôi nghiêng để sử dụng một thư viện mà nội bộ sử dụng các chức năng bản địa nếu có sẵn, thay vì luôn luôn thích thực hiện riêng của mình. - orad


Nếu như tôi, bạn đang mong đợi danh sách các khác biệt về mức sử dụng giữa gạch dưới và lodash, có hướng dẫn di chuyển từ gạch dưới sang lodash.

Đây là trạng thái hiện tại của nó cho hậu thế:

  • Dấu gạch dưới _.compose là Lodash _.flowRight
  • Dấu gạch dưới _.contains là Lodash _.includes
  • Dấu gạch dưới _.findWhere là Lodash _.find
  • Dấu gạch dưới _.invoke là Lodash _.invokeMap
  • Dấu gạch dưới _.mapObject là Lodash _.mapValues
  • Dấu gạch dưới _.pluck là Lodash _.map
  • Dấu gạch dưới _.where là Lodash _.filter
  • Dấu gạch dưới _.any là Lodash _.some
  • Dấu gạch dưới _.all là Lodash _.every
  • Dấu gạch dưới _.each không cho phép thoát bằng cách quay lại false
  • Dấu gạch dưới _.flatten sâu theo mặc định trong khi Lodash cạn
  • Dấu gạch dưới _.isFinite không phù hợp với Number.isFinite
       (ví dụ. _.isFinite('1') trả về true trong dấu gạch dưới nhưng false trong   Lodash)
  • Dấu gạch dưới _.matches viết tắt không hỗ trợ so sánh sâu
       (ví dụ. _.filter(objects, { 'a': { 'b': 'c' } }))
  • Dấu gạch dưới ≥ 1.7 & Lodash đã thay đổi _.template cú pháp để
    _.template(string, option)(data)
  • Lodash _.uniq không chấp nhận một iteratee chức năng như Underscore's. Sử dụng Lodash _.uniqBy
  • Lodash _.first và ._last không chấp nhận một n đối số như Underscore. Sử dụng slice
  • Lodash _.memoize cache là Map như đối tượng
  • Hỗ trợ Lodash -sự xâu chuỗi, lười biếng chuỗi và phím tắt   dung hợp
  • Lodash chia quá tải _.head, _.last, _.rest, & _.initial ra vào
      _.take, _.takeRight, _.drop, &    _.dropRight
       (I E. _.head(array, 2) trong Underscore là    _.take(array, 2) ở Lodash)

55
2017-07-21 09:35



Tôi đã tự mình gặp phải những vấn đề này khi di chuyển và tôi đang duy trì (WIP) tài liệu chéo đi giữa cái này và cái kia. Hy vọng nó cũng hữu ích cho người khác! - luxon


Đây là năm 2014 và một vài năm quá muộn. Tôi vẫn nghĩ rằng quan điểm của tôi là:

IMHO cuộc thảo luận này đã bị thổi bay tỷ lệ khá một chút. Trích dẫn những điều đã nói ở trên bài viết trên blog:

Hầu hết các thư viện tiện ích JavaScript, chẳng hạn như Gạch dưới, Valentine và   wu, dựa vào “phương pháp kép gốc đầu tiên”. Cách tiếp cận này thích   triển khai gốc, chỉ quay lại vani JavaScript nếu   tương đương bản địa không được hỗ trợ. Nhưng jsPerf tiết lộ một điều thú vị   xu hướng: cách hiệu quả nhất để lặp qua một mảng hoặc mảng   bộ sưu tập là để tránh hoàn toàn việc triển khai gốc, chọn tham gia   các vòng lặp đơn giản thay thế.

Như thể "các vòng lặp đơn giản" và "vani vani" có bản địa hơn so với việc triển khai phương pháp Array hoặc Object. Jeez ...

Nó chắc chắn sẽ là tốt đẹp để có một nguồn duy nhất của sự thật, nhưng không có. Ngay cả khi bạn đã được nói khác, không có Vanilla Chúa, thân yêu của tôi. Tôi xin lôi. Giả định duy nhất thực sự nắm giữ là tất cả chúng ta đều viết mã Javascript nhằm thực hiện tốt trong tất cả các trình duyệt chính, biết rằng tất cả chúng đều có các triển khai khác nhau của cùng một thứ. Đó là một bitch để đối phó với, để đặt nó nhẹ nhàng. Nhưng đó là tiền đề, cho dù bạn có thích hay không.

Có lẽ bạn đang làm việc trên các dự án quy mô lớn cần hiệu suất twitter để bạn thực sự thấy sự khác biệt giữa 850.000 (dấu gạch dưới) so với 2.500.000 (lodash) lần lặp qua danh sách mỗi giây ngay bây giờ!

Tôi cho một người không. Ý tôi là, tôi đã làm việc với các dự án mà tôi phải giải quyết các vấn đề về hiệu suất, nhưng chúng chưa bao giờ được giải quyết hoặc gây ra bởi cả Underscore lẫn Lo-Dash. Và trừ khi tôi nhận được sự khác biệt thực sự trong việc thực hiện và hiệu suất (chúng tôi đang nói C + + ngay bây giờ) cho phép nói một vòng lặp trên một iterable (đối tượng hoặc mảng, thưa thớt hay không!), Tôi thay vì không bị làm phiền với bất kỳ tuyên bố dựa trên kết quả của nền tảng chuẩn đã được ý kiến.

Nó chỉ cần một bản cập nhật cho phép Rhino thiết lập phương pháp Array trên lửa theo kiểu thời trang mà không phải là một "phương pháp vòng lặp thời trung cổ thực hiện tốt hơn và mãi mãi và không biết". một phương pháp mảng đột ngột trong FF nhanh hơn nhiều so với não bộ của anh ta / cô ấy. Người đàn ông, bạn chỉ có thể không gian lận môi trường thời gian chạy của bạn bằng cách gian lận môi trường thời gian chạy của bạn! Hãy suy nghĩ về điều đó khi quảng cáo ...

vành đai tiện ích của bạn

... lần tới.

Vì vậy, để giữ cho nó có liên quan:

  • Sử dụng dấu gạch dưới nếu bạn vào tiện lợi mà không phải hy sinh bản địa.
  • Sử dụng Lo-Dash nếu bạn thích sự thuận tiện và thích danh mục tính năng mở rộng của nó (bản sao sâu, v.v.) và nếu bạn đang có nhu cầu tuyệt đối về hiệu suất tức thì và quan trọng nhất là đừng bận tâm giải quyết thay thế ngay sau khi outshine của API gốc các workaurounds có ý kiến. Mà sẽ xảy ra sớm. Giai đoạn.
  • Thậm chí còn có một giải pháp thứ ba. DIY! Biết môi trường của bạn. Biết về mâu thuẫn. Đọc của họ (John-David'cát Jeremy's) mã. Không sử dụng điều này hoặc điều đó mà không thể giải thích lý do tại sao một lớp nhất quán / tương thích thực sự cần thiết và tăng cường luồng công việc của bạn hoặc cải thiện hiệu suất của ứng dụng của bạn. Rất có thể yêu cầu của bạn được thỏa mãn với một polyfill đơn giản mà bạn hoàn toàn có thể tự viết. Cả hai thư viện chỉ là vani đơn giản với một ít đường. Cả hai đều chỉ chiến đấu với những người đang phục vụ chiếc bánh ngọt ngào nhất. Nhưng hãy tin tôi, cuối cùng cả hai chỉ nấu với nước. Không có Vanilla God nên không thể không có vị Vanilla, đúng không?

Chọn cách tiếp cận phù hợp với nhu cầu của bạn nhiều nhất. Như thường lệ. Tôi muốn fallbacks trên thực tế thực hiện trên gian lận thời gian chạy theo ý kiến ​​bất cứ lúc nào nhưng ngay cả đó dường như là một vấn đề của hương vị ngày nay. Gắn bó với các nguồn lực chất lượng như http://developer.mozilla.com và http://caniuse.com và bạn sẽ ổn thôi.


43
2017-09-11 21:27



Cảm ơn bạn đã đăng Lukas. Các bản dựng sẵn có thể được tối ưu hóa thêm không? Tôi thu thập họ có những ràng buộc áp đặt bởi các tiêu chuẩn ngăn cản họ có tối ưu hóa so sánh với các thư viện, nhưng tôi không biết chi tiết một cách trực tiếp hoặc cho dù điều này là đúng hay không. - Brian M. Hunt
ví dụ. "Bằng cách tối ưu hóa cho trường hợp sử dụng 99%, các phương thức fast.js có thể lên tới 5x nhanh hơn so với tương đương nguyên gốc của chúng." - - github.com/codemix/fast.js - Brian M. Hunt
Xin chào Brian, tôi xin lỗi nếu điều này gây hiểu lầm, tôi không có ý nói rằng các thư viện đó không nhanh hơn nhiều so với các thư từ tương đương của chúng. Nếu bạn đang có nhu cầu tuyệt vọng về hiệu suất ngay bây giờ, bạn có thể tốt hơn với một bộ công cụ như LoDash hoặc fast.js khi chúng cung cấp việc triển khai nhanh hơn các phương thức chuẩn. Nhưng nếu bạn chọn sử dụng một thư viện không rơi vào các phương thức gốc, bạn có thể bỏ lỡ bất kỳ sự tối ưu hóa hiệu suất nào trong tương lai trên các trình cài sẵn. Các trình duyệt sẽ phát triển cuối cùng. - Lukas Bünger
Trình duyệt "nhà sản xuất" gặp khó khăn trong việc tuân thủ các tiêu chuẩn trình duyệt của họ, ít hoạt động hơn nhiều. Hầu hết các lợi ích về hiệu năng trong việc triển khai bản địa là kết quả của phần cứng nhanh hơn. Các "triển khai bản địa sẽ bắt kịp" lý do đã được xung quanh trong nhiều năm. Số năm = vĩnh cửu trên internet. NẾU các triển khai gốc bao giờ bắt kịp, các thư viện sẽ được cập nhật để sử dụng chúng. Đó là điều thú vị về nguồn mở. Nếu một người phát triển ứng dụng không cập nhật lên thư viện mới nhất, ứng dụng của họ sẽ không đột ngột bị chậm lại, nó sẽ không tăng tốc. - Andrew Steitz
... nhưng nếu bạn hỏi họ về Array.from có lẽ họ sẽ không biết nó phải làm gì. Các "vành đai tiện ích" JS dường như quá quan tâm đến việc thúc đẩy cách giải quyết oh-so-genial của họ mà họ có xu hướng quên rằng bằng cách làm như vậy, họ đang thực sự pha loãng quá trình tiêu chuẩn hóa. Không cần các tính năng không gây áp lực lên trình duyệt "nhà sản xuất". Thực tế thú vị: 2 trong 4 trình duyệt chính dựa trên các dự án nguồn mở (1, 2). - Lukas Bünger


Tôi đồng ý với hầu hết mọi thứ nói ở đây nhưng tôi chỉ muốn chỉ ra một đối số ủng hộ underscore.js: kích thước của thư viện.

Đặc biệt trong trường hợp bạn đang phát triển ứng dụng hoặc trang web có ý định sử dụng chủ yếu trên thiết bị di động, kích thước của gói kết quả và hiệu ứng vào thời gian khởi động hoặc tải xuống có thể có vai trò quan trọng.

Để so sánh, các kích thước này là những gì tôi nhận thấy với nguồn-map-explorer sau khi chạy ionic phục vụ:

lodash: 523kB
underscore.js: 51.6kb

14
2018-04-26 14:20



Cảm ơn Peter, đây là một điểm đáng lưu ý ở đây. Có nhiều thảo luận ở nơi khác, bao gồm: gist.github.com/alekseykulikov/5f4a6ca69e7b4ebed726 . (Câu trả lời này có thể được cải thiện bằng cách liên kết một số các cuộc thảo luận khác và trích dẫn các bit liên quan) Sự khác biệt về kích thước có thể được giảm bằng cách chọn các phần của lodash, cộng với lodash cây lắc. - Brian M. Hunt
Thx @ BrianM.Hunt cho trả lời của bạn, không biết rằng nó có thể bao gồm các phần của lodash, gonna có một cái nhìn. Gần đây với ionic-native, Ionic đã có một con đường như vậy cho libs bản địa của họ, tốt để lưu ý rằng càng có nhiều lo ngại về kích thước ứng dụng - David Dal Busco
tôi tự hỏi bạn đã nhận được 523kB ở đâu? lodash.com nói rằng nó chỉ nén 24kB. tải xuống chỉ 74kB - Martian2049
bài đăng của tôi được đưa ra vào tháng 4 năm 2017. như tôi đã nói trong nhận xét của mình, source-map-explorer after running ionic serve - David Dal Busco
Vào tháng 3 năm 2018 - lodash.min.js là 72,5 kB và underscore-min.js là 16,4 kB - Combine


Không chắc chắn nếu đó là những gì OP có nghĩa là, nhưng tôi đi qua câu hỏi này bởi vì tôi đã tìm kiếm một danh sách các vấn đề tôi phải ghi nhớ khi di chuyển từ gạch dưới để lodash.

Tôi thực sự sẽ đánh giá cao nếu ai đó đăng một bài viết với một danh sách đầy đủ các sự khác biệt như vậy. Hãy để tôi bắt đầu với những điều tôi đã học được một cách khó khăn (có nghĩa là, những thứ làm cho mã của tôi phát nổ trên sản xuất: /):

  • _.flatten trong dấu gạch dưới là sâu theo mặc định và bạn phải vượt qua đúng như đối số thứ hai để làm cho nó cạn. Trong lodash nó là nông theo mặc định và đi đúng như đối số thứ hai sẽ làm cho nó sâu! :)
  • _.last trong gạch dưới chấp nhận một đối số thứ hai cho biết có bao nhiêu phần tử bạn muốn. Trong lodash không có tùy chọn như vậy. Bạn có thể mô phỏng điều này với .slice
  • _.first (cùng một vấn đề)
  • _.template trong gạch dưới có thể được sử dụng theo nhiều cách, một trong số đó là cung cấp chuỗi mẫu và dữ liệu và nhận được HTML trở lại (hoặc ít nhất đó là cách nó làm việc một thời gian trước đây). Trong lodash bạn nhận được một chức năng mà bạn nên ăn với dữ liệu.
  • _(something).map(foo) hoạt động dưới dấu gạch dưới, nhưng trong lodash tôi phải viết lại nó _.map(something,foo). Có lẽ đó chỉ là một TypeScript-vấn đề

9
2018-03-25 12:16



Trong lodash, chuỗi đi qua một iterator lười biếng, và đòi hỏi và endpoint như _(something).map(foo).value(). - Brian M. Hunt
Điều này tất cả có thể đánh bạn nếu bạn sử dụng Backbone Collection mà proxy gọi đến các thư viện này - ví dụ collection.first (5) sẽ không cung cấp cho bạn 5 phần tử đầu tiên, nhưng thay vào đó là phần tử đầu tiên :) - qbolec


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

Bài viết mới nhất so sánh hai của Ben McCormick:

  1. API của Lo-Dash là một siêu của Underscore.

  2. Dưới mui xe [Lo-Dash] đã được viết lại hoàn toàn.

  3. Lo-Dash chắc chắn không chậm hơn Underscore.

  4. Lo-Dash đã thêm gì?

    • Cải thiện khả năng sử dụng
    • Chức năng bổ sung
    • Hiệu suất đạt được
    • Viết tắt cú pháp cho chuỗi
    • Bản dựng tùy chỉnh để chỉ sử dụng những gì bạn cần
    • Phiên bản ngữ nghĩa và phạm vi mã 100%

8
2017-12-07 12:19





Tôi chỉ tìm thấy một sự khác biệt mà kết thúc là quan trọng đối với tôi. Phiên bản lodash không tương thích với underscore _.extend() làm không phải sao chép các thuộc tính hoặc phương thức được xác định cấp lớp.

Tôi đã tạo một bài kiểm tra Jasmine trong CoffeeScript để minh họa điều này:

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

May mắn thay, lodash.underscore.js bảo tồn hành vi sao chép tất cả mọi thứ của Underscore, cho tình huống của tôi là hành vi mong muốn.


5
2017-12-12 16:56