JavaScript Map オレオレ拡張

今、かつてないほどJavaScriptと関わっている。
※JavaScriptという名称は正式にはOracleの登録商標で一般的には ECMA Script って事になるんだろうけど、めんどくさいので JavaScript と明記する。あらかじめご了承のほど。

僕のJavaScriptの文法、その他の知識は正直2010年(ES5)ぐらいで止まってる。というのも今持っている知識だけで要求されるほとんどのケースが実現可能だからだ。
もちろんパフォーマンス的な、効率的な・・・というのは棚に上げまくっているんだけど。その当時も ES6 も意識していましたが、まだブラウザでの実装状況が混沌としててInternetExplorerがまだまだ全盛時代だったので、どうしてもすべてのケースで動くように ES5 を強制していた。

今の JavaScript って5~6年前によく見たコーディングスタイルとは全然違いますよね。
ブラウザでホスティングされているJavaScriptで普通にラムダ式が使えるし、変数宣言で var ではなく let を使うことでブロックスコープを意識したコーディングができる。
まぁ、今頃こんなこと書いても、今更感が半端ないんですけどね。

去年から現在進行形で携わっている仕事では、徐々に(少しずつ) ES6 を意識したコーディングを心がけるようになってきました。ほんとに少しずつですけどね💦

余談:(余談ばっかりだが・・・)——————
理由はマイクロソフトが正式に Internet Explorer 及び edge-HTMLをベースにしたEdgeブラウザのサポートを止める、もしくは新規開発しない、事を宣言したから。
残念なことだけど、ITリテラシーの低い人たちからすれば、未だにInternet Explorer がインターネット業界(笑)の標準だと思っている人が結構多い。
マイクロソフトがレガシーブラウザと決別宣言してくれたおかげで、ChromeやFireFox,Chromium版Edgeを強制することが可能になったことが非常に大きい。
———————-

一番意識しているのは(オブジェクト初期化子{}でインスタンスを作る)オブジェクトを連想配列的に使用するのを止めてMap や Set を使うことにしたこと。
MapやSetもかなり以前から実装されているけど、やっぱり InternetExplorer11 では限定的な実装なので使うのも躊躇してた。

Map,Set は非常に便利ですよね。オブジェクトを使用した連想配列では、キー(プロパティー)に文字列ぐらいしか使えない。Mapだとキーに何でも入る。
MDNでの説明だと、頻繁に削除・挿入を繰り返すケースでパフォーマンスが上がるんだそうで。

たいがいの場合、キーには文字列を使うのが大半の用途だと思います。DOM要素やオブジェクトもキーにできると思うけど、正直僕には使いどころが分からない。まぁ、思いつくのは コールバック(関数)なんかをためておく用途にするぐらい。それでも、そういう時は Map よりSetを使うし。。。

でも特にブラウザ上でDOMとか扱っていると、やっぱりプレーンなオブジェクトの方がコーディングが楽な時もある。ので、Map.prototype空間にオレオレMap拡張メソッドを追加して使うことになってくる。

※2020/04/02 ちょっと追記した。

Map.prototype.toPlainObject

たぶん誰もが書いてる・・・と思う、文字通り、文字列をキーにしたMapをオブジェクトに変換する。
最新のブラウザとかだと、Object.fromEntries とかいう Object.entriesの逆動作を行う関数が実装されているので↓は不要なのかも。

Map.prototype.toPlainObject = function()
{
  var rv = {};
  this.forEach(function(v,k) { 
    if(typeof k === 'string')
      rv[k] = v;
  });
  return rv;
};
// もしくはもっと簡単に・・・
Map.prototype.toPlainObject = function()
{
  return Object.fromEntries(this);
};

Map.from

オブジェクトからMapへの変換は・・・↓でいいのかな? Object.entries は比較的新しめのブラウザしか対応してなくない?

Map.from = function(o)
{
  return new Map(Object.entries(o));
};

Map.prototype.stringify

JSON.stringify のもろパクリですね。toString をオーバーライドすればいいんでしょうけど、そこまでするのは止めましょう。
主に localStorage/SessionStorage へ格納するときに使う。

Map.prototype.stringify = function()
{
  return JSON.stringify(this.toPlainObject());
};

Map.parse

これも JSON.parse のパクリ。JSONのパクリというか、文字列を直接parseするのではなく、一旦オブジェクトにJSON.parseで変換して Map に変換します💦

Map.parse = function(str)
{
  return new Map(Object.entries(JSON.parse(str)));
};

Map.prototype.numIncr/Map.prototype.numDecr

