Signal時代から、イマドキのElmに移行中である話。

2014年かな?そのぐらいから、Elmで開発してきたプロダクトをイマドキのElmに移行した(してる途中)なんで、その話をします。わりとポエムです。

なんというか、本来は、12/15日にあげる予定だったんですが、12/7を開けて頂いたので、(そもそもわざわざ空けて頂くほどの内容じゃないと思うので)、大変なんか悪い気がします...

そんなこんなで、とりあえず投稿します。

つくっているものと開発経緯

実は、2012年から、Direct Manipulationと、Visual Programmingに関して、僕は関心がありまして、ずーっと開発してきたものがあります。このプロダクトは非公開ですが、今後公開する予定があります。(もう1年ぐらい、伸びてるんですがね。)

さて、開発言語としては、最初は、Vanilla JS(https://qiita.com/nobkz/items/9c79f019f93335ee5140) でした。そんで、Elmに書き直して、なんかちょっと良くなかったので、また、Vanilla JSにもどって、今は、また、Elmに移行している途中でしたが、今の時点で記事にしようと思います。せっかくAdvent Calendarの季節なので、そろそろ一旦まとめようかと。

んで、いろいろな技術をつめこんでいて、言語を作成するんで、ジェスチャーをパーサで書いたりとか、ルーティングについて自分で実装したり(その頃そもそもSPAって概念がなく、そういうのがなかった)、いろいろありました。

この記事について、

あくまで、この記事はElmに関する記事なので、Elmに焦点を当てます。メインは、Signalです。

Signalについて。

https://qiita.com/nobkz/items/a9ae4a25be3f7eb21311

に書いてますが、FRPの中心的な考え型でした。当時は、関数型言語でこうやってGUIを実装していけばいいのかぁという、感じがありました。

用は、Signalを足したり引いたり、似たり焼いたりして、Signal同士や、関数を組織しながらプログラミングしてきました。とてもデータフロー的な考え方に近いものだと思っていました。

ある程度成功していたと思います。

しかしながら、問題がありました、個人的な考えでは、当時のElmには、アーキテクチャに関する問題と、非同期に関する問題がありました。

TaskやMailboxは難しかった。そしてコードも難しくなった。

Signalは正直そこまで、難しい概念ではないと思います。しかしながら、問題だったのは、TaskやMailboxだと思います。このヘンテコな仕組みが、Elmのコードを難しくしていたのではないかと思います。

しかしながら、今のElmはなくなりました。どこに行ったのでしょうか?

イマのElm

そんなこんなしている間に、ElmはFRPを捨てました。FRPとおさらばしました。

そして、SignalやTaskは、Elmのフレームワークとして、ElmのPlatformに隠蔽してしまいました。

SignalからElmへ移行

ジェスチャーの移行

僕は最初に関心、ジェスチャーの実装をどうしようか?って問題でした、ジェスチャーはSignalを利用して、判定していました。

gesture : Signal GestureState

余談ですがこれは実は、Controllerの状態なはずです。本来であれば、ジェスチャー状態も分離したいのですが、Elmでは、Modelとされているのでにょもるんですが、しかないですね。素直にElmのModelというTypeに階層を置き、Controllerと本来のModelに分けました。そもそも、MVCモデルってのは、MとVの分離を言うことが多いのですが、MとCに関する状態の境界あって、そのところが、ぜーんぶStateとされて大変にょもるのですが、しかたないですね。

もどりますが、このようなControllerに関する、ものはどこに行ったかといえば、subscriptionでした。

subscriptions : Model -> Sub Msg

僕は、そもそもsubscriptionの状態に関して、Gestureの状態を分離したかったので、

subscriptions model = 
  Sub.batch [ 
    gestureUpdate (getGesture model)
  ....
   ]

gestureUpdate : GestureState -> Sug Msg

みたいな感じで、実装しました。subscriptionは、個人的には、ある意味Controllerのようなものでした。

SubscriptionとSignal

Elmの作者のコメントとかは見てはいないのですが、ぼんやりelm-coreの実装とか読むと、なるほど、Subscriptionのおかげで、Singalはいらなくなったんだなと思いました。さらに、websocketなどがやりやくなったんだろうなと思いました。

確かに学習コストは下がったかのように思いましたが、実はSubscriptionが本質的にはSignalの役割なんじゃないかと。

Commandについては、また今度考察しておくかな。

パーサーについて

Elmでパーサーも書いていました。

パーサーについては全く実装が変わりませんでした。そういえば、ElmはDSLと言う人がいましたが、汎用プログラミング言語です。もし、DSLだと言うなら、パーサーなんぞ書けない筈だと思います。

フロントエンドDSLをつくるなら、たぶん、汎用言語としての機能が余計で学習コストになっていたと思います。

WebsocketやHttp requestについて

これも今のところ上手く行っています。CommandやSubscriptionにうまーくまとまったなぁという感想です。

設計の話

Elm Platformはフレームワークですが、フレームワークとして、設計がすごく変わるかといえば、実はそこまで変わらないなぁというのが僕の感想です。

しかしながら、個人的にはGUIの設計のひとつでしかないというのも感想にはあります。Elmに合わないGUIの設計をすると大変かもしれません。PAC的なアーキテクチャをとると大変かもね。

しかし、実装技術としては大きく変わったなぁと思います。以上。