00:04
8月23日、火曜日ですね。 地獄は朝9時を回りました。
今日の東京は、ちょっと朝曇っている感じですけどもね。
はい、おはようございます。 眠いのきーつこくわはなです。
では、本日の朝活を始めていきたいかなと思います。
どうで、ですね。今日は、タイトルにありますけども、 昨日も若干読みましたね。冒頭だけ読んだんですけど、
5 JavaScript Concepts to Make You an Excellent Frontend Developer っていう記事を読んでいこうかなと思います。
タイトルにある通りですね。
フロントエンドのデベロッパー、 素晴らしいデベロッパーになるためには、
必要ではないけど、この人が考える 5つのJavaScriptのコンセプトというところです。
この記事を読んでいこうと思います。
昨日はその、はい、見て、冒頭の1つ目ですね。 5つのうちの1つ目のコンセプトについて、
ちょっと触れてみたって感じですね。
1つ目は、ちなみに言うと、継承についてですね。
Let's Talk About Infinitarsということで、 継承についてお話ししていきましたと。
継承と言っても主に、合計6個の継承があって、 それぞれについてメリディ名の話をしてたんですけど、
僕の中では、あんまりJavaScriptでは継承を そんな意識しなくてもいいんじゃないかというか、
意識むしろあんまりしないほうがいいんじゃないか というようなものもあったりはしましたね。
いろんな継承もありますけどね。
プロトタイプ継承とか、 プロトタイプのチェーンの継承であったりとか、
コンストラクター継承であったりとか、 いろんなものがありますけど、
一旦今の、 今現代でのモダンなフロントエンドの開発では、
いわゆるSPAを作ることがまだまだ主流で、 SPAフレーマークとしてリアクトド、ビュート、
今スベルトとかが出てきてるんですかね。
あとソリッドジェースとかが、 その辺ですね。
いわゆる仮想ドームを使わないフレーマークも 結構出てきたりしてて、
その辺の議論も出てますけど、 そういうやつを使うんですが、
それらを使えば、基本的にはJavaScriptの継承ってところは あんまり意識しないことが多いよなっていう。
プロトタイプっていう名前すら、 皆さんも滅多に聞かなくなっただろうっていう印象があるので、
知っとって損はないですし、そういう裏付けがあって、
JavaScriptは動いてるっていうところなんですけど、 その辺は知識だけで言ったほうがいいのかなって思いますし、
最近の初学者の方にJavaScriptを教えるときに、 いわゆるディスは教えますけど、
ディスとかいろんなものは教えるんですけど、
プロトタイプっていうものをどう伝えなくても 良くないかなって思ったりもちょっとしていました。
いました?いました。
そんなところですね。
というのが一応第1章の話でした。
一応この記事もまた、 今日読む記事もTwitterで共有しますので、
後ほど中身見てもらって、皆さんの方でも いろいろ考えていただくといいのかなと思いました。
じゃあ今日は第2章、2章というか 2つ目のコンセプトからいきたいなと思います。
ケイジさんとケンジさんですね。 おはようございます。ご参加いただきありがとうございます。
では行きましょう。2つ目のコンセプトですね。
03:00
2つ目はディスキーワードですね。
ディスというキーワードについて 簡単に理解していきましょうと。
ディスっていうのはいわゆるコンテキストの 話だと思いますけど、
これにはいつつのシナリオがあって、 この辺を知っておくといいんじゃないかと思いました。
1つ目は結合イベントですね。
The binding event pointと言ってますけど、
結合イベントはイベントそのものを指しますよ というのがまず1つですね。
2つ目に通常の関数ですね。
というのはメソッドの本体を指しますよ と言ってます。
続いて、クラスですね。
クラスを指したりするものとかは、 新しい関数だったりを指し示しますよと言ってますね。
The current class、現在のクラスを指し示すのが ニューファンクションと言ってますが、
これはちょっと訳が変だな。
新しい関数というのは現在のクラスを 示しますよと言ってますね。
続いて、アロー関数ですね。
アローファンクションというのは 親のコンテキストを指しますよというところですね。
ES5からES6に移行するときに、
僕らが結構ドハマりしたポイントの1つですね。
関数定義ってファンクションを なんちゃらかんちゃらって書いたりするのと、
アロー関数で定義するものって 2つあるんですけれど、
現実にはこの2つはスコープというか、
thisが指し示すものが違ったりするよ というところが落とし穴ですね。
ここは結構意識していいかもしれないです。
最後5つ目ですね。
最後5つ目はcallとapplyとbindという JavaScriptの組み込み関数ですね。
この辺は確かにthisとしては 意識しておいていいなと思いますが、
callもapplyもbindも、
昨日も言いましたけど、
あんまり使う機会は少ないかなっていう 最近思ったりしますね。
これも現代のJavaScriptの開発する中で、
フレームワークらへんがその辺を いい感じでラップしたりとか、
機能として提供したりしているので、
あんまりcallとかapply、bindをそのまま、
直接使うことっていうのも 結構少ないのかなと思います。
複雑なものとか、
ちょっとテクニカルな行動をしなきゃ いけなくなったという状況であれば
ありますけど、
基本的にはなくていいのかなって 思ったりはしてますね。
ただ使うときは、
このthisっていうキーワードの指し 示すものって何ですかっていうのを
意識した方がいいなというところでした。
今のがthis。
2つ目のコンセプト、thisキーワードでした。
thisは本当に難しいので、
しっかり学ぶのがいいと思いますけど、
でも学ぶのも難しいので、
いろんな人たちがthisについて 記事書かれているので、
その辺を読んでいただければ いいんじゃないかなと思います。
余談ですと、
もしthisについて復習したり 勉強したい場合はですけど、
thisキーワードについて書かれている 記事が結構古かったとしても、
それは結構僕、参考にしていいと思います。
っていうのもthisっていうキーワードは、
このコンセプト、
そもそもJavaScriptの歴史で ほぼほぼ変わっていないし、
仕様としてもそのまま生きているので、
記事が古くても全然通用するな っていうふうに思ってます。
なので、だいたいKitaとかZとかで スターがめっちゃついている、
06:02
もしくはいいねがすごく高い thisキーワードの記事っていうのは、
そんなに間違いはないと思うので、
そのまま読んでもいいんじゃないかな と思います。
もちろんMDNから勉強するのが 確実ではありますけど、
ちょっとイメージしづらかったり、
実践的な行動っていう意味では、
そういうZenKitaみたいなのを 見ていくのがいいのかなと思ったりしました。
じゃあ余談をさておき戻ります。
続いて3つ目のコンセプトですね。
3つ目はHow Much Do You Know About Type Judgmentですね。
型判定についてどこまで知っていますか っていう話です。
型ですけど、これいわゆるタイプスクリプトの型じゃなくて、
JavaScriptの本来の型になりますね。
JSの型判定というと、
例えばtypeofだったりinstanceofだったりまたconstructだったり、
あとobject.prototype.toString.call みたいなメソッドが浮かびますね。
4つ目のobject.prototype.toString.callメソッドなんて、
あんまり意識しないと思うんですけど、
使ったことある人もほとんどいないと思いますけど、
基本的にはtypeofとinstanceofでいいと思います。
クラスを使っている場合はconstructorを使ってもいいと思いますけど、
この辺を使ってJSの型判定を使うと思いますけども。
そしてこれらの関数とドアの違いっていうのを見てみましょうと、
比較してみましょうと言ってますね。
ドアってどういう意味なのかわからない。
1個1個解説がされてますね。
1つ目です。まずtypeofですね。
typeofっていうのは、
ヌルを除くプリミティブ型は正しい型を表示しますよと。
しかしobjectの場合は関数以外のobjectが表示されるので、
その記録は本来の型を判定するのみで、
objectを判定することはできないというのが注意ですね。
typeofで確かあれを入れてみたら、
objectで確か書いてくるはずなんで、こういうところですね。
なのでobjectっていうところはわかるんですけど、
どういうobjectなのかというのを判定することができないというのが落とし穴ですね。
なのでプリミティブ型っていうのが見たいときにtypeofを使うのが多分いいと思います。
objectのときはtypeofを使うのはあんまり適切ではないよという話ですね。
続いて次にinstanceofですね。
instanceofっていうのは変数がobjectのinstanceかどうかを判定するために使われます。
内部の仕組みはそのプロトタイプチェーンを通じて判定されます。
確かに型が正しいかどうかはわかります。
しかし注目すべきはinstanceofっていうのはプロトタイプを検出し、
プロトタイプチェーン上の全ての型が真であるっていうことを返します。
したがって2つのobjectがinstance関係に属しているかどうかっていうのを判断するのに使えるだけで、
objectのinstanceがどの型に属しているかっていうのを判断することはできませんよっていうことでした。
ちょっと説明が難しいですけどもこの辺は使っていくと
ああなるほどってわかると思うんでその感じですね。
やっぱり名前の通りinstanceofなのでどのinstanceなのかっていうところが見れるので、
それがわかるだけでも結構目的は達成するっていう気はしてますけどね。
09:03
続いていきましょう。
続いてconstructorですね。
constructorはプロトタイプのプロパティであると。
これはそうですね。
関数を定義するとjsエンジンっていうのはその関数よりプロトタイプを追加し、
そのプロトタイプのconstructorのプロパティっていうのは関数の3種を指すので、
プロトタイプを書き換えると元のconstructorが失われることになりますと。
まあそうねっていうので結構破壊的変更というか危険な行動になるのであんまそういうことはしないほうがいいと思います。
基本的にはプロトタイプを書き換えるものじゃなくて追加していったりするものがいいと思います。
まあプロトタイプそのものを書き換えるってやったことは僕はないですけど、
まあまあ必要があればやるんですからね。
まあ今はでもプロトタイプそんなに意識は、
まあ先ほども言った通りですけどしないので、
まあそういう書き方はそのものもまずしないかもしれないですけどね。
まあいいや、そういう感じでした。
まあ一応constructorっていうのはそういうものがありますよってことですね。
これについてもうちょっと法則があるそうですね。
しかしこれらには明らかな欠点もありますと。
で2つぐらい欠点が書かれてますね。
1つ目はヌルとかアンディファインドに対するconstructorっていうのがなくて、
まあこの方式では判定ができないと。
ああそうですね。ヌルとかアンディファインドはしかも、
こいつらはプリミティブ型じゃなくて確かオブジェクト型だったはずですね。
でもこいつらに対するconstructorは確かにないので、
constructorでヌルとかアンディファインドっていうものを判定することができないよってことですね。
確かにこれはそうですね。
で2つ目ですね。
2つ目は開発者っていうのがプロトタイプを書き換えた後にオブジェクトをカスタマイズすると、
元のconstructorが失われてしまいますと。
したがって開発の標準化のために一般にオブジェクトのプロトタイプを書き換える際には、
constructorを再割り当てし、
オブジェクトインスタンスの型が変更されないようにする必要がありますと。
いわゆるコピードとっておいてとかバックアップとっておくって感じですね、
コードの中で。
これをする必要があるのは結構確かにだるいので、
そもそもプロトタイプを書き換えなくて良くないっていう感じですね。
基本的には追加をするっていうところが良いと僕は思っています。
今のが弱点でしたと。
最後4つ目ですね。
toStringメソッドですね。
これはtoStringまでは結構使ったことがある方がいらっしゃると思いますけど、
toString.callまでいくっていうのは現代であんまり聞かない気がしますけどね。
toStringっていうのはいくつかの方式の中で比較的優れたものでは一応あると言ってます。
一応推奨してますよっていうこの人も言ってますね。
toStringっていうのはプロトタイプメソッドで、
このメソッドを呼ぶとデフォルトで現在のオブジェクトのクラスっていうのが返されます。
これはオブジェクトなんちらかんちゃっていうような形式の内部プロパティで、
そのなんちらかんちゃっていうのはオブジェクトの型が返ってきますよっていうふうに言ってますね。
そういうものがあるので結構皆さん型判定するときに
基本的にはまずtypeofとかinstanceofとか使うかもしれないですけど、
意外にtoStringメソッドでやってみると、
表示形式はオブジェクトなんちゃって形になるんですけど、
12:02
ただ判定自体はしっかりできるので、
これはこれで一つの方法でいいよっていうふうに、
この記者の方はこれを推奨してますっていうことでした。
JavaScriptのオブジェクトの話は、
昨日も言いましたけどJavaScriptは全てオブジェクトなんですよね。
関数もオブジェクトですし、
紛らわしいのは頭大文字のオブジェクトですね。
いわゆるオブジェクト型のやつですけど。
全てのオブジェクトはオブジェクト型を
継承したオブジェクトなんですよね。
言語的に内部ですでに継承してるんで、
わざわざあれしなくていいんですけど、
あれとかfunctionとかいろんな
コンストラクターの関数とかオブジェクトあるんですけど、
それは全てオブジェクトオブジェクトを継承してるので、
そこがまた悩ましいというか誤解を招く
ポイントだなって思ったりはしますね。
逆に言うとJavaScriptって関数がオブジェクトなので、
関数そのものを他の引数に使えるし、変数にぶち込めるし、
なんなら関数の中にいきなり
変数を定義したりすることもできるっていう、
他の言語ではなかなか見ない機能があるので、
面白い反面何でもできちゃうので
めんどくさいなっていうのもあったりはしますけどね。
この辺までもやっぱり今はTypeScriptがあるんで、
その辺でしっかりガードしていくのがいいのかなと思いますし、
あとコーディング規約をしっかりしていくのがいいのかなと思いましたね。
ちょっと余談でした。
タイプジャッジメントですね。
型判定にするときのメソッドを4つというところでした。
typeofとinstanceofとconstructorとオブジェクトの
プロトタイプメソッドのtoStringメソッドですね。
っていうのを使っていきましょうということでした。
じゃあ次4つ目ですね。
4つ目のコンセプトですけれども、4つ目は
Let's understand the conversion of the following types togetherと言ってますね。
はい。
以下の型の変換を一緒に理解していきましょうというところです。
というのが、JSの型変換の3つのケースに分けることができると言っていて、
この3つを理解しましょうと。
convert to booleanなんで、booleanへの変換と
convert to numbersとconvert to stringsですね。
booleanと数値と文字列に変換をするというところです。
この辺を一緒に理解しておくといいよという話ですね。
このうちbooleanへの変換というのは、
undefinedとかnullとかfalse、not a numberのnoneですね。
空文字列だったり0、マイナス0とかですね。
これら以外の値は全てtrueに変換されます。
はいはいはい。
いわゆるfalseな値と言ってもいいかもしれないですね。
以外は全てtrueに変換されます。
オブジェクトが見割り当てがどうかというのを判定するときは
日常的に使うことができるので、
この辺使ってみていいんじゃないかなというところでした。
はい。
なるほどね。
JSのコンセプト、5つのコンセプトの中で
これを入れるというのは実践的な観点でいいなと僕は思いましたね。
たぶんそう、booleanとかnumberとかstringAの
いわゆるキャストって言われるもんですよね。
割となんだかんだ使う印象はまだ強いですね。
僕の周りだけかもしれないですけど。
15:01
ので、この辺を確かにコンセプトの1つに入れておくのは確かに良いですし、
特にbooleanAの変換というのに
そのfalseの値というのが全て
falseの値以外は全てtrueに変換されるというのは
結構使い勝手が良いので、
この辺は確かにコンセプトとして知っておいてよいなと思いましたね。
はい。
じゃあ今ので4つ目のコンセプトでした。
ラスト5つ目ですね。
5つ目は…
ちょっと待って、翻訳するので少々お待ちください。
5つ目はですね。
はい。
comparison operators
あとはhow much do we knowですね。
比較演算子のことですね。
比較演算子はどこまで僕らは知っていますかという話です。
比較演算子というのはよく使われるものですよと。
ほぼ毎日使うでしょうと思いますけど。
全て数値型で値の大きさを比較するのであれば当然ながら簡単ですけど
数値以外の値の場合に比較演算子を使う場合はどうでしょうかというところですね。
順序としては次のようになるでしょうという風に言っています。
値はまずprimitiveに変換をして
to primitiveメソッドとかもありますけど
数値に変換すればvalue ofメソッドだったりとか
数値変換はいろんなメソッドあるのでまたこれも悩ましいですけど
この人はとりあえず例としてvalue ofメソッドを使っています。
あと文字列に変換する。
これはto stringメソッドですね。
これはそのまま使えば良いという感じです。
to stringメソッドを使うか
空文字列をプラスでつけるみたいなやり方もちょっと無理やりですけどありますけどね。
そんないろんなやり方あります。
こちらで説明されているので私が述べたことを補足しています。
to primitiveの処理についてですが
to primitiveにはnumberの場合とstringの場合があります。
numberの場合は以下のように実行しますと言っています。
まず入力が元の値であればその値を直接返しますよと。
それ以外の場合は入力がオブジェクトであれば
input.value ofメソッドというのを呼びますと。
その結果がprimitiveであたえてあればその結果を返します。
それ以外の場合はinput.to stringメソッドというのを呼び出しますと。
結果がprimitiveであればそれを返します。
そうでない場合は全部エラーを返してあります。
stringの場合は2と3が入れ替わる。
2と3というのは
入力がオブジェクトならinput.valueを呼んで
結果がprimitiveならその結果を返す。
それ以外の場合はinput.to stringメソッドですね。
呼び出して結果がprimitiveであれば結果を返す。
この順番が入れ替わるよと言っています。
stringを判定したいので
先にto stringメソッドを呼び出すのは確かにそうですね。
numberであれば今のままでですね。
value ofを先に呼び出すよということですね。
to primitiveの値が
stringのときとnumberのときは今の話ですね。
他のときは他のときで別途実装していくことが必要になりますけど
一旦primitive型というのを判定するときには
18:01
今言った通りまずto primitiveを使って
そうじゃない場合はvalue ofを使って
それでも違う場合はto stringを使って
そうじゃない場合は基本的にはprimitiveじゃないから
エラーにするかオブジェクトの型ですよというのを教えてあげるよというところですね。
問題はでも入力値がstringかnumberか
前提で分かっていない場合は
その2と3の順番を入れ替えないといけないというところが
バグの温床になる気はしますので
ここの判定をしっかりしなきゃいけないという感じはありますけど
でもそうやってprimitiveの値の判定というか
値の判定というか検知をすることができますよということでした。
比較演算子というか結局はそういうメソッドに頼っているというような感じはしますね。
比較演算子は基本的には数値型に使うもの
でもそれ以外で値の判定をするときとかというのは
こういうメソッドを使ってやるのもいいよという話でしたね。
というわけで今ので5つ目のコンセプトでした。
今回の教諭は以上になりまして
次回も引き続き教諭しますので皆さんも一緒に議論してくださいと。
読んでくださってありがとうございました。
皆さんの関心を楽しみにしています。
ほげほげという風に言ってました。
以上JavaScriptの5つのコンセプトですね。
というところですね。
僕の中ではそんな何か驚くほどの学びがあったというか
そんなエクセレントなフロントデベロッパーになるための
コンセプトというほどでもないのかなと思いました。
JavaScriptという言語そのものに対しての
そのいわゆるエクセレントデベロッパーになるためのというお話なので
現代のフロントエンド開発という観点で僕は物を見がちなので
この記事自体がすぐに参考になるかというと
そうでもないなという意味で
あんまり印象に残らなかったところですけど
JSそのものを勉強するという意味では
この5つのコンセプトは確かに知っとって損はないし
知るべきだなというものも確かにあったので
その辺を見てもらえればいいのかなと思いましたね。
やっぱりそうですね。
結局は2つ目のコンセプトです。
JavaScriptという言語は
言語仕様としてスコープが本当に課題になってくるので
今後先ESXが、ESですね、
JavaScriptがどんな風に進化していくかわからないですけど
どうやってもJavaScriptである限り
多分このディスと戦うのは逃れられないというのは僕は思っているので
ここはもう絶対的に知るべきだなと思います。
あといろんなライブラリ使ったりとか
フレームワーク使ったりもして
中で時折結局ディスってなんだっていうか
こいつのコンテキストってなんだっていうのを
悩む必要が出てくるのは今後もいっぱい出てくると思うので
JSのフレームワークである限りは
なのでここをまずはしっかり抑えていくのがいいんじゃないかなと思いましたね。
他にもいっぱいありますけどね。
仮移課だったりいわゆるキャッシュ化するとかメモ化ですね。
メモライズっていうのもあったりするし
さっき言ったスコープもどこからコールするかっていうところで
スコープの判定も結構ありますし
21:00
巻き上げがあったりしますからね。
JavaScriptである限りプロトタイプは本当悩ましいですけど
知っておいていいけど使うかというと
ほぼ使わないよっていう感じはしますね。
むしろ普通にクラス構文でいいと思いますけどね。
一応シンタックスシューガーなので結局はプロトタイプなんですけど
概念として知っておいて別にいいのかと思います。
それよりもやっぱりエグマスクリプトの最新の機能を追っておくっていうのも
一つ僕はいいんじゃないかなと思ったりしているので
そっちのほうが大事かなという気はしますね。
あとは個人的には最後の5つ目の比較演算子と話しましたけど
比較演算子よりも多分審議事表を覚えておくか
全部覚えなくてもいいので
審議事表でよく使うものだけでも
インプットしておくのがいいと思います。
いわゆるJavaScriptのフォルシーな単位にゼロが入ってきたりするとか
NullとかUndefinedとか何とかっていうJSならではの扱いになったりする
一応NullとかUndefinedは他の言語でもあるんですけど
JSでの扱いっていうのはまたどうなのかっていうのは
しっかり把握しておく必要が出てくると思いますので
この辺ですかね。
あとは何ですか。
落とし穴系で言うと多分
あれですね。
足し算、ひざんというか加算減算のところですね。
プラスとマイナスのところですけど
そういったものを足したり引いたりするときに
例えば片方に文字列で片方が数字だったりすると
勝手に文字列変換に内部的にキャストされますよみたいなとか
こういう落とし穴系を知っておいたほうがいいと思うので
JSを勉強するんだったらこの辺かなっていうのが
僕の観点というか
今まで経験して考えたコンセプトかなと思ったりします。
結局いっぱい出てくるんであれですけど
優先度的にはやっぱりThisですよってことですね。
という話で若干時間余っちゃったんですけど
中途半端になりそうなので
今日はここで以上にしたいかなと思います。
ここ2,3日JSの記事を読んだので
次はCSSかデザイン周りかという話を探して
もし見つかれば読みたいと思います。
じゃなければもうちょっとフィロソフィーというか
哲学的な話が僕結構大好きなので
その辺の記事を読んでいこうかなと思いますので
また明日もごゆるりと参加いただけたら
すごく嬉しいなと思います。
逆にこういうものを読んでほしいとか
こういう記事ないですかっていうオーダーがあったら
全然探しますので
そういうのも投げてもらえたらすごく嬉しいなと思います。
では今日の朝活動はこちらで以上にしたいかなと思います。
今日もたくさんの方ご参加いただきありがとうございました。
では火曜日ですね。
今日もお仕事ある方頑張っていただければなと思います。
では終了します。お疲れ様でした。