オブジェクトだと、普通にobj.counter++ とか、obj.counter += 10 とかできますよね。。。。
Mapだと一旦 getで取得してsetで更新しないといけません。JavaScriptは演算子を定義もしくはオーバーロードできませんよねぇ。。。。
演算子のオーバーロードは混乱の元になるので極力やっちゃいけない、ってC++の時言われてたな・・・。今もそうなのかなぁ。。。

Map.prototype.numIncr = function(key,delta)
{
  if(typeof delta !== 'number' || delta == 0)
    delta = 1;

  var value = this.get(key);
  if(typeof value === 'number')
  {
    value += delta;
    this.set(key,value);
  } 
  return this;
};
Map.prototype.numDecr = function(key,delta)
{
  if(typeof delta !== 'number' || delta == 0)
    delta = 1;

  return this.numIncr(key,-1 * delta);
};

なんか、Mapの良さ(キーはなんでもOK)を殺してしまうようなものばかりだな。。。キーをstringに限定するようなものあればな~・・・とは思いますが、型が強制されない言語だと難しい。

ざっとよく使うものを列挙しました。自分がコピペできるように💦
ここまで書いてて、気づいたのは・・・var使いすぎ問題! ついつい癖で var って書いてしまうんす。
ラムダ式もイマイチ好きになれない記法だったりします。 C#だと当たり前のよう書くんですけどね。。。好き嫌いというより単に癖なのかも。

ウェブブラウザ上のJavaScriptでExcelファイルをゴニョゴニョしたい

2022年6月13日 修正。追記を削除。FileReaderを使用したコードを削除。代わりに Blob.arrayBuffer()メソッドを使用したコートに変更しました。


2021年10月21日 追記 FileReaderを使わず、Blob.arrayBufer()を使用したコードを追記しました。


特に需要はないと思いますが、極たま~~~にウェブでエクセルファイルを扱うことがあります。
なんつっても、世の中の文書フォーマットは、マイクロソフトのエクセル(Excel)がデファクトスタンダードです💦
これはもうどうにもなりません。CSVで、つっても、エクセルファイルをよこしやがります。

まぁ、やっぱり業務システムにはエクセルは欠かせません、というか、これなしには、日本は動きません。日本の企業とか国、地方公共団体は、エクセルで動いているんです。これはもう動かしようのない事実であり当分の間は変わりませんし、変化の兆しも見えません。

しょうがない。

と、開発者の方が思ったかどうかわかりませんが、ブラウザのJavaScriptでエクセルファイルをパースして編集して、出力してくれる ライブラリがあるんですね。サーバーサイドのNode.jsでも使えます、というかそっちがメインのライブラリなのかも。

一般的にMS-Officeをインストールしたパソコンにはおまけ?として、EXCELのオートメーションが使えるようになってます。あくまでOfficeを買えば!の話ですが。
Windows Scripting HostなどからVBScriptやJScriptを使ってカンタンにエクセルファイルをアーダコーダできます。

・・・が、今回はこういう噺ではありません。
一般的なブラウザ上で、エクセルファイルをアーダコーダできるライブラリがあったんです。需要がなかったので今まで知らなかった!

SheetJS Spreadsheets simplified

で、ググったりしていろいろ調べると、意外にカンタンに使えちゃいますね。ただし、javascriptの blobとかFileReaderとかArrayBufferとかUint8Arrayとか・・・そういうちょっとややこしめの知識が必要です。

昔と違ってブラウザでローカルファイルとか普通に扱えます。ですが、その時は必ず、上記のFile/Blob/FileReader/ArrayBuffer/TypedArrayとかが絡んできます。
FileとBlobの関係、ArrayBufferとTypedArray(Uint8Arrayとか)の関係、さらにはFileReaderとFile/Blobの関係。このあたりは鬼門です。なんでこんなめんどくさいんだよ!っていつも思います。

MDNとかのリファレンスを読むのが手っ取り早いのですが・・・とりあえず、MDNのサイトでは、こういう場合は、こうする、という「お約束」の手順が書かれているので、まずそれを丸覚えするのがいいと思います。公文式です(笑) 理屈は後から学べばいいんです。ただ、ググってブログ記事を参考にするのは結局は理解するのが遅くなってしまうので、リファレンスとサンプルを読んで、書いて、試してみたほうがいいと思ってます。

※ たぶんIEでは動かないと思う。試してないけど。IEは既にMSも認めたオワコンなんで、どーでもいい。

下のデモ(テストコード)

さて、HTMLファイルをサクッと書きます。(Ryzenの価格表コピペしました。)

JSライブラリは適当にCDNから引っ張ってきましょう。僕は jQuery好き好き人間なので、jQueryを使用します。すみません。
INPUT[type=file]タグでローカルファイルの口としましょう。ドラッグ&ドロップを仕込んでもいいのですが、コードをカンタンにするため、普通のファイル選択にしました。ここでローカルファイルを選んでjavascriptコードに放り込みます。

