jQueryで追加した要素にイベントを付与する!

こんばんは、有村です。年の瀬ですね。
おそらく今年最後の投稿です。

今日は、「jQueryで追加した要素にイベントを付与する」をテーマに記事を書きます。

まずは簡単な仕様。

・ページ読み込み後、複数の .parent に対して .child を子要素として保持しているか精査。
・.child を保持していた場合、.parent の子要素として .btn を追加する。
・.btn をクリックすると、.child が開いたり閉じたりする。

まあ要はアコーディオンってやつですね。
ここのポイントは、「ページ読み込みの状態では .btn は存在していない」という点です。

で、私は最初こう書きました。

動きそうに見えるじゃないですか?
でも、実際には…

・子要素に .child がいれば、ボタンは追加される
・でも .btn を押しても何も起こらない

という挙動になりました。なぜ。

原因はお分かりですね、 .btn に click イベントを付与するタイミングでは、まだ .btn が存在していないんです。
なので、後から「追加されたでーーーwww」ってやってきた .btn ちゃんは、イベントを何も持っていない…となるのです。

で、早速解決法。

先ほどと違うのは、セレクタが .parent になって、on の第2引数に .btn が追加された点です。

じゃあなぜこれで動くのか?どうやらこれはバブリングを利用しているようです。
バブリングは 対象 → 先祖 にイベントが伝わっていくことを指します。つまり、.btn をクリックしたら、その親要素である .parent にもクリックイベントが伝わっているということです。
それを利用して、このonメソッドでは、

・.btn をクリックする
・.parent にバブリングでクリックイベントが伝わる
・元々のイベントの発生源が第2引数の要素とマッチしているか精査
・マッチしていたならばfunction実行

という流れが行われているようです。便利!!!!
thisの値も、発生源である .btn 自身が返ってきます。

年の終わりにいい発見があってよかったです!
来年もこまめに更新できたら…いいな…

それでは、良いお年を。

関数もオブジェクトである。

こんばんは。有村です。
橘さんに「全然ブログ更新しねーな」と言ったんですけど、それを言ってしまった以上、私が更新しないと「お前もなwww」と返ってきそうなので、書きます。

さて早速ですけど、javascript における関数はオブジェクトなんですって。まあその辺はググれば山ほど出てきますし割愛するとして…

関数の書き方なんですけど、

って記述もできるし、

ってのもできますよね。

私、後者の書き方って何がいいんだろうとずっと謎だったんですけど、ようやく見えてきた気がします。

たとえば、メッセージボックスを開いたり、閉じたりする処理を実装するとします。(toggleで一発やんとかは置いておいて…)
そういうときは今までだと、

って書いていたんですけど。
これだけで終わればいいんですけど、もっと複雑な仕様になると、

とか関数がどんどん増えそうですよね。
どれだけ messageBox にまつわる関数を量産すれば気が済むねんってなりそうです。

そこで、冒頭の話題に戻りますが、関数はオブジェクトなんです。
オブジェクト…オブジェクト……。まずは、もしこの messageBox にまつわる仕様を、オブジェクトっぽく書いたらどうなるでしょうか?

おお、先程の messageBoxなんちゃらの羅列より、なんだかすっきりした気がします!
ただこれだともちろん動かないので、javascriptっぽく書くと…

メッセージボックスを開きたければ、

おおおおー、なんだか分かりやすくなりました!

ひとつひとつ関数を書くやり方だと、頑張って関数名に規則性を持たせても「どこからどこまでが messageBox の仕様…?」と見にくいですし、見にくいが故に「他の案件でもこのソース使おう♪」ってなったときに使い回ししにくいなと思います。
オブジェクトとして書くと、「機能のまとまり」として捉えられるので、使う人にとっても優しいコードになるのではないでしょうか?

今まではメリットが分からなくて、実際にこの書き方したことはないんですけど…
ある日仕事してる夢を見て、その夢の中で上記みたいなソース書きながら「あー!分かった!こういうことかー!」って言っていたので、備忘録も兼ねて記事にしました。
にしても、夢の中でアハ体験するって、職業病というよりなんか病んでる気がする。

