htsign's blog

ノンジャンルで書くつもりだけど技術系が多いんじゃないかと思います

トップ > JavaScript

全てのフレームを対象にするには

JavaScript

某大手工業系企業の新規開発プロジェクトに参画しているのですが、非常に悲しいことに社内ポータルが未だにフレームを使用したサイトなのです。
フレームを使うと容易にペインで分けたサイトを構築できるため、実用重視のエンタープライズ界隈で重宝されるのはよく分かります。

ただ、フレーム*1を使うと、ブックマークレットを作ろうと思ったときにそのままではトップレベルのウィンドウにしか効力を発揮しません。
埋め込まれているフレームのソースURLがトップレベルのウィンドウと同じドメインに属しているのであれば*2、以下のようなコードを使うことで全フレームに対して操作することができます。

// for IE9+
(function loop(win) {
  return Array.prototype.reduce.call(win, function(p, c) {
    return p.concat(loop(c.window));
  }, [win]);
})(window)
.forEach(function(window) {
  var document;
  try { document = window.document; } catch(e) { return; }
  /* code here */
});

// compressed
(function l(w){return [].reduce.call(w,function(p,c){return p.concat(l(c.window))},[w])})(window).forEach(function(w){try{var d=w.document}catch(e){return}/* code here */})

*1:<iframe>も同様です。

*2:Same-Origin PolicyはWebにおける重要な概念です。

リンク化スクリプト

Firefox GreaseMonkey JavaScript bookmarklet

かねてからHatena::Let で公開 *1 していて、個人的にもかなり使っているスクリプトをGreaseMonkey用に書き直したのでそれも公開してみます。
https://gist.github.com/htsign/5eed5473a9e75c7c45f3a5571d7d0803/raw/convertTextToLink.user.js

GreaseMonkey用っていうか単にES2015で書き直しただけで、特別GreaseMonkeyには依存していませんが。

せっかくなのでGreaseMonkey版はMutationObserverによる追加ノードの監視機能も付けました。
Hatena::Letの方（以下、ブックマークレット版）にはこの機能は持たせていません。
対象となるブラウザの範囲にIEも入るからです。
新しいノードに適用する為には都度実行してやれば済む話で、別にそんなに手間なわけでもありませんし。

一応Mutation Events（document.addEventListener("DOMNodeInserted", ...みたいなやつ）はIE9から対応していますが、これは既に非推奨となった技術なので積極的に採用するつもりはないです。
場合分けめんどいですしね（本音）

NodeIteratorで探索しているのでそれなりに速いと思いますが、そもそもの計算量の時点でたかが知れてるのでアレです。

注意点として、テキストに対して要素を追加する（DOMに破壊的変更を加える）為、DOMの構造に依存した外部コードがある場合には不具合の原因となる可能性があります。

*1:ブックマークレット版もES2015版での大幅な編集に合わせてだいぶ構造変わってます

以後は特に指定のない限りJSはES6記法で書いていこうと思います。

JavaScript

Intlオブジェクトというものを知りました。
国際化表記における各種変換を取りまとめるそこそこ大規模なオブジェクトらしい。

Collator DateTimeFormat NumberFormatの3つのサブオブジェクトを持つ模様。
それぞれインスタンス化して使用するっぽい。

(() => {
  let localeOption = { style: "currency", currency: "jpy" };
  let locale = new Intl.NumberFormat("ja-JP", localeOption);
  console.log(locale.format(1234500)); // => ¥1,234,500
})();

便利。

第二引数のoptionにcurrencyDisplayを指定すると表記方法が変わるっぽい。
currencyDisplay: "symbol"がデフォルトで、他にcodeとnameがあるらしい。
symbolの場合の記号が半角とか全角とか、その辺は実装依存っぽい。

とか思ってたら

Number#toLocaleStringとか、他の代表的なオブジェクトにメソッドとして同等機能が提供されていた。
newはオーバーヘッドも大きいし*1、特別な理由がない限りは基本こっちですね。

*1:実測はしていませんが

Microsoft Edge (Windows 10 Mobile) のUser-Agent

JavaScript Windows Phone Edge

なかなかすごいことになっています。
どこかの記事（確かスラド辺り）で読んだことありますが、WebKitと同じ挙動を示すようにしたとかなんとか。

Lumia 950で確認しました。

Mozilla/5.0 (Windows Phone 10.0; Android 4.2.1; Microsoft; Lumia 950) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Mobile Safari/537.36 Edge/13.10586

例えば以下のような条件判定に一致するようになります。

var ua = navigator.userAgent.toLowerCase(), cond;

cond = /android/.test(ua) && /mobile/.test(ua);
console.log("Android : " + cond); // "Android : true"

cond = /safari/.test(ua);
console.log("Safari : " + cond);  // "Safari : true"

Linux; U;が入っていないのが救いですね。
参照: 滅び行くAndroid 標準ブラウザをサポート外にして悩みの種をなくす話 - Qiita


User-Agentでブラウザの判断をせざるを得ない現状も個人的にはどうかと思います。
本当であれば機能面で分けるべきなんですよね。

console.log("Legacy IE : " + (/*@cc_on ! @*/false));

var webkitKeys = Object.keys(window).filter(function(e){
  return window.hasOwnProperty(e) && e.indexOf("webkit") !== -1;
});
console.log("WebKit : " + (webkitKeys.length > 0));

まぁこれはこれで穴がありますが…。