THẢO LUẬN

thg 6 24, 8:41 SA

Cảm ơn bạn @refacore đã chia sẻ ví dụ này.

Đây là một chia sẻ rất hay và giúp chúng ta hiểu sâu hơn về cách hoạt động của JavaScript. Mình sẽ giải thích lý do tại sao kết quả lại như vậy:

  1. Mặc dù setTimeout() được coi là bất đồng bộ, nhưng JavaScript vẫn thực thi code theo mô hình đơn luồng (single-threaded).

  2. Khi gặp setTimeout(), JavaScript sẽ đẩy callback function vào Web APIs (trong trình duyệt) hoặc libuv (trong Node.js) để xử lý. Đồng thời, một bộ đếm thời gian được khởi động.

  3. Trong khi chờ đợi, JavaScript tiếp tục thực thi các dòng code tiếp theo, trong trường hợp này là vòng lặp for.

  4. Khi bộ đếm thời gian kết thúc (sau 10ms), callback function không được thực thi ngay lập tức. Thay vào đó, nó được đẩy vào Callback Queue (hoặc Task Queue).

  5. Event Loop liên tục kiểm tra xem Call Stack có trống không. Nếu trống, nó sẽ lấy function đầu tiên từ Callback Queue và đưa vào Call Stack để thực thi.

  6. Trong ví dụ của bạn, vòng lặp for chiếm toàn bộ Call Stack trong một thời gian dài (có thể hơn 10ms). Trong suốt thời gian này, Event Loop không thể đưa callback function từ setTimeout() vào Call Stack được.

  7. Chỉ khi vòng lặp for kết thúc, Call Stack trống, Event Loop mới có thể đưa callback function vào để thực thi.

Đó là lý do tại sao bạn luôn thấy dòng log "timeout" ở cuối cùng. Mặc dù setTimeout() là bất đồng bộ, nhưng việc thực thi callback function vẫn phải tuân theo quy tắc của Event Loop và đợi cho đến khi Call Stack trống.

Điều này cho thấy rằng "bất đồng bộ" trong JavaScript không có nghĩa là "chạy song song", mà là "không chặn" (non-blocking) - cho phép code tiếp tục thực thi trong khi chờ đợi các tác vụ khác hoàn thành.

+1
thg 6 24, 8:36 SA

Cảm ơn vì bổ sung nhé @refacore,

Mình xin phép làm rõ thêm ý kiến của bạn:

  1. Bạn nói đúng khi cho rằng sửa đổi prototype sẽ ghi đè (overwrite) các phương thức hiện có. Điều này có thể dẫn đến việc mất đi các chức năng đã được định nghĩa trước đó trên prototype.

  2. Việc ghi đè prototype có thể gây ra lỗi ở những nơi khác trong code nếu có logic phụ thuộc vào các phương thức cũ. Đây là một rủi ro cần lưu ý khi thực hiện việc này.

  3. Cách tiếp cận an toàn hơn, như bạn đề xuất, là kiểm tra xem phương thức đã tồn tại chưa trước khi định nghĩa nó. Ví dụ:

if (typeof MyObject.prototype.myMethod === 'undefined') {
  MyObject.prototype.myMethod = function() {
    // Định nghĩa phương thức mới
  };
} else {
  console.warn('Phương thức myMethod đã tồn tại trên prototype');
}
  1. Nếu phương thức đã tồn tại, ta có thể chọn giữ nguyên phương thức cũ, ghi log cảnh báo, hoặc throw một error tùy thuộc vào yêu cầu cụ thể của ứng dụng.

  2. Một cách tiếp cận khác là sử dụng Object.defineProperty() để thêm hoặc sửa đổi phương thức trên prototype một cách an toàn hơn:

Object.defineProperty(MyObject.prototype, 'myMethod', {
  value: function() {
    // Định nghĩa phương thức mới
  },
  writable: true,
  configurable: true,
  enumerable: false
});
  1. Thực ra trong dự án thì thường sẽ có setup ESLint , việc sử dụng các công cụ linting và kiểm tra tĩnh có thể giúp phát hiện các thay đổi không mong muốn đối với prototype.

Việc kiểm tra trước khi định nghĩa và sử dụng các phương pháp an toàn để thêm hoặc sửa đổi phương thức là những cách tiếp cận tốt để tránh các vấn đề tiềm ẩn trong code.

+1
thg 6 24, 8:19 SA

Cảm ơn bạn @refacore, mình không ngờ lại nhận được nhiều commnet như vậy. Có nhiều comment thật sự thấy bài viết sôi động hẳn. Cảm ơn bạn và trong tương lai nếu có thể mong bạn comment thật nhiều để giúp mình cải thiện chất lương bài viết nhé. (Viết mà ko thấy ai comment thì cũng chán lắm, năm ngoái mình bỏ viết hơn 1 năm giờ mới viết lại đấy kaka 😄).

À quay lại câu hỏi về continuebreak trong vòng lặp.

  1. Về continue:

    continue có một số điểm đặc biệt trong vòng lặp:

    • Nó cho phép bỏ qua phần còn lại của mã trong lần lặp hiện tại và chuyển đến lần lặp tiếp theo.
    • Khi gặp continue, vòng lặp sẽ ngay lập tức chuyển đến bước tiếp theo (ví dụ: tăng biến đếm trong vòng lặp for) mà không thực hiện các câu lệnh còn lại trong thân vòng lặp.
    • continue rất hữu ích khi bạn muốn bỏ qua một số trường hợp cụ thể trong vòng lặp mà không muốn kết thúc toàn bộ vòng lặp.

    Ví dụ:

    for (let i = 0; i < 5; i++) {
      if (i === 2) continue;
      console.log(i);
    }
    // Output: 0, 1, 3, 4
    
  2. Về break:

    break cũng có những đặc điểm riêng:

    • Nó sẽ kết thúc hoàn toàn vòng lặp và chuyển điều khiển chương trình ra khỏi vòng lặp.
    • Khi gặp break, chương trình sẽ thoát khỏi vòng lặp ngay lập tức, bỏ qua tất cả các lần lặp còn lại.
    • break thường được sử dụng khi bạn muốn thoát khỏi vòng lặp khi đã tìm thấy kết quả mong muốn hoặc khi gặp một điều kiện đặc biệt nào đó.

    Ví dụ:

    for (let i = 0; i < 5; i++) {
      if (i === 3) break;
      console.log(i);
    }
    // Output: 0, 1, 2
    

Điểm khác biệt chính giữa continuebreak là:

  • continue chỉ bỏ qua lần lặp hiện tại và tiếp tục với lần lặp tiếp theo.
  • break kết thúc toàn bộ vòng lặp và thoát ra ngoài.

Cả hai đều là công cụ mạnh mẽ để kiểm soát luồng thực thi trong vòng lặp, giúp code của bạn linh hoạt và hiệu quả hơn.

Hy vọng những giải thích này giúp các bạn đọc hiểu rõ hơn về continuebreak. Nếu bạn có bất kỳ câu hỏi nào khác, đừng ngần ngại hỏi nhé!

0

😋😋😋😋

+1
thg 6 24, 8:11 SA

Cảm ơn bạn @refacore đã đọc bài viết và đưa ra câu hỏi rất hay! Đây là một điểm thú vị trong JavaScript mà mình rất vui được giải thích.

Bạn hoàn toàn đúng về kết quả của đoạn code. Hãy cùng phân tích từng block nhé:

Block 1:

{
  var message = 'test';
  console.log(window.message); // test
  console.log(this.message); // test
}

Trong block này, var được sử dụng để khai báo biến message. Biến được khai báo bằng var có phạm vi function hoặc global, không bị giới hạn bởi block. Do đó, nó được thêm vào đối tượng global (window trong trình duyệt) và có thể truy cập thông qua window.message hoặc this.message (khi this trỏ đến global object).

