JavaScript について知らないかもしれない 6 つのこと

ルイス・シアンシ作✏️

それで、あなたは JavaScript 開発者ですか?うれしいですね — このコードは何を返すと思いますか?そう、これはひっかけ質問です:

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

C#、Java など、他のほとんどすべての言語では、JavaScript Expert を使用してオブジェクトを返します。 JavaScript でも同じ結果が返されると考えるのも無理はありません。

しかし、ユーモアを交えて、これを開発コンソールにポップし、関数を実行してください。ほとんど信じられないことに、未定義が返されます。

物事が計画通りに進まないとき

ソフトウェア開発者として働くということは、アプリがうまく機能するかどうかにかかわらず、アプリがどのように機能するかについて責任を負うことを意味します。その際の主な制約は、使用するツールです。使用しているものを理解していれば、ソフトウェアを設計する際に適切な選択ができるでしょう。

JavaScript は、非常に多くの新しいソフトウェア開発者が選択する言語であるため、独特です。モバイルアプリを作成したいですか? React Native と JavaScript を使用するだけです。デスクトップアプリ？ React Native と JavaScript。どこかで実行するクラウド機能? Node.js、そしてご想像のとおり、JavaScript。

しかし、JavaScript は長い間存在してきたため、かなりの欠点や欠点があります。その中には、ちょっと面白いものから、自分のコードがまったく機能しない、なぜなのかわからない重大なものまで、さまざまなものがあります。

そして、たとえ Internet Explorer 6 が全盛期だった時代に私たちが生きていたとしても、Web の多くを壊すことになるので、これらの設計上の決定事項の一部を修正しようとしても手遅れになるでしょう。もしそうなら、私たちが今日試してみたらどうなるか想像してみてください。 ??

では、JavaScript が期待どおりに動作しないのはなぜでしょうか?見てみましょう。

自動セミコロン挿入 (ASI)

最初にリストした例は JavaScript インタプリタによって受け入れられますが、期待した結果は得られません。その理由は、自動セミコロン挿入によるものです。

C# などの一部の言語では、各行をセミコロンで終了することが独断的です。 JavaScript では行の終わりを示すためにセミコロンも使用しますが、セミコロンは実際にはオプションです。オプションとは、JavaScript が一連の複雑なルールを適用して、セミコロンがそこに配置されるべきかどうかを判断することを意味します。

最初の例では、開始括弧が戻りと同じ行にないため、ASI がそこに開始括弧をポップします。したがって、JavaScript に関する限り、コードは実際には次のようになります:

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

これを回避する方法は、開始括弧をリターンと同じ行に置くことです。また、セミコロンは JavaScript では技術的にはオプションですが、その概念を扱うことは長期的には害を及ぼすことになります。

面接があり、JS を書かなければならず、「ただしセミコロンはオプションだ」という理由に基づいてセミコロンなしで書くと、紙をシャッフルしたり、くすくすと笑ったりすることが多くなるでしょう。それは絶対にやめてください。

非シーケンシャルキーを含む配列

単純な配列があると想像してみましょう:

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

配列を使ってポップ、プッシュ、追加など好きなことを何でもできることはわかっています。しかし、JavaScript では他の言語と同様に、インデックスによって配列要素にアクセスできることもわかっています。

しかし、JavaScript の珍しい点は、配列がまだそのインデックスに達していない場合でも、配列インデックスによって要素を 設定 することもできることです。

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

良い質問があります。要素を 3 つだけ設定した場合、配列の長さはどれくらいになりますか?おそらく直感的にはわかりませんが、それは 101 です。一方で、配列項目 2 から 99 が未定義であることは合理的ですが、他方では、100 ではなく 3 つのオブジェクトのみを設定しています。

なぜそれが重要なのでしょうか?
たぶん、あなたは頭から目が飛び出てこう言うかもしれません。それはJavaScriptではなく、あなたを奇妙にさせるのです。」

その立場は理解できます。しかし、入れ子になった for ループで何かを実行しているときに、間違ったイテレータを選択したり、二段計算を行ったりしたと想像してください。

「なぜ期待された結果、期待された結果、未定義の期待された結果が得られるのか」という思考プロセスは、ある時点で狂気の沙汰に変わり、やがて涙を流すことになるでしょう。あなたがやろうとしていることに対応するために配列が魔法のように拡張されるとは、ほとんど知りませんでした。

