concatだらけになるtemplate literal - Qiita
Babelで変換されたあとのコードを見ると、一見無駄にも思えるコードが生成されていたのですが、実はそれが必要だった、というお話です。 Template Literalとは ES5までのJavaScriptでは、文字列を合成するには「1つ1つ+演算子で連結していく」「Array.prototype.joinで連結する」などの手法があったのですが、どちらの方法にしてもどのような構造の文字列ができるか、分かりづらいものでした。 ES6では、他言語のように文字列途中で式展開ができる、Template Literalが登場しています1。引用符として`...`を使い、式展開はその途中に${...}と書くという、他言語と比べてもそこまで違和感のない記法となっています。 Babelでの変換結果 で、例によってIEは非対応なので（MDN）、IEを切り捨てられない環境ではBabelでの変換が必要となります。こ
入力直後に変換を入れる場合のUX - Qiita
Controlledのメリット ReactではControlled Componentといって、デフォルトで<input>などにデータは保存されず、onChangeイベントでデータを拾って回収する必要があります。 ただ、必ずしもこれは入力フォームのデータをそのまま保存する必要がない、ということでもあります。たとえば、内部で扱うデータは摂氏だけど、onChangeで華氏→摂氏に変換、valueで逆変換を行えば、データ構造に変化なくフォームだけ華氏に切り替えられます。 不可逆変換の、UX上の問題点 そのように、可逆な変換を行う分にはユーザーが気づく機会もなく、便利なだけなのですが、不可逆な変換を入れるととたんにややこしくなります。 たとえば、onChangeで数字をコンマ区切りにするような処理を入れた場合、「12,345」を入力するつもりであっても、「1234」まで入力したところで「1,234
@babel/pluginのloose/specモードについてまとめ - Qiita
Babel 7がリリースされたということで、気になる点について調査を行っていたのですが、その過程で一部のプラグインにlooseモードがあるということを知ったので、それについてまとめてみます。 looseモードとは JSXのようなそもそもJavaScriptにないものは別として、Babelのプラグインが変換する各文法構造については、EcmaScriptとして厳密な動作仕様が決まっています。 ただ、変換して実行する過程で、「厳密に言えば仕様どおりになっていなくても、重箱の隅はつつかないから処理が早い/コードが短い、実用充分なコードになればそれでいい」という需要もあります。そういうのに対応するのがlooseモードです。 逆に、「厳密な動作のほうが需要が少ない」と判断された場合には、specで厳密な動作に切り替える、という仕組みのものもあります。 Object.definePropertyと代入の
document.allという名の亡霊 - Qiita
JavaScriptは、「Don't break the web」ということを念頭に、仕様拡張なども構成されていっているのですが、時として妙なものも発生してしまいます。 falsyな値 JavaScriptにはfalsyな値が7つ（0、-0、NaN、false、null、undefined、''）ある、ということは有名かと思います。…で、MDNを見てみると、8つ目の値が存在します。それが、document.allです。 仕様としての挙動 通常のJavaScriptにfalsyとなるオブジェクトは存在しませんから、明らかに目立つ挙動なのですが、WHATWGの仕様を参照してみると、さらにすごい挙動をするとのことでした。 typeof document.all === 'undefined' document.all == null、document.all == undefined（===では
PolyfillとPonyfill - Qiita
JavaScriptを書くにあたって、未だにブラウザによっては存在しない機能を考慮せざるを得ない状況が続いています。そこで取る対策として、PolyfillとPonyfillがあります。 気の抜けない、ブラウザごとの差 最近でこそブラウザは強制バージョンアップするものが増えてきましたが、もはやバージョンアップすることのないIE 11、そしてOSとセットでしかアップデートできないiOSのSafariなど、常に最新といかない環境も残り続けています。さらに言えば、JavaScript自体もECMA 201xというように、毎年バージョンアップし続けるので、ブラウザごとにそれをキャッチアップできるタイミングも違ってきます。 ということで、どこまで行っても「ブラウザごとの実装差」は残り続けることとなってしまいます。 Polyfillのメリットと欠点 Polyfillとは、「標準となったメソッドが存在しな
Reflowを制するものはDOMを制す - Qiita
すごい記事が1日目2日目で来ている中で恐縮ではありますが、フロントエンドJavaScriptでパフォーマンス点から気にしたほうがいい部分について書いてみることにします。 DOM律速になるケースもある よく「JavaScriptが遅い」ということも多いのですが、具体的にはどのあたりが遅くなってくるのでしょうか. 純粋にJavaScriptのスクリプト処理が遅い…最近はブラウザ自体も高速化しては来ましたが、それを追いかけるようにJavaScriptの巨大化も進んでいます。ただし、純粋にプログラム言語的な処理なら、Web Workerに振ることで並列化が可能です。 Ajaxや画像読み込みなどの通信が遅い…サーバ側で高速化する手もありますが、状況によってはJavaScriptで先読みを始めておいて、体感時間を短くすることも可能かもしれません。 DOM操作・表示が遅い…これについて今回考えてみます。
手書きしたほうが速いメソッドと疎な配列 - Qiita
JavaScriptで配列を駆使するようなプログラムを書くことも多いですが、状況によっては標準のメソッドを使うより、手書きでループを回したほうが速いこともあります。 Qiitaの記事を読んでいて 少し前に投稿されたTypeScriptの記事を見ていたのですが、その中で、 重大なボトルネックとなりうるため全体で100msに1回以上の間隔で実行される場合を除き以下のメソッドを原則使用禁止とする。 Array#concat Array#slice Array#splice なんていう記述がありました。さすがに「え、そうなの？」と思いましたが、すぐ下に付いていたベンチマークは、たしかにそのような結果を示しました。 そうなる理由 もちろん、ネイティブに実装してあることもあるような標準メソッドが、JavaScript上に実装したものより遅いというのはさすがにおかしいので、調べてみました。すると、原因が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
