ToKyoto.jsでScala.jsについてLTしてきました。

自分の発表について

speakerdeck.com

もう3日前のことになりますが、ToKyoto.jsでLTしてきました。Scala.jsの話です。スライドにあるし、このブログでも何度か取り上げていますが Scala.js 普通に実用性あります。とはいえ「実用性がある」と「使うべき」の間には高い壁がそびえているわけですが……。

ちょっと補足的な話をしておくと、ReduxやVuexが提供する状態管理パターンのよさはいくつかあって、

  • Single source of truth が守られる
  • 参照系と更新系が強制的に分離させられる
  • 以上の二点により、プレゼンテーション上でのデータの分割構造とロジック上のデータの分割構造が分離される
    • ヘッダーで使う情報とメインコンテンツで使う情報が互いに関連するみたいなやつが、おなじデータソース見るの簡単とかそういうこと
  • 自分でデータの変更をobserveしなくていい
  • 状態がピュアなJS objectで表されている

というのがわたしの認識するメリットです。そのうち、最後のメリットに関しては「SSRするからInitialStateをサーバーサイドでバーっとjsonに吐き出したい」とかそういうときにとくに効いてくるもの(参考: You Might Not Need Redux – Dan Abramov – Medium )という感じがある。

逆に言うと、そういう制約がないのであれば、「ふつうのLayered Architecture」をやりながら、Single source of truthを守り、コマンドとクエリを分離してやれば、ReduxやVuexが提供してくれるメリットをある程度教授しつつも、他のGUIプラットフォームで得たGUIアプリケーション設計の知見を活かすことができると考えています(データ変更監視するのはがんばるしかない)。

実際、Scala.jsに移植されたNekogataDrumSequencerBackLoggerはRepositoryがSingle source of truthになっていて(というかモデル層以下で状態を持つものはすべてRepositoryに寄せて、他を全てImmutableで書いている)、これはそれなりにワークしているなあという実感があります。

逆に言うと、ReduxやVuex的な「状態のスナップショットがJSONで取れちゃう」みたいなことがしたいときにはもう少し工夫する必要がありそうですね。

で、こういう「Layered Architectureでがんばる」みたいなやつはJSだとちょっとむずかしくて、いや、むずかしいっていうか、むずかしくはないんだけど、Scalaみたいないろんな言語サポートが欲しくなるな〜みたいなのがあって、そこで「Scala.jsありかもよ」っていう文脈ですね。

ほかのひとの発表について

@amagitakayosi さんのやつがとくにおもしろかったです。とくにMIDI信号をがんばってGPUに送るときの工夫の話が「うおー、おもしれ〜〜〜」って感じで、NekogataDrumSequencerもMIDIコン対応したくなりました(GPUには送る必要ないけど)。

その他

仕事ではJS書きまくってるんですけど、コミュニティ的にはいままであまりJS界隈に顔を出したことがなくて、JSコミュニティはアウェイな感じだったんですけど、twitterやブログで一方的に知ってて「話してみたいな〜」って思ってたひとと話してみたら先方もわたしのこと知っててくれて、その上で有意義なお話をたくさんさせてもらえてめっちゃよかったです。次はScalaっていうアウェイなコミュニティに顔を出してみたいなと思うのでScalaMatsuri応募するぞ!