Những lỗi phổ biến khi làm việc với Javascript
Mọi developer đều thi thoảng mắc lỗi khi viết ứng dụng. Đây là một phần cơ bản của quá trình phát triển. Trong đó, có một số lỗi mà sẽ bị mắc phải thường xuyên hơn các lỗi khác. Sẽ thật tốt nếu ta nhận biết được chúng và phòng tránh trước khi mắc phải. Một khi làm được điều đó thì chúng ta sẽ ...
Mọi developer đều thi thoảng mắc lỗi khi viết ứng dụng. Đây là một phần cơ bản của quá trình phát triển. Trong đó, có một số lỗi mà sẽ bị mắc phải thường xuyên hơn các lỗi khác. Sẽ thật tốt nếu ta nhận biết được chúng và phòng tránh trước khi mắc phải. Một khi làm được điều đó thì chúng ta sẽ phát triển ứng dụng một cách dễ dàng hơn rất nhiều. Dưới đây là 10 lỗi phổ biến mà các Javascript developer thường gặp phải:
Tham chiếu sai đến this
Các kỹ thuật coding và các mẫu thiết kế trong Javascript ngày càng tinh vi, và cùng với đó là sự tăng lên của self-referencing scopes trong callback và closure, một nguồn gốc của sự nhầm lẫn về this/that.
Xem xét đoạn code dưới đây:
1 2 3 4 5 6 7 8 | Game.prototype.restart=function(){ this.clearLocalStorage(); this.timer=setTimeout(function(){ this.clearBoard(); // what is "this"? },0); }; |
Thực thi đoạn code trên sẽ dẫn đến một lỗi:
1 2 3 | UncaughtTypeError:undefinedisnotafunction |
Tại sao?
Ta cần xem xét context. Nguyên nhân của lỗi trên là bởi vì, khi bạn gọi hàm setTimeout() thì thực sự ở đây bạn gọi đến hàm window.setTimeout(). Kết quả là hàm bạn truyền vào setTimeout() được định nghĩa trong context của window object. this ở đây là window object và nó không có hàm clearBoard()
Giải pháp truyền thống là lưu tham chiếu đến this trong một biến và có thể sử dụng bởi closure.
1 2 3 4 5 6 7 8 9 | Game.prototype.restart=function(){ this.clearLocalStorage(); varself=this; // save reference to 'this', while it's still this! this.timer=setTimeout(function(){ self.clearBoard(); // oh OK, I do know who 'self' is! },0); }; |
Một cách khác hiện đại hơn, bạn có thể sử dụng bind() để truyền một tham chiếu đúng:
1 2 3 4 5 6 7 8 9 10 | Game.prototype.restart=function(){ this.clearLocalStorage(); this.timer=setTimeout(this.reset.bind(this),0); // bind to 'this' }; Game.prototype.reset=function(){ this.clearBoard(); // ahhh, back in the context of the right 'this'! }; |
Nghĩ rằng có block-level scope
Một nhầm lẫn của các developer là giả định rằng Javascript tạo ra một scope mới cho mỗi code block. Mặc dù điều này là đúng trong rất nhiều các ngôn ngữ lập trình khác, tuy nhiên nó không đúng với Javascript.
Ví dụ, xem xét đoạn code sau:
1 2 3 4 5 6 | for(vari=0;i<10;i++){ /* ... */ } console.log(i); // what will this output? |
Nếu bạn cho rằng console.log() sẽ in ra undefined hay ném ra một lỗi thì bạn đã sai. Tin được hay không, nó sẽ in ra output là 10. Tại sao?
Trong hầu hết các ngôn ngữ khác, đoạn code trên sẽ lỗi vì biến i chỉ có thể dùng trong block của vòng lặp for. Tuy nhiên, trong Javascript, biến i vẫn trong scope kể cả sau khi vòng lặp for kết thúc và giữ lại giá trị của nó sau khi thoát khỏi vòng lặp. Hành vi này được gọi là variable hoisting.
Điều đáng chú ý là block scope được hỗ trợ trong Javascript thông qua từ khóa let.
Rò rỉ bộ nhớ
Rò rỉ bộ nhớ là vấn đề hầu như không thể tránh khỏi trong Javascript nếu bạn không có ý thức phòng tránh chúng. Có rất nhiều cách có thể làm rò rỉ bộ nhớ, vì vậy ta sẽ chỉ nhấn mạnh một số trường hợp phổ biến.
Ví dụ 1: Tham chiếu lỏng lẻo đến các object không còn tồn tại.
Xem xét đoạn code sau:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | vartheThing=null; varreplaceThing=function(){ varpriorThing=theThing; // hold on to the prior thing varunused=function(){ // 'unused' is the only place where 'priorThing' is referenced, // but 'unused' never gets invoked if(priorThing){ console.log("hi"); } }; theThing={ longStr:newArray(1000000).join('*'), // create a 1MB object someMethod:function(){ console.log(someMessage); } }; }; setInterval(replaceThing,1000); // invoke `replaceThing' once every second |
Nếu bạn thực thi đoạn code trên và theo dõi bộ nhớ được sử dụng, bạn sẽ thấy một lượng bộ nhớ lớn bị rò rỉ, 1MB mỗi giây. Điều đó trông như ta đang bị rò rỉ longStr mỗi khi replaceThing được gọi. Nhưng tại sao?
Hãy kiểm tra kỹ hơn.
Mỗi theThing object chứa 1MB longStr object. Mỗi giây, khi ta gọi replaceThing, nó giữ một tham chiếu đến theThing object trước trong priorThing. Nhưng có lẽ đây không phải là vấn đề, vì mỗi lần chạy qua, tham chiếu trước đó đến priorThing sẽ bị hủy (khi priorThing được gán lại thông qua priorThing = theThing;). Hơn thế nữa, nó chỉ được tham chiếu đến trong thân hàm replaceThing và trong hàm unused không bao giờ được sử dụng.
Vậy tại sao lại có sự rò rỉ bộ nhớ ở đây?
Để hiểu điều gì xảy ra, chúng ta cần hiểu rõ hơn về cách mọi thứ hoạt động trong Javascript. Nếu cả hai hàm được định nghĩa trong replaceThing thực sự sử dụng priorThing, thì điều quan trọng là cả hai đều nhận cùng một object, kể cả nếu priorThing được gán đi gán lại, cả hai hàm vẫn sử dụng cùng mội môi trường lexical. Nhưng ngay khi một biến được sử dụng bởi bất kỳ một closure nào, nó kết thúc trong môi trường lexical được chia sẻ bởi tất cả closure trong scope đó. Và nó dẫn đến rò rỉ bộ nhớ.
Ví dụ 2: Tham chiếu vòng tròn
1 2 3 4 5 6 7 | functionaddClickHandler(element){ element.click=functiononClick(e){ alert("Clicked the "+element.nodeName) } } |
Ở đây, onClick có một closure giữ tham chiếu đến element (thông qua element.nodeName). Bằng cách gán onClick cho element.click, tham chiếu vòng tròn được tạo ra: element -> onClick -> element -> onClick -> element…
Kể cả nếu element được xóa khỏi DOM, sự tham chiếu như trên vẫn sẽ ngăn chặn không cho element và onClick được dọn dẹp, và do đó, dẫn đến rò rỉ bộ nhớ.
Phòng tránh rò rỉ bộ nhớ: Những gì bạn cần biết
Việc quản lý bộ nhớ trong Javascript phụ thuộc chủ yếu vào khả năng truy cập object.
Các object sau được cho là có thể truy cập và được coi là root:
- Object được tham chiếu từ bất kỳ đâu trong call stack hiện tại (tất cả các biến cục bộ, các tham số trong hàm đang được gọi, các biến trong closure scope)
- Tất cả các biến toàn cục.
Object được giữ trong bộ nhớ ít nhất là khi chúng còn có thể truy cập được từ bất kỳ một root nào thông qua tham chiếu hay một chuỗi các tham chiếu.
Nhầm lẫn khi so sánh bằng
Một trong những tiện lợi của Javascript là tự động ép kiểu cho giá trị boolean khi tham chiếu đến một boolean context. Nhưng đôi khi việc tiện lợi này lại gây nhầm lẫn. Ví dụ một vài điều sau đây thường gây khó chịu cho các Javascipt developer:
1 2 3 4 5 6 7 8 9 10 11 | // All of these evaluate to 'true'! console.log(false=='0'); console.log(null==undefined); console.log("
"==0); console.log('==0); // And these do too! if({})// ... if([])// ... |
Như ví dụ mô tả trên, các quy tắc ép kiểu đôi khi không rõ ràng, do đó, tốt hơn hết nên sử dụng === thay vì ==.
Thêm một điều cần lưu ý là việc so sánh mọi thứ với NaN sẽ luôn trả về false. Do đó, để xác định một giá trị là NaN cần sử dụng một hàm toàn cục có sẵn isNaN():
1 2 3 4 5 | console.log(NaN==NaN); // false console.log(NaN===NaN); // false console.log(isNaN(NaN)); // true |
Việc thao tác DOM không hiệu quả
Javascript cung cấp việc thao tác các phần tử DOM một cách khá dễ dàng, tuy nhiên không có điều gì để thúc đẩy để làm việc đó một cách hiệu quả.
Một ví dụ phổ biến là thêm một loạt các phần tử DOM cùng một lúc. Việc thêm một phần tử DOM là một hoạt động khá tiêu tốn chi phí, do đó, việc thêm đồng loạt các phần tử DOM là không hiệu quả và có thể không hoạt động đúng.
Một thay thế hiệu quả khi cần thêm nhiều phần tử DOM là sử dụng document fragments. Nó sẽ cải thiện cả hiệu quả lẫn hiệu suất.
Ví dụ:
1 2 3 4 5 6 7 8 9 10 | vardiv=document.getElementsByTagName("my_div"); varfragment=document.createDocumentFragment(); for(vare=0;e<elems.length;e++){ // elems previously set to list of elements fragment.appendChild(elems[e]); } div.appendChild(fragment.cloneNode(true)); |
Sử dụng sai định nghĩa hàm trong vòng lặp for
Theo dõi đoạn code sau:
1 2 3 4 5 6 7 8 9 | varelements=document.getElementsByTagName('input'); varn=elements.length; // assume we have 10 elements for this example for(vari=0;i<n;i++){ elements[i].onclick=function(){ console.log("This is element #"+i); }; } |
Ở đoạn code trên, nếu ta có 10 phần tử input, khi click vào bất kỳ phần tử nào thì ta đều nhận được thông báo “This is element #10”. Đó là do khi onclick được kích hoạt trên bất kỳ phần tử nào thì vòng lặp for khi đó đã hoàn thành và giá trị của i là 10. Sau đây là cách để sửa đoạn code trên để đạt được hành vi mong muốn:
1 2 3 4 5 6 7 8 9 10 11 12 | varelements=document.getElementsByTagName('input'); varn=elements.length; // assume we have 10 elements for this example varmakeHandler=function(num){ // outer function returnfunction(){ // inner function console.log("This is element #"+num); }; }; for(vari=0;i<n;i++){ elements[i].onclick=makeHandler(i+1); } |
Với cách sửa như trên, makeHandler được thực thi ngay lập tức mỗi lần chạy qua vòng lặp, nhận tham số i + 1 và bind nó vào scope của biến num. Việc này sẽ đảm bảo mỗi sự kiện onclick sẽ nhận được giá trị i phù hợp thông qua biến num này.
Vận dụng không triệt để kế thừa prototype
Một số lượng lớn các Javascript developer không hiểu đầy đủ và tận dụng không triệt để các tính năng của kế thừa prototype.
Ví dụ:
1 2 3 4 5 6 7 8 9 | BaseObject=function(name){ if(typeofname!=="undefined"){ this.name=name; }else{ this.name='default' } }; |
Nhìn có vẻ khá đơn giản. Nếu truyền vào name thì sẽ sử dụng nó, nếu không sẽ gán name là “default”.
1 2 3 4 5 6 7 | varfirstObj=newBaseObject(); varsecondObj=newBaseObject('unique'); console.log(firstObj.name); // -> Results in 'default' console.log(secondObj.name);// -> Results in 'unique' |
Nhưng nếu ta làm như sau:
1 2 3 | deletesecondObj.name; |
thì sẽ nhận được:
1 2 3 | console.log(secondObj.name);// -> Results in 'undefined' |
Nhưng sẽ tốt hơn nếu nó là giá trị mặc định “default”. Điều này có thể đạt được bằng cách tận dụng kế thừa prototype:
