ダーシマ・ヱンヂニヤリングスマートフォン用の表示で見るダーシマ・ヱンヂニヤリングこの広告は、90日以上更新していないブログに表示しています。2014-04-23ブログを移転しました!ネコメシが社員ブログを独立して始めたことに伴い、本ブログ、ダーシマ・ヱンヂニヤリングも移転しました。ダーシマ・ヱンヂニヤリング超絶おすすめブログです!!記事の移行はないため、このはてなブログはそのまま残していますが、フィード購読などの登録をされていた場合は登録変更をお願いします。今後とも、ネコメシぶろぐ及びダーシマ・ヱンヂニヤリングを宜しくお願い申し上げます。優れた方法論だと思うが、大変めんどうくさいことを強いてくることがある。変えられるかどうかを思索するものである。」くなっている面もあると思うが、そこは承知の上なので念頭に置かれたし。Gistのライブラリをアップデートしました。Gistのライブラリをアップデートしました。投稿する処理を持つウェブアプリはよくあると思う。そのときに実装する必要がある機能のひとつに文字数カウントの機能がある。内でバリデーションを行いたい機会は少なくないはずだ。数えたい神経質な人向けなので、ある程度の精度でよいという方は他の方の作られたライブラリを参照するのがよいと思います。短縮したりする処理のことを考えると一筋縄には行かない。文字としてカウントされることになっている。23文字としてカウントされることになっている。正しく正規表現で引っ掛けるのはなかなか骨が折れる。使われているロジックをそのまま流用できればよい。リポジトリが公開されている。リンクをクリックすると、そのソースが出てくる。これを流用すれば、正確なツイート文字数カウントができるはずだ。ためしに実装してみたのが以下。いうメソッドが文字数を数える関数で、プレーン文字列を渡せば文字数が返ってくる。ダウンロードし、ページから読みこめばよい。正確に数えるためとはいえ、ツイート文字数を数えるためだけにこのライブラリを導入するのはちょっと気後れする。このライブラリは、文字数を数える以外にもいろいろな機能が含まれている。ハッシュタグが含まれているツイートにリンクタグを付与する関数など。これらの機能は、文字数を数えるという目的には必要ないので削ることができる。そこで削ってみたのが以下。行あるが、だいぶましになった。同じように使えるように互換性を保ちつつ、機能削減や軽量化・高速化が図られているライブラリ。強くらいのサイズになるので、読み込み容量がシビアなモバイル向けのウェブサイトを作るときには特に重宝する。互換性があるが、ときどき微妙なところで挙動が異なっているのが玉にきず。そんな傷入りの機能のひとつのようだ。とで異なっている不具合。時点での不具合なので、もっとあとのバージョンでは修正されているかもしれない。jQueryZepto.jsパラメータにオブジェクトの配列を渡した時に、出力される文字列が異なっているのがわかる。いう関数が呼ばれている。リクエストを行うための形式に変換する関数で、まさに挙動の差の原因となっている部分。パラメーターを受け取るとおかしくなる(と思う。出力形式に統一したい。当該コードと置き換えればよろしい。コードを置換することを想定しているので、それ以外のバージョンの場合はお気をつけて。リポジトリに上がっていたプルリクエストから抜粋した。6ヶ月前に起票されたプルリクだけれども今のところ取り込まれていない。コミッターの人も口出ししているので、そのうち取り込まれるのではないかと思う。ファイルに直接手を入れるのは気が進まないと思う。その場合は以下のような感じでムリヤリオーバーライドする感じでいいのではないかと。できるライブラリであるRequireJSをプロジェクトで使ってみた。プロジェクトの規模感を簡単に説明しておくと、まず単画面アプリケーションではなく、従来通りテンプレートが複数あるウェブサイトだ。あるウェブサイトとはいえ、JavaScriptで動く機能やUIがたくさんあり、テンプレートのパターンが100枚以上ある。カルーセルと画像切り替えが動けばヨシ、みたいなそこらのコーポレートサイトよりは遥かに規模の大きいウェブサイトとなっている。導入を決めたのは、今回のプロジェクトで必ず現出するであろう懸念点を、あらかじめ潰しておきたかったという動機から。その懸念点というのは主にファイルサイズの問題。ウェブサイト内で使われている全JSファイルを全て結合圧縮すると、最終的に1MBくらいになってしまい、初回ロード時に読ませるにはちょっとキツい。可能なら、使用されるページが限定されているJSファイルは、必要なときにだけリクエストされるようにしたかった。いう意味では、今回の導入の動機は“ファイルサイズ、リクエスト数の最適化”であって、“モジュール管理”ではない。いう前提がありますね。RequireJSを使って良かった点まともにモジュール管理ができるようになったコンパイルが強力。稀になかなかJSが実行されない以下、詳細。まともにモジュール管理ができるようになったJavaScriptは言語仕様としてモジュールの仕組みを持っていないため、モジュール管理的な事をしようと思ったら自前で用意しなければならない。場合、ルールとしてモジュール名やオブジェクトのツリー構造を決めていくことになる。RequireJSを導入することによって、1ファイル=1モジュールと半ば強制的になる。そのためツリー構造はフォルダツリーを見れば把握できるようになる。それから、依存関係を明示することで、そのモジュールの正体が把握しやすくなった。JSの読み込み順を気にする必要もなく、無用なストレスから開放された。Gruntとの相性が良かったRequireJSを使うと、1モジュール=1ファイルになるため、ファイル数がドーンと増える。いう懸念があるが、提供されているオプティマイザーを使うと、依存しているファイルを再帰的に探って1ファイルにまとめてくれる。このオプティマイズのタスクをGruntに任せることができて、楽だった。「全部のページでモジュールA,B,Cは読み込ませたい。モジュールD,Eは特定のページでしか使わない」という場合にも、オプティマイザを使うことで「モジュールA,B,Cを含むABC.js」と「モジュールD,Eを含むDE.js」に別々に結合・圧縮することもできる。モジュールDがモジュールAに依存していたとしても、DE.jsにはAを含まないように、よしなにやってくれたりもする。このやり方はまた別のエントリーにするかもしれない。3ファイルにまとまった。scriptタグをHTMLに埋め込むと厄介RequireJSに則ってモジュール定義したものを、HTMLの中から直接scriptタグを使って埋め込もうとするとハマる。非同期読み込みなので、scriptタグが登場した時点でそのモジュールが存在している保証がないためだ。そもそもどういう機会にscriptタグをHTMLに直接記述するかというと、例えば画像切り替えのJSを即時発動したい時。ある書き方は以下のような感じ。Readyのタイミングまで発動されないのが欠点。そのため、画像をクリックしても何も起きないタイミングが存在してしまうことになる。$('#image_switcher_1').imageSwitcher();</script>となり、該当箇所のDOM構築が終わった直後にJSを発動するので、画像をクリックしても何も起きないタイミングがほぼ無い。RequireJSを使用していると、上の例でscriptタグが登場した時点でそのモジュールが存在している保証がないため、こういう細かいパフォーマンス調整は出来なくなってしまう......。稀になかなかJSが実行されない予想以上にスクリプトのリクエストが遅延して、なかなかJSが発動されないケースがある。ブラウザにもよるけど、ブラウザは同時に8リクエストくらいしかできない。その帯域をCSSや画像などで埋められていると、JSのリクエストが後回しになり、そのぶん実行が遅れる。Readyよりずっと後になってしまうこともある。ような「とりあえず入れとけばよい」系のプロダクトではないと思った。入れるべきか、控えるべきかを切り分けるキーになるものは、プロジェクトの規模なのかなー。ある程度の規模になると、モジュール管理の機構をなくしてコードを書くのが困難になる。スクリプトの結合・圧縮もスマートに行いたくなる。このあたり、必要のない程度の規模のプロジェクトであれば、わざわざ導入しなくてもよいかもしれない。JSの実行が大幅に遅れてしまうことが稀にある問題は、結構なネックとなっているとおもう。仕組み的に仕方ないとはいえ、これがあるから導入を見送るという考え方は全然アリだと思う。16:53RequireJSをプロジェクトで使ってみての所感Tweet広告を非表示にするもっと読むコメントを書く次のページプロフィールid:tsmd株式会社ネコメシに務めるフロントエンドエンジニアです。本ブログは移転しました。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。