twitter@js_bankfacebook@jsbankrss@jsbank






Hướng dẫn kiểm tra biến trong JavaScript Tổng quát, bài viết này sẽ hướng dẫn bạn chi tiết cách thức kiểm tra các kiểu dữ liệu JavaScript. Bài viết bao gồm đầy đủ mã nguồn JavaScript ví dụ và chỉ dẫn chi tiết, bạn vui lòng vào trang chính để xem thêm.

Các bài viết liên quan khác:
- Lập trình JavaScript hướng đối tượng dành cho người mới
- 10 thủ thuật JavaScript đơn giản dành cho người mới học
- 10 eBook tốt nhất người mới học JavaScript nên đọc
- Các vấn đề JavaScript cơ bản cho người mới học


Nhãn: kiểm tra biến, biến trong JavaScript, kiểu dữ liệu JavaScript

Tạo video bằng AI chỉ với giọng nói hoặc văn bản



Ứng dụng video AI MIỄN PHÍ hàng đầu của bạn! Tự động hóa video AI đầu tiên của bạn. Tạo Video Chuyên Nghiệp Của Bạn Trong 5 Phút Bằng AI Không Cần Thiết Bị Hoặc Kỹ Năng Chỉnh Sửa Video. Sản xuất video dễ dàng dành cho nhà tiếp thị nội dung.
Ứng dụng video AI KHÔNG GIỚI HẠN miễn phí trong tay bạn

foo versus window.foo and this.foo

The secret to our solution lies in how JavaScript handles undefined variables versus undefined properties. Here�s a quick reminder on the difference between the two:

// variable foo
var foo;

// property bar (and object variable foo)
var foo = {};  // create an empty object to add bar too
foo.bar = "";

The difference between these makes all the difference whether a fatal error occurs:

foo;  // ReferenceError: foo is not defined

var foo = {};
foo.bar;  // undefined
foo.blah; // undefined

We can randomly invent and check any property of foo we want, and the code will keep chugging along:

var foo = {};
foo.something = "hello";

if(foo.bar) { // undefined, interpreted as false (same as !!foo.bar)
  // never runs
}

if(foo.something) {
  foo.something;  // "hello"
}

Now comes the magic. If you know anything about JavaScript running in the browser, you know that all global variables are part of the window object. This means foo and window.foo are equivalent:

var foo;

foo === window.foo;  // true

// "this" is another bag of worms, but note this anyway
this.foo === window.foo;

So technically our variable foo is a property of the window object. So we should be able to check for any arbitrary variable in the window scope now!

window.foo;  // undefined (not a fatal error!)

// even though we're checking for the same thing, we get a fatal error�
foo;  // ReferenceError: foo is not defined

Practical uses

Now as long as we have a global entry point for our code, we can write our code in such a way that it won�t ever give us a fatal error if our variables aren�t yet defined:

if(window.foo && foo.bar) {
  foo.bar();
}

Of course nothing happens, because we haven�t defined foo. But why doesn�t foo.bar give us a fatal error? Because the first test, window.foo failed out. It would be useless processing for the JavaScript engine to also evaluate the second statement, because the end result will still be the same (false && true results in false, false && false results in false). So it doesn�t get so far as foo.bar.

And now the code will work properly when we hook up our code to our foo global namespace:

var foo = {
  bar: function() {
    alert("hello world");
  }
}

if(window.foo && foo.bar) {
  foo.bar();  // "hello world"
}

Shorthand

It�s becoming common to see an abbreviation for the above code. Check out the following two methods, which accomplish the same thing:

// Method 1
if(window.foo && foo.bar) {
  foo.bar();  // "hello world"
}

// Method 2
window.foo && foo.bar && (foo.bar());

Don�t get too scared.. these blocks of code are equivalent. Method 2 is shorter, but it simply goes something like this: if window.foo isn�t set, stop evaluating this line (just as above in the if statement). Otherwise, if foo.bar exists then execute the code in parentheses, which gives us an alert (�hello world�);

Just a word of caution about using Method 2: it�s obviously less clear what�s going on here. Your own cleverness might actually result in unnecessary confusion, especially of other people work in the same code base and they�re at different levels of understanding. In these cases we should first strive to be clear, and then only clever if it�s not at the expense of being clear.

It�s also likely that a code minifier would take care of this cleverness for us at build time, giving us the best of both worlds.


Google Safe Browsing McAfee SiteAdvisor Norton SafeWeb Dr.Web