で、次に実際の処理を書いていきます。まず、基本。INPUT[type=file]のonchangeイベントハンドラを起点にしています。(1311行目付近)

ローカルファイルを読み込んでゴニョゴニョするときは、必ずFileReaderのインスタンスを作って、onloadイベントで処理を行います。(18行目付近)
下記例では、FileReader.readAsArrayBuffer() していますが、単純に Data URIが必要であれば FileReader.readAsDataUrl() を使用します。
ローカルの画像ファイルを読み込んで表示するときは、readAsDataUrlメソッドを使いますよねぇ。
ちなみにreadAsArrayBufferメソッドを使うと、onloadイベントハンドラ内で ev.target.result によってArrayBufferオブジェクトを得ることができますが、

Internet Explorerが今月中(2022年6月現在)に抹殺される。そして、FileReaderを使うやり方は、もう時代遅れなので、Blob.arrayBuffer()メソッドとasync/await構文を使ったものにしましょう。

直接このArrayBufferオブジェクトにアクセスすることができません。必ず、TypedArray・・・たとえば、Uint8Arrayなどのオブジェクトのインスタンスからアクセスします。めんどくさいですねぇ。

FileReader.onload内で、ev.target.result を そのまま Uint8Arrayコンストラクタに渡して、ArrayBufferへアクセスするための Uint8Arrayオブジェクトを作り(21行目付近)、それを XLSX.readメソッドに渡します。ただそれだけで、エクセルファイルをパースしてくれます。あとは、XLSX.utils オブジェクトのメソッドをコールしていけば、だいたいのことはできると思います。
CSVデータが欲しければ、XLSX.utils.sheet_to_csv, JSONデータが欲しければ XLSX.utils.sheet_to_json、シートを増やしたければ、XLSX.utils.append_sheet、他にも javascript配列をシートに、DOM TABLE要素をシートに・・・とか対応するメソッドがあるようです。この辺のドキュメントはgithubをたよりに試行錯誤するしかないのかな。。。

エクセルファイルにシートを追加して、そのエクセルファイルをダウンロードする、これだけのことをクライアント内(ブラウザ内)で完結することができてしまいます。
ローカル内でサーバーを立てる必要もありません。上記二つのHTMLとJSを任意のフォルダに適当な名前で保存して、file://スキームで試すことも可能です。

(1) HTMLファイル ローカルで開いたところ。

(2) エクセルを選択すると、ダウンロードリンクが追加されます。