それでは、今日はこのへんで。

暗黙の型変換

久しぶりです!原田です!

サボってました!すいません!

 

さてさて「暗黙の型変換」ってありますよね、忘れると怖いんで殴り書きします。

これって、PHPだけかと思ってたらSQLもあるらしいです!調べたらまた書きまーす。

 

$a == $b って型変換をした後に、等しいかどうかを判断してるんです。

$a != $b、$a <> $bも型変換後に比較をしているそうです。

↑ switch 文にも当てはまります!

※ === あるいは !== による比較では型変換はしない!型も比較するためです。

 

 

具体的に考えると、、、

比較対象に文字列があると、文字列を数値に変換された後、比較を行うそうです。

$str = ‘string’;      //文字列→数値に変換 (int)”test”; →0(ゼロ)

$num = 0;

if ( $str == $num ) {

echo ‘true’;    //まさかのtrueとなる!

} else {

echo ‘false’;  //falseになると思いきやならない。

}

文字列と数値の比較って思わぬ結果を招く危険があるんですね。

型意識があまりなかったので、一つ一つの型をちゃんとみようと思いました。

 

 

 

 

ファサードについて考える(超初級編)

こんばんは。有村です。
年末が近づくにつれ忙しくなる、これITあるある。

さて今日は、デザインパターンのファサードについて有村なりに考えてみました。

Q:ファサードの例をあげてみて!
A:jQueryのメソッドを思い出すよろし

ファサードは玄関…つまり窓口…という表現は色々な記事で見かけましたが、いまいちピンときませんでした。
また、複雑な処理を隠蔽する…という役割もあるそうですが、これも言葉で言われても理解できません…。

そんな中、一番「あー」ってなったのは、「jQueryのメソッドはファサード」という表現です。

たとえばjQueryのメソッドを使うとき、IE8だとこの書き方…IE9からだとこっち…とか考えないですよね。生のjavascriptだと、IE8はaddEventlistenerが使えないなど考慮しなければならないのですが。
では、jQueryではそれらを考えなくてもメソッドひとつでいい感じになるのはなぜか?
答えは、jQueryのメソッドの中で、ブラウザに応じた分岐処理をやってくれているからです。

また、ブラウザの分岐にとどまらず、生のJSで書いたら相当に長くなる処理であっても、私たちはその先にある処理を意識することなく「メソッドを呼び出しさえすれば」実現することができます。
つまりこんな感じで、中で何やってるのかは分からないけど、この窓口を叩けば後はいい感じにやってくれる、というのがファサードの考え方の掴みなのかな?と思っています。

窓口と処理する人、という考え方は実生活にも則しているな〜と思うと、 処理する人 → 専門職 → つまりそいつらは1つの役割しか持たない → 関数の細分化と抽象化 にも発想が発展するような気がしますね!

それでは、今日はこのへんで。

schema.orgと初めての遭遇

こんばんは。有村です。
もう1ヶ月くらい風邪をひいている気がするのですが、これもう風邪じゃないですよね?

さて今日は、「構造化マークアップ」とか「schema.org」とか、「聞いたことはある…だがよく分からねえ用語」と対峙したので、ゆるくまとめてみます。

Q:schema.orgってなんなのさ?
A:検索エンジンに正確なページの情報を伝えるための記法。

このコードだけ見たとき、「h1だから、ほげほげはそれなりに大きな見出しなんだろな…」と分かりますが、具体的にそれが何かは分からない。
その下に「100円」と書かれた要素がいるので、ああーこれは商品名なのかな?と予想がつくかも知れませんが、はっきり明示されてはいませんよね。
おそらく、商品名なのかな?どうかな?という疑問は、検索エンジンにとってもそうなのでしょう。
例の如く色々端折りますが、

とした場合、「商品について述べるでー」「ほげほげが商品名やでー」「100円が商品価格やでー」と明示したことになります。これなら検索エンジンにも分かりやすいですね!