唯一の問題は、あなたが間違ったことをしようとしていたということです。

C# などの別の言語と比較すると (特に理由はありませんが)、配列は固定長です。配列を作成するときは、長さを定義する必要があります。 List などの他の動的コレクション オブジェクトの場合でも、未定義のインデックスに代入することはできません。したがって、ネストされたループが以前に割り当てられていないインデックスに書き込もうとすると、プログラムはスローします。

例外は良くありませんが、おそらくそれが正しいことです。つまり、スイスチーズの配列を作成するつもりだったのでしょうか?誰かがそんなことをするつもりですか？そうでなければいいのですが。  

開発者がスイス出身であれば、それはスイス チーズ アレイだけです。そうでなければ、それはただのひどいプログラミングです。

プリミティブへのプロパティの追加は無視されます

JavaScript ではプロトタイプに新しい関数を割り当てることができることはわかっています。したがって、文字列や配列に ✨特別な力✨を与えることができます。もちろん、そうすることはひどい行為です。文字列プロトタイプが他のプロトタイプとは異なる動作をすることになるため、すでに多くの開発者にとって計り知れない心の痛みを引き起こしています。

それで、たとえば次のようにすることができます:

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

そして、文字列オブジェクトを作成できます:

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

そして、それは false を返します。

文字列がどのように機能するかを工場で定義された実装に、いつでもランダムに関数を組み込むことができるのは素晴らしいことです。

確かに、これらの善良な人々は皆、腰を折って TC39 仕様で JavaScript を定義するのに何万時間も費やしましたが、だからといって、必要に応じてランダムな関数を実行することを思いとどまらないでください。

その特定の種類の痛みに満足できない場合は、必要に応じて複雑なオブジェクトに新しい関数をランダムに割り当てることもできます。これにより、コードが非常に特殊な形でナンセンスになり、自分と神だけが理解できるようになります。 :

このようにオブジェクトを構成するのは当然ひどい考えですが、私たちはこの裏切り行為に積極的に取り組んでおり、JavaScript は私たちのリクエストに従うことを義務付けています。 testObject は、そこに投入した新しい関数を引き受けます。

しかし、オブジェクトプリミティブでは、驚くべき方法で善意が尽きてしまいます。

インタプリタは、文字列プリミティブに関数を割り当てようとする試みを認識します。関数をエコーバックして私たちに返すこともあります。しかし、それを呼び出そうとすると、「testString.onlyFalse は関数ではありません」という TypeError が発生します。これが不可能な場合は、通常、これが関数呼び出しではなく代入時にスローされることが予想されます。

なぜそれが重要なのでしょうか?
良くも悪くも、JavaScript は非常に柔軟で動的な言語です。この柔軟性により、他の言語では不可能な機能を作成できます。何かがうまくいかなかった場合は、例外が発生することを期待する必要があります。 JavaScript はこの厄介なコマンドを受け取り、「まあ、まあまあ」という感じで、それを忘れてしまいますが、この根本的な期待は変わります。

型強制

他の強く型指定された言語では、データを保存する前に、保存するデータの型を定義する必要があります。 JavaScript にはこれと同じ種類の制限がなく、オブジェクトをその定義された型から喜んで遠ざけ、うまく連携させようとします。

一方では、変数をそれぞれの型に行き来するキャストから解放されます。とても便利です:
ブール値でも同じです:

このアプローチは完全に正気であり、「足し算」として知られるタブーな儀式に参加するまでは有効です。 「1」と「1」を足すとどうなるでしょうか?型強制はどのように行われるのでしょうか?

パーティーにブールを持ち込むと、狂気の楽しさが倍増します:

ああ、それは bool が何らかの形で内部的に数値であるからでしょうか?
いいえ。それはブール値です。 JavaScript は、正方形の厄介なエッジを削り取って、その丸い穴に収まるようにしています。その理由は次のとおりです。

なぜそれが重要なのでしょうか?
数値を加算するなどの基本的なことを行っている場合、結果が異なると奇妙なバグが発生する可能性があります。タイプ間をザッピングすると意図した結果が得られない可能性があるため、比較するときは 3 つの等号 (===) を使用するように注意してください。