(3) 元のエクセルはいつもダミーで使わせてもらってる疑似会社情報のエクセルファイル
( http://hogehoge.tk/personal/ )

(4) HTMLのテーブルデータをエクセルシートにぶっこんでくれます。
ただしセル書式は全部吹っ飛びます。

今回は、エクセルシートを追加してみましたけど、セルの属性とかは全部ぶっとんでしまいました💦
が、単にJSONやCSVが取れればいい、というのが大半の需要かと思いますので問題はないでしょう。

僕は エクセルファイルをサーバー側で変換するのではなく、クライアントで一旦CSVに変換してから、サーバーにアップロードして、処理を行う用途に使用しました。サーバーでエクセルファイルを処理すると重くなるんで・・・。
エクセルを読むだけなら、カンタンにできるので、本当にありがたいライブラリです。

ただ一点、ちゃんとしたリファレンスドキュメントがありません。。。これはPro版を買えってことなのかなぁ。。。Community版はApache License 2.0なんで、「おまえら、ソース読んで、自分でなんとかしろよ」ってことなんでしょうね。

hasOwnPropertyがない

Internet Explorer 8でチェックしてたら、window.hasOwnProperty()のところでエラーが発生。あれ?

自分の無知が恥ずかしい。。。

MSDNドキュメントをチェックしてみると、なんかドキュメントがええかげん。.hasOwnPropertyの説明では確かにIE8はサポートされない、と書いてあるんだけど・・・javascriptのバージョン情報のところを見ると、hasOwnPropertyは’Y’になっとる。

だけど、Object.hasOwnProperty はエラーは起こらず。どゆこと?

結局、IE8の時だけ、下記のようにする。

// これってもしかして、常識なの???(^^;;;
var undefined;
if(window.hasOwnProperty === undefined)
{
  window.hasOwnProperty = function(property_name)
    {
       return Object.prototype.hasOwnProperty.call(window,property_name); 
    };
}

なんか、釈然としない。はやくIE8消えてくれ。つか、会社のPC、いいかげん、XPから7にバージョンアップさせてほしい・・・自分で金出すから。

packer(.NET版)を勝手に改造

これ、すごい。こんなスマートなビルの壊し方があるんすね。。。ビル爆破より地味だけど、なんかお金かかりそう。
http://www.bbc.co.uk/news/world-asia-21406927

それはともかく。

javascriptコードを圧縮するのに packer (http://dean.edwards.name/download/#packer) の.NET版をよく使っています。
が、.NET版は(たぶん)メンテされておらず?ソースコードも .NET Framework 1.0時代のものなので、見栄えがかなり悪いし、テキストボックスの入力が32KBに制限されていたり、とちょいと不満がくすぶっていました。
最近Javascriptコードを書くことが多くなって、頻繁に使い出すと、どうもこのUI自体が(僕にとっては)使いにくい。

で、あまり見た目を触らずボタン類の配置、ビジュアルスタイルの適用などを含めて改造。
自分用の書庫の意味もかねているので、ここにアップロード。

左がオリジナル。右がUI改造版
jspacker myjspacker

改造点は、

  • ボタン配置・レイアウトを変更した。
  • ビジュアルスタイルを適用するようにした。
  • ラベルを日本語化した。.configファイルでラベル編集可能。
  • テキストボックスの32KB制限を外した。
  • ファイルからの読込(Loadボタン)時に文字コードを判別するようにした。
    (文字判定にInternet Explorerのモジュールを使っているのでIEを削除している方(いないと思うけど)の環境では文字判定できません

ユーザーインターフェイスの部分(Visual C#のIDE上で編集できる部分)のみ修正したのでpacker本体のアルゴリズムには一切タッチせず。packer自体のバージョンは上がっていると思うので、たぶん古いアルゴリズムのままのはず。分からんけど。

プロジェクトのプラットフォームを.NET Framework 3.5にして、フォームを定義しているソースファイルでIDE機能のデザイナーで編集される部分のコードを分離( partial class化)してます。

<< Download from here if you need.>> もし必要ならダウンロードはこちら
(改造後のVisual C# 2008のプロジェクトソースも同梱してます。)
(なんか、chromeだと、危険だ!とか出てダウンロードできませんが、別になんも仕込んではいないです。)

使い方は・・・説明しなくても・・・(^^;;;
ラベルを英語にしたい場合は、Javascript packer.exe.config ファイルを開いて、

&lt;setting name=&quot;Lang&quot; serializeAs=&quot;String&quot;&gt;
&lt;value&gt;ja&lt;/value&gt;
&lt;/setting&gt;

の中の、ja の部分を ja以外、たとえば、en とかにしてください。
ラベルを修正したい場合は、configファイルの該当箇所を修正してください。ただ、ボタン幅は固定なので長さによってははみ出るかも?

でわでわ。

ID値がグローバル変数に自動追加される

超初歩的なことに、はまってしまった。自分自身の備忘録として残しておこう。

自分で組んだjavascriptコードが chrome で動いたり動かなかったりしたことがきっかけだった。
そのスクリプトは、ブラウザ判定をしてて、chrome、いえ、webkit の検出に以下のようなコードを使用していた。
これ自体は、グーグル検索で辿り着いた、W3G(world wide web guide)というサイトに掲載されていたものを丸々拝借させてもらいました。

// chrome/safari等のオブジェクトを使った判別。
(function(undefined)
{
  var isWebkit = !document.uniqueID &amp;&amp; !window.opera &amp;&amp; !window.sidebar &amp;&amp; window.localStorage &amp;&amp; window.orientation === undefined;
})();

さて、ここで、chromeでアクセスしているにもかかわらず、HTMLファイルによってはtrueになったりfalseになったりして ????という状態で、falseと判定されるHTMLを開いてブラウザのコンソールで、調べていったら、 !window.sidebarfalseになることが判明。

これでピンときた(思い出した)。

あ!、HTMLファイルのある要素(DIVタグ)に id=”sidebar” って属性をつけてるわ・・・。

とほほ。ご存じのように、タグのid属性に指定した値は、グローバル変数に(厳密に言うと、windowオブジェクト)に追加されるんだった・・・orz

いや、確かに昔、Internet Explorer が中心だったころ、よくこれでラクしてたんだよな・・・最近は、document.getElementByIdというDOMメソッドを使用することがほとんどだったので忘れてた。でもIEならともかく・・・webkitでこれに直面するとわおもわなんだ。

結局、元になるHTMLファイルから、sidebar という名のid属性値を、違う値に全部変更することで一件落着。

これから、タグにid属性を含めるときは、必ずハイフンを使用した値にするようにしよう・・・と固く誓うのであった・・・。
というより、こんなIEの独自仕様は端っからwebkitから消し去ってくれればいいのに・・・。