Null vs. Undefined
JavaScript (і, відповідно, TypeScript) має два нижніх типи: null
та undefined
. Вони мають різні значення:
Щось не було ініціалізовано:
undefined
.Щось наразі недоступне:
null
.
Перевірка на наявність обох.
Справа в тому, що вам доведеться мати справу з обома. Цікаво, що в JavaScript з ==
, null
і undefined
рівні тільки один одному:
Рекомендую використовувати == null
для перевірки як undefined
, так і null
. Зазвичай вам не потрібно робити розрізнення між цими двома значеннями.
Ви також можете використовувати
== undefined
, але== null
є більш традиційним/коротшим підходом.
Є одне виключення - це кореневі значення undefined
, про які ми розповімо далі.
Перевірка на undefined на рівні кореня (root level)
Пам'ятаєте, як я говорив, що ви повинні використовувати == null
? Звичайно, пам'ятаєте (адже я це тільки що сказав ^). Але не використовуйте його для рівня кореня. В строгому режимі, якщо ви використовуєте foo
, а foo
є undefined
, ви отримаєте виняток ReferenceError
exception, і весь стек викликів буде розгорнутий.
Ви повинні використовувати строгий режим... і, насправді, компілятор TS автоматично вставить його за вас, якщо ви використовуєте модулі... більше про це буде розказано пізніше в книзі, тому вам не потрібно буде явно це вказувати :)
Тому, щоб перевірити, чи змінна визначена на рівні глобального контексту, ви зазвичай використовуєте typeof
:
Обмежте явне використання undefined
undefined
Оскільки TypeScript дає вам можливість документувати ваші структури окремо від значень, замість використання такого коду, як:
ви повинні використовувати анотацію типу:
Функції зворотного виклику в стилі вузла (Node style callbacks)
Зворотні функції у стилі Node (наприклад, (err, щосьІнше) => { /* щось */ }
) зазвичай викликаються з err
, встановленим в null
, якщо помилок немає. Ви, в будь-якому випадку, зазвичай використовуєте перевірку на істинність для цього:
При створенні власного API, щоб досягти послідовності, можна використовувати null
Насправді, для власних API варто розглянути використання промісів, в цьому випадку вам фактично не потрібно турбуватися про відсутні значення помилок (ви обробляєте їх за допомогою .then
або .catch
).
Не використовуйте undefined
як засіб валідаціі.
undefined
як засіб валідаціі.Нижче наведен приклад цієї помилки:
можна набагато краще написати ось так:
JSON та серіалізація
Стандарт JSON підтримує кодування null
, але не undefined
. При кодуванні JSON-об'єкта з атрибутом null
, атрибут буде включено з його нульовим значенням, тоді як атрибут зі значенням undefined
буде повністю виключено.
Як наслідок, бази даних на основі JSON можуть підтримувати значення null
, але не undefined
значення. Оскільки атрибути зі значенням null
кодуються, ви можете передати намір очистити атрибут, встановивши його значення в null
перед кодуванням і передачею об'єкта до віддаленого сховища.
Встановлення значень атрибутів до невизначених (undefined) може заощадити витрати на зберігання та передачу даних, оскільки імена атрибутів не будуть закодовані. Однак, це може ускладнити семантику очищених значень у порівнянні з відсутніми.
Заключні думки
Команда розробників TypeScript не використовує null
: Рекомендації з кодування TypeScript , і це не викликало жодних проблем. Дуглас Крокфорд вважає, що null
, це погана ідея та слід просто використовувати undefined
.
Однак, в кодових базах у стилі Node.js використовується стандартний підхід використання null
для аргументів помилок, оскільки воно позначає "щось зараз недоступне". Особисто я не зважаю на розрізнення між цими двома значеннями, оскільки багато проектів використовують бібліотеки з різними підходами і просто відкидають обидва значення за допомогою == null
.
Last updated