thắc mắc Khó hiểu về khối if trong ngôn ngữ javascript

riêng phần hoisting của arrow function và closure tôi học 2 lần, research đủ loại doc mà gặp lại vẫn ko nhận ra, cay vl, chắc do tiếp thu chậm

Sent from Xiaomi MI 8 Lite via nextVOZ
như đọc cái thread này mới thấy cái trước giờ mình nghĩ là đúng hóa ra không phải. ví dụ ép kiểu ==, ===. Trước cứ nghĩ == không cần so sánh kiểu dữ liêu, chỉ cần giá trị bằng. === vừa so sánh giá trị, vừa so sánh kiểu. Nhưng vừa đọc lại You dont know Js thì thấy === thực chất là strict mode không cho ép kiểu thôi.
 
Hình như tôi nhớ có thớt javascript gì đó trong f rồi thì phải.

Tốt nhất hỏi đáp về ngôn ngữ kiểu này nên quy về 1 2pic của ngôn ngữ, chứ hỏi newbie kiểu này loãng quá.
 
Hình như tôi nhớ có thớt javascript gì đó trong f rồi thì phải.

Tốt nhất hỏi đáp về ngôn ngữ kiểu này nên quy về 1 2pic của ngôn ngữ, chứ hỏi newbie kiểu này loãng quá.
bên cái web overflow nó cho linh tinh đủ kiểu nhưng mà nó có cái tag, bấm vào cái tag nó chỉ ra các nội dung của tag đó thui, forum voz thì chưa có cái ý :pudency::sad:
 
2 biến nếu đều trỏ tới kiểu dữ liệu object thì sẽ compare theo reference. tức là kiếm tra xem 2 biến đó có trỏ tới cùng một vùng nhớ không. nên trong trường hợp hai object khác nhau thì không bao giờ bằng nhau, dù có dùng == hay ===. 2 biến kiểu object chỉ bằng nhau khi và chỉ khi chúng trỏ tới cùng một vùng nhớ.
so sánh 2 object mà dùng kiểu chuyển sang string thì có 2 vấn đề. có những property không thể convert sang được (function, non-enumerable https://developer.mozilla.org/en-US...eference/Global_Objects/Object/defineProperty). hoặc khi dính vào cấu trúc không thể serialize được (ví dụ: tree vòng tròn chẳng hạn).
trong YDKJS ô tác giả toàn gợi ý nên học và tận dụng sức mạnh của prototype, nhưng mà giờ còn ai dùng cái này không fen, khi đã có từ khóa class và typescript:sad:
 
trong YDKJS ô tác giả toàn gợi ý nên học và tận dụng sức mạnh của prototype, nhưng mà giờ còn ai dùng cái này không fen, khi đã có từ khóa class và typescript:sad:
JS vẫn là prototype-based, keyword class chỉ là cách viết khác cho developer dễ dùng hơn thôi. bản thân nó vẫn là prototype. xem code được generated ra sẽ thấy.
 
javascript không định nghĩa trong việc so sánh 2 object với nhau, thím phải tự định nghĩa trong từng trường hợp cụ thể của mình.
Nếu muốn so sánh 2 object bằng nhau theo nghĩa đen, thì chuyển thành dạng string
Mã:
const cat = {
    weight: 100
}

if(JSON.stringify(cat) == JSON.stringify({ weight: 100 })) // true
Cái này ko ổn, vì 2 object giống nhau nhưng key order có thể sẽ khác nhau.
JavaScript:
JSON.stringify({a: 1, b: 2}) == JSON.stringify({b: 2, a: 1}) // false

@linh vật: lodash có hàm isEqual: https://github.com/lodash/lodash/blob/2f79053d7bc7c9c9561a30dda202b3dcd2b72b90/eqDeep.js#L29

Nói chung việc compare 2 objects trong js là việc ko đơn giản, tạm thời bỏ qua thì tốt hơn cho người mới bắt đầu.
 
đây là ví dụ cho object cat, còn nếu cứ lúc nào so sánh 2 object nào cũng dùng lodash, thì phải đánh đổi hiệu năng, trong khi lodash lại viết cho giải pháp toàn diện, khi dùng cho trường hợp cụ thể thì lại không cần đến mức đó, dùng lodash giống như đóng đinh bằng búa tạ vậy

tôi thấy nhiều anh nói lodash chậm này nọ, vậy chậm là vì sao anh giải thích luôn với. 1 thư viện phổ biến và lâu đời bậc nhất lại thua dev tự viết tôi thấy hơi lạ.
 
tôi thấy nhiều anh nói lodash chậm này nọ, vậy chậm là vì sao anh giải thích luôn với. 1 thư viện phổ biến và lâu đời bậc nhất lại thua dev tự viết tôi thấy hơi lạ.
JSON stringify nếu object lớn thì tổng thể có khi chậm hơn lodash.isEqual nhiều. vì lodash nó sẽ dừng lại khi thấy sai khác. còn thằng kia nó phải serialize toàn bộ.
show cái benchmark đây cho mn tham khảo: https://www.measurethat.net/Benchma...-equality-comparison-for#latest_results_block
1621787807161.png
 
tôi thấy nhiều anh nói lodash chậm này nọ, vậy chậm là vì sao anh giải thích luôn với. 1 thư viện phổ biến và lâu đời bậc nhất lại thua dev tự viết tôi thấy hơi lạ.
fen có thể tự google mà nhỉ, tại sao phải hỏi lại trên voz?

https://blog.bitsrc.io/you-dont-nee...rted-loving-javascript-functions-3f45791fa6cd
https://codeburst.io/why-you-shouldnt-use-lodash-anymore-and-use-pure-javascript-instead-c397df51a66

lưu ý bật với proxy, mạng vn chặn medium
 

đây là native vs lodash? Tôi hỏi là dev tự làm so với lodash. Cụ thể trong cái ví dụ isEqual, vì sao lodash chậm hơn và cách nhanh hơn là thế nào.

comment thêm về link medium, native chắc chắn nhanh hơn, nhưng con số trong bài viết thật sự gây nghi ngờ. Lodash find array 3 phần tử mất 140ms mà có người tin và coi nó như sự thật hiển nhiên? Tôi sẽ confirm nhưng trước mắt là ko tin rồi đó.
1621788922710.png
 
đây là native vs lodash? Tôi hỏi là dev tự làm so với lodash. Cụ thể trong cái ví dụ isEqual, vì sao lodash chậm hơn và cách nhanh hơn là thế nào.
câu ông voz lit nói rồi còn gì, tùy trường hợp, có thể ko cần phức tạp đến độ phải xài isEqual
hB8nmx5.png


comment thêm về link medium, native chắc chắn nhanh hơn, nhưng con số trong bài viết thật sự gây nghi ngờ. Lodash find array 3 phần tử mất 140ms mà có người tin và coi nó như sự thật hiển nhiên? Tôi sẽ confirm nhưng trước mắt là ko tin rồi đó.
Ok, cứ cho cái medium là fake số liệu đi, nhưng lodash vẫn chậm hơn native phải ko
BdgiW7R.png
 
đây là native vs lodash? Tôi hỏi là dev tự làm so với lodash. Cụ thể trong cái ví dụ isEqual, vì sao lodash chậm hơn và cách nhanh hơn là thế nào.

comment thêm về link medium, native chắc chắn nhanh hơn, nhưng con số trong bài viết thật sự gây nghi ngờ. Lodash find array 3 phần tử mất 140ms mà có người tin và coi nó như sự thật hiển nhiên? Tôi sẽ confirm nhưng trước mắt là ko tin rồi đó.
Xem tệp đính kèm 562004
cái trong bài viết đo bằng new Date không chuẩn lắm đâu. đo bằng performance chuẩn hơn
1621789495735.png
 

Thống kê chủ đề

Ngày tạo
Chief Technology Officer,
Người trả lời cuối
Hàn Quá Nhanh,
Trả lời
70
Lượt xem
5.179
Quay lại
Lên đầu trang