Q:で、なにがメリットなんですか?
A:検索結果が最適化されるよ
検索結果が最適化…?日本語でおk…ですが、ブラウザで何かを検索した結果でレビューの☆が出てきたり、サイト名の下にサイト内検索ができる検索窓が出てきたり…というのは、誰しも一度は見たことがあると思います。それが検索結果の最適化だそうです。
このラーメンおいしいかな?どうかな?と店舗名で検索したときに、ラーメンの画像が出てきたり、評価が★★★★☆だったりすると、「おお〜行ってみようかな!」ってなりますよね。逆も然り。
この場合、ラーメンの店舗名で検索するユーザが求めるのは「ラーメンの評価はどうか」「見た目はおいしそうか」などだと思うので、検索結果が最適化されている、というのはなるほど納得です。

Q:ってことは、ちゃんとやれば検索結果表示順もグイグイ上がるってことですね!
A:検索結果表示順には直接影響ないらしい(悲報)
SEOと同じで、ちゃんと書けば表示順に反映されるものなのかと思ってましたが、どうやらそれは違うらしい。
あくまで検索結果の最適化であって、schema.orgを適切に使ったからといって表示順には直接影響はないとのこと。
ただ、
検索結果が分かりやすい → ページのアクセスが増える → 優良サイトとして検索エンジンが認識、表示順アップ
というのはありそう。というか、絶対あると思います。

schema.orgとの遭遇で、分かってきたのはそんな感じです。
本気でやろうと思ったらかなり奥が深くて、今日はさわりだけでしたが…「良いWEBコンテンツ」を作成する上では避けて通れなそうですね!仲良くするぞ!

それでは、今日はこのへんで。

他の世界を見て分かったこと(※ただの雑記)

こんばんは、有村です。
超ご無沙汰してました。なんか忙しくて。言い訳です。

リハビリがてら記事書こうと思ったのですが、リハビリなのでね、ただ雑記だけ書いて今日は終わりにしようと思います。

今まで色々オブジェクト指向ってなんぞやとか調べて一丁前に記事書いたりしてましたけど、実のところ「ほーん、すごいなあ(小並感)」くらいで終わってたんですよね。
そんな中、いつもお世話になってる偉大な先輩から「そろそろオブジェクト指向とかデザインパターンとか分かってくるんちゃう?(鼻ホジー)」とアドバイスもらったので、改めてMDNの記事を読んでみたんですけど。

な、なんだこれは!?分かる!分かるぞ!!!!
な感じでスルスルと(※あくまで前と比較して)入ってくるようになってました。

でも最近JSをガッツリ書いてない気がするんだけどな〜なんでだろな〜と考えたら、あることに気付きました。
確かにJSは書いてなかったけど、その代わりPHPを読んだり書いたりする頻度が増えたな、と。

JSではオブジェクトとかclassとかnewとかインスタンスとか意識して書くこと少ないですけど(頭いい人は意識してるのかもしれないけど、あたしゃしてないのよ!)、PHPはそれらありきというか、それ使わないでどうやって書くの!?って言語ですよね……なかなか理解できなくて何度も涙を流さず泣きました。
それらをなんとな〜く理解できるようになってきてからのJSだったので、知らず知らずのうちに何かが身についていたのかも知れません。
ちなみに先輩が先述の発言をしたのは、変数の命名を見てピンときたらしい。確かにいま見るとオブジェクトっぽい書き方をしている。でもそれだけでよく分かったな。

まぁオブジェクト指向でやってみろ!って言われてもやっぱり書ける気はしないんですけどね(小声)

で何が言いたいかというと、もっといいコード書きたいなーでも頭いい人の言うことはよく分からんわーってなったら、他の言語を触って見ると新しい世界が開けるかもという実体験話なのでした。
私はHTMLとCSSとJSの世界しか知らなかったので、余計にそう感じるのかも知れませんが…。いま悩んでいる人にちょっとでもアドバイスになればいいなと思って記事にしてみました。
技術的な話が本当に何もなくてすみません!

それでは、今日はこのへんで。おやすみなさい。