GitHubNW.js(node-webkit)でazu/pdf-markdown-annotatorというアプリを作りました。pdf-markdown-annotator簡単に書くとPDFとMarkdownエディタを横に並べてメモを書けるアプリPDFから選択範囲をエディタに引用プレビューモードから該当ページにジャンプできるMarkdownの読み書きMarkdownのプレビューという感じのシンプルなアプリです。Linuxで多分動くはずですなぜ作ったか?箇条書すると以下のような感じで作りました。動いたという感じでできました。onlyですが)以下にES5仕様の読書メモを公開してあります。viewerで動いています。NW.jsはNode.jsが動くので、require("babel/register")();という一行が初期化時に走らせて、後はES6で書いたコードが読み込み時に自動でES5に変換できます。そのためES6のコードがビルド不要で動かせます。pdf.jsはDOMをガンガンいじるライブラリなので、Reactで扱うときにどうするかはちょっとまだ迷っているので雑な作りになってます。azu/pdf-markdown-annotatorComponentで包んであるけど、包みきれてない感じPDFの表示はiframe置いただけというシンプルなもので、こんなものでも結構使えるのでpdf.jsは触って楽しい感じがします。したらイベントの仕組みがViewerに入るので、これあるとよりコンポーネントとして扱いやすくなると思います。Macは結構良さそうでしたが、やっぱりエディタ部分が何か微妙でした(シンタックスハイライトが欲しい)。いう感じで既存のものをちょこっと組み合わせてアプリが作れるようになってきたのは楽しいです。Componentと同じ名前で名前空間を作ると命名に迷いが減るので書きやすくなった感じがします。CSSを参考にしていて、MarkdownEditorというコンポーネントなら、.MarkdownEditorというクラスをつけるというシンプルなルールですね。Componentsでも使い勝手の問題やメンテされてないものがあったりします。Markdownのプレビューにreact-remarkableを使ったりしましたが、動いてなかったので修正を送ったりしてました。Componentに限らず起こりえるものなので、UIコンポーネント(DOMに追加するような何か)を提供する人はちゃんと設計する必要があると感じました。Runnerに依存しない作りにするとかそういうのと似たような話な気がします。Elementの4つのライフサイクルイベントをベースに考えた作りになっていると、React以外のコンポーネントとしても対応しやすくなるじゃないかと思います。Rocks後、DOMを<div>的な何かを追加するのだけがコンポーネントじゃなくて、今回使ったpdf.jsのwebviewerをiframeで埋め込むのも一種のコンポーネントかなと思いました。複雑なUIならiframeで扱えると意外と楽だったり、iframeなのでカプセル化しやすいです。最近だとseamless属性やsandbox属性などもあるので、制御もしやすくなってたり下手にDOM追加で頑張るより安全で見えます。Componentsさんは来そうでまだ来てないので、その辺は色々想像しながら実装に落としていくのが現状なのかと思います。タグ:nw.jsnode-webkitpdfmarkdowngithubJavaScriptCustomElementWebComponentお知らせ欄JavaScriptに関する最新情報は週一でJSer.infoを更新しています。efcl/efcl.github.ioからご意見下さい関連記事コメントを。