機能の引き上げ

私たちが今日使用している言語では、「関数ホイスティング」と呼ばれる重要な側面があります。本質的に、これは、ファイル内の好きな場所に関数を記述でき、関数が宣言される前に関数を呼び出すことができることを意味します。

function returnSomething()
{
  return
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

コードを機能させるために手動でコードを並べ替える必要がないので便利です。

しかし、関数を記述する方法は複数あります。この例では、これを行うために関数宣言を使用しました。関数式を使用することもできます:

function returnSomething()
{
  return ; // <-- semicolon inserted by ASI, remainder of function not evaluated.
    {
      name: 'JavaScript Expert'
      contactMethod: 'Shine batsign at sky'
    }
}

なぜそれが重要なのでしょうか?
どちらの場合でも関数の宣言に大きな違いはありませんが、間違った関数を選択すると、関数を宣言した後に呼び出さない限り、関数を呼び出すことができなくなります。

Null はオブジェクトです

他の言語では、オブジェクトのプロパティを割り当てることも、null にすることもできます。 null は、プロパティが割り当てられていないことを示します。私たちの頭の中で、そこにオブジェクトがあるか、それがヌルであるかを同一視するのは簡単です。必要に応じて、プロパティを null に戻すこともできます。

JavaScript は null と未定義を持っているため、この状況を複雑にしています。でもそれはどれも同じですよね？手にボールを持っているか、持っていないかのどちらかです。

当然のことながら、すべてが同じというわけではありません。 JavaScript では、null は値が意図的に欠落していることを示し、unknown は値が暗黙的に欠落していることを示します。つまり、それが意図的であろうと、明示的であろうと、空に書かれたものであろうと、事実は価値がない = 価値がないということですよね?

繰り返しになりますが、残念ながら、この方程式は成り立ちません。

それでは、未定義の種類とは何でしょうか?

それで、null の型は何ですか?

?それはオブジェクトです。したがって、JavaScript では、複合オブジェクトの型と null は同じであり、どちらもオブジェクトです:

なぜそれが重要なのでしょうか?
JavaScript には堅牢な型チェック システムが組み込まれておらず、選択できるプリミティブ型は少数しかありません。そのため、typeof を使用して変数の内容を理解するのは困難になる可能性があります。変数が有効なオブジェクトを保持している場合、オブジェクトを取得します。ただし、null の場合でもオブジェクトを取得します。 null 参照がオブジェクトであると考えるのは直感に反します。

結論

JavaScript が言語として今日非常に人気があることに疑問の余地はありません。時間が経ち、npm などの他のエコシステムが膨大な数のパッケージをホストし続けるにつれて、JavaScript の人気は高まり続けるでしょう。

しかし、終わったことは終わった。 null がオブジェクトであることや、JavaScript が適切と思われる場所にセミコロンをポップすることがどれほど奇妙であっても、これらのシステムが非推奨になったり、変更されたり、削除されたりすることはおそらくありません。余談ですが、自動セミコロンインジェクションが一夜にしてオフになった場合、おそらく CrowdStrike アップデートよりも大規模な世界規模の停止が発生するでしょう。

確かに、これらの 1 つを変更すると、ウェブに大混乱が生じるでしょう。実際に元の問題に戻って解決するよりも、これらの言語特有の癖を開発者に認識させるほうが安全で、おそらくより実用的です。

それでは、適切な選択を行ってください。セミコロンを使用することを忘れないでください。

---

LogRocket: コンテキストを理解することで JavaScript エラーをより簡単にデバッグします

コードのデバッグは常に面倒な作業です。しかし、間違いを理解すればするほど、修正が容易になります。

LogRocket を使用すると、これらのエラーを新しい独自の方法で理解できます。当社のフロントエンド監視ソリューションは、JavaScript フロントエンドに対するユーザーの関与を追跡し、エラーを引き起こしたユーザーの行動を正確に確認できるようにします。

LogRocket は、コンソール ログ、ページの読み込み時間、スタック トレース、ヘッダー本体を含む遅いネットワーク リクエスト/レスポンス、ブラウザーのメタデータ、カスタム ログを記録します。 JavaScript コードの影響を理解するのがこれまでになく簡単になります!

無料でお試しください。

以上がJavaScript について知らないかもしれない 6 つのことの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。