Block 2:

{
  const message = 'test';
  console.log(window.message); // undefined
  console.log(this.message); // undefined
}

Trong block này, const được sử dụng để khai báo biến message. Khác với var, biến được khai báo bằng const (cũng như let) có phạm vi block. Điều này có nghĩa là biến message chỉ tồn tại trong block đó và không được thêm vào đối tượng global. Vì vậy, cả window.messagethis.message đều trả về undefined.

Đây là một ví dụ tuyệt vời về sự khác biệt giữa varconst/let trong JavaScript. Nó cho thấy tại sao việc sử dụng constlet có thể giúp tránh ô nhiễm phạm vi global và tạo ra code an toàn hơn.

Cảm ơn bạn một lần nữa vì câu hỏi rất hay này. Những tương tác như thế này thực sự là động lực để mình tiếp tục viết nhiều bài hơn nữa trong tương lai. Nếu bạn có bất kỳ câu hỏi nào khác, đừng ngần ngại hỏi nhé!

+1

cảm ơn nhiều nhé

+1
thg 6 24, 2:10 SA

5 thử đoạn code này:

setTimeout(() => {
console.log('------------------ timeout -------------------');
}, 10);
for(let i = 0; i < 1000000; i++){
	if (i % 10 === 0) {
    	console.log(i);
    }
}

sẽ luôn thấy dòng log timeout ở cuối, tức là nó phải đợi vòng lặp for xong mới thực thi. Nếu là bất đồng bộ thì tại sao?

+1
thg 6 24, 2:02 SA

4 có thể check bằng Object.keys(a).

+1
thg 6 24, 2:00 SA

sửa prototype thì nó overwrite, tức là không có xung đột, mà có thể break code ở đâu đó do logic đã cập nhật lại. Cách thường làm là ta check xem func đấy đã có chưa trước khi khai báo nó. Nếu có rồi thì dùng lại hoặc throw hoặc log error.

+1
thg 6 24, 1:57 SA

continue trong vòng lặp có gì đặc biệt? break thì sao ^^!

+1
thg 6 24, 1:54 SA

Sửa lại đoạn code đầu tiên thành thế này:

{
  var message = 'test';
  console.log(window.message); // test
  console.log(this.message); // test
}

{
  const message = 'test';
  console.log(window.message); // undefined
  console.log(this.message); // undefined
}

block 1 không đổi. kết quả block 2 đều là undefined. Em giải thích xem?

+1
thg 6 23, 5:09 CH

Airflow không chỉ dùng để lập lịch chạy hàm trong database, mà còn dùng trong dự án bình thường. Dễ thấy nhất trong các dự án to, có ~1000 task như Spotify thì họ sẽ dùng Airflow hoặc 1 trình quản lý khác như Luigi mà họ tạo ra để quản lý các task, visualize các luồng tasks, nói đơn giản là 1 cái pipeline ý.

0
Avatar
đã bình luận cho bài viết
thg 6 23, 2:55 CH

struct là kiểu giá trị. vì thế trong struct ko dùng string mà dùng mảng char, do string là kiểu tham chiếu không có độ dài cố định, không thể để trong struct. cũng vì thế struct có size cố định. là kiểu giá trị nên struct được clone ra khi truyền vào function. thay đổi struct ở local scope không ảnh hưởng outer scope.

0
thg 6 23, 1:48 CH

Cảm ơn a đã góp ý e mới học nên nhiều cái chưa rõ ạ

0

À bạn có thể cho mình xin dockerfile các image trong bài viêtd ko? Do mình test rewrite-target của ingress, cần điều chỉnh thử root folder của frontend. Nếu được mình cảm ơn nhé

0

sao cứ viết kiểu nửa Tây nửa ta đọc khó hiểu thật ấy

0

cho mình ké link này nha: https://cookkitmart.com/

0
Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí