the north.

同人いろいろやるサークル "the north." のブログ

今日やったこと: 2018/12/08

久々にブログに書けるくらいまとまったことをやったぞ。 ここのところコミティア原稿で忙しかったり、DJ業で忙しかったり細々した進捗が多かったので書くのが億劫だった。

今日はFleurをめっちゃいじってた。 ツイッターの様子

  • [fleur] Redux devtools に対応させた diff withReduxDevTools という関数を作った。こいつにappContextを与えると、AppContext#dispatchをオーバーライドして、redux-devtoolsにdispatchやdehydrateされたStoreを送りつけるようになる。 使い方はこれを見てくれ
  • [fleur-di] ライブラリ非依存のどシンプルなDIコンテナライブラリを作った
    詳細はREADMEを見てくれ
    これは @f_subal 先生の影響を受けて作ったものだ、詳細は気になったら聞いてくれ
  • [fleur-test] fleur用のモックファクトリーライブラリ、fleur-diと組み合わせればこれでOperation層のテストはそれなりにできるようになるはず
  • [fleur / fleur-route-store-dom] 放置してたSSR対応ブランチをmaster追従させてマージした。

[fleur / fleur-route-store-dom] 放置してたSSR対応ブランチをmaster追従させてマージした

これにあわせて動作確認のためにTodoMVC(TypeScript + React)をコピーしてきてFleur(SSR)で再実装してみたんだけど、 TodoMVCのコードがTypeScript的にもReact的にもめっちゃ古くて書き直しが面倒だった… 半日くらいの時間をこやつに奪われた…つらい…
fleur-diの使い心地検証もしたいので、時間があったらAPI部分を書いてそこらへんのテストも書いてみたいが、面倒なのでしばらくやりたくない

FleurのAPIがクソ

TodoMVCの再実装してて、やっぱりFleurのAPI長ったらしくて書くのが面倒くせぇという気持ちが浮上してきた Operationと名付けたのがよくなかった感がある、今のうちならUseCaseとかにしても誰も困らないから変えようかな…

this.props.context.executeOperation

お前な。これはUseCaseに変えてもクソ長いからそもそもpropsに直接生やしたほうが良いかもしれん。 コンフリクトが怖いけど、Reduxのprops.dispatchだってみんな被せずに使ってるしな、気にするほどでもなかったかもしれない

this.props.{execOperation,getStore} なら多少マシ感がある。

operation、お前必要?問題

TodoMVCみたいなかなりシンプルなプロジェクトだと、Operation層が極薄0.02mmって感じになり書くのが億劫になる。 ComponentContext#dispatch とか生やせばOperation層をスキップしてStoreに司令を送れるが それを許した先の.executeOperation.dispatchが混在する世界は、初見に対してハードモードって感じになりそうなので 強い気持ちで「無意味そうなoperation(...)にも設計の一貫性と一覧性として必要だよ」と言っていくことにした。

context.getStore(HogeStore).getXXX()

connectToStoresのお前だよお前。Redux触ってる立場になるとクソ長い。 stores.hoge.getXXX みたいなやつになりたい。でもAPIがBreaking Change過ぎてつらい。

operationの引数、型チェックは聞くがエディタ補完が効かないし引数渡しがオブジェクトなのがつらい

第二引数に受け取るオブジェクトの型定義がキレそうなほど面倒くさい これになってくれ。実際できるかは知らん。

export const hogeOp = operation(context => (arg: string, arg2: string) => {
  context.dispatch(hogeAction, {arg, arg2})
})

context.execOperation(hogeOp('arg1', 'arg2'))

// 今は
export const hogeOp = operation((context, payload: { arg: string, arg2: string }) => {
  context.dispatch(hogeAction, payload)
})

現行はTypeScriptの以前の型定義の制約上、関数の引数列の型を推論できなかったから1オブジェクトを受け取る形式にしたけど、 もう可変長引数の型を推論できるようになったし、Payloadを受け取るか引数を受け取るかは利用者が任意に選べばええじゃろ。 とりあえずオレはオブジェクトをぶっ壊して展開するやつを書き飽きたぞ… フレームワークとしてはどっちかに固めたいところだが。


というのが本日得た課題感でした。おしまい。

今日やったこと: 2018/09/28

  • [Delir] Expression APIの整理
  • 一日ゲームして遊んでた

Expression APIの整理

DelirのエクスプレッションとP5.js クリップ内で使えるAPIを整理した。以前はctx.timeと書いていたコードがthisComp.timeなどになった。(短縮化するつもりだったのにこの記事書いてみて全く短縮されてないことに気づいた… あかん…)

合わせて、P5.jsクリップ内でdelir.ctx.timeとなっていたものもthisComp.timeなど、エクスプレッションに合わせる形にした。

今日やったこと: 2018/09/27

  • [fleur] SSR対応検証コードを書いた

fleurのSSR対応

今更になってようやく実際にブラウザを使ったSSR検証コードを書いたけど、RouteStoreがかなりガバガバだった。 今日だけでとりあえずサーバーと差のないレンダリングがクライアントでもできるようになった、明日余裕があったらRouter周りを書くかもしれない。 SSR Supporting by ra-gg · Pull Request #2 · ra-gg/fleur · GitHub

あとお仕事でreact-routerを使ってるんだけど、ページアクセス時の初期APIリクエストのことを全く考えてない設計になっててオエーッ!になった… つらい…

今日やったこと: 2018/09/26

  • [Delir] オフラインモード対応

オフラインモード対応

Delirでのレンダリング出力時にrequestAnimationFrameとフレームレートによるスロットリングを利用していて、どんなに早く出力できても動画の再生時間と同じ時間がかかっていた問題を直した。 ここでrequestAnimationFrameを使わなくなったことによって、実はDelirがバックグラウンドにいるとBlinkによってレンダリングキューが停止されてレンダリングが進まなくなっていた問題も解消した。

今日やったこと: 2018/09/24

RenderContextのリファクタリング

Delirのエンジン内には、進行中のレンダリングに関する情報(コンポジションのサイズとか、レンダリング中のフレーム番号とか)を抱えるRenderContextというものがあるんだけど これが実はレンダリングのステップによって実は4種類くらい存在する。

その4種類の内、2種類はRenderContextPreRenderContextという形で表現されていたが、もう2種類はnullableプロパティが埋まってるかどうかで区別されていた。 この構造によって、ある状況で埋められるべきプロパティが埋められているかどうかが型検査時には保証できず、ランタイムにお祈りを捧げるしかなかった。

そんなのが辛いと嘆いていたら @orekyuu から助言を頂いた。

まず全てのContextで必ず存在するプロパティをまとめてRenderContextBaseというクラスに集約し、全ての派生型はこのクラスに実装された#to**RenderContextメソッドを経由するようにした。 これにより、そのメソッドコールの型検査を通過していれば、埋められるべきプロパティが埋められていることを確約できるようになり、安心して利用できるようになった。

詳しくはこのコミットを見てほしい

Refactor engine by ra-gg · Pull Request #181 · ra-gg/Delir · GitHub

***RenderTaskのリファクタリング

昨日、Parameter Reference APIをマージしたけど、キーフレーム周りのコードが重複しまくっていてつらかったのでリファクタリングした。 計算処理自体は関数化されていてDRYなんだけど、それらをクリップ・エフェクトのキーフレームに適用する部分が重複してた。

とりあえずキーフレームの処理に関しては同一のものとして扱うべきなので、ParameterTableというクラスに切り出した。 エクスプレッションの適用処理もインターフェース自体はクリップとエフェクトで違いがなかったのでこのクラスに詰めてとりあえず重複コードをある程度減らせた。

ここが切り出されたクラス

https://github.com/ra-gg/Delir/pull/181/commits/9f3eb186cd60ad70b21aded7b42737407d735cda#diff-69acab044fde8ac299c9e66d52c2806d

そしてこれが切り出される前の重複コード

ParametersTable クラスができたことで、キーフレームの探索処理もこのクラスに集約できるようになっていい感じになった。エクスプレッションの適用はまだ地獄味があるけど。

今日やったこと: 2018/09/23

  • @ragg/fleur-test (fleurのテストユーティリティライブラリ)を書き始めた
  • [Delir] LabelInput Componentが変換確定のためにEnterを押したときに「入力完了」になるのを直した
  • [Delir] Parameter Reference Expression API対応
  • [Delir] MonacoEditorがフォーカス時にフリーズするやつを直した
  • [Delir] エンジン周りのリファクタリングについて考え始めたが、なにもわからない… 俺には… なにもわからない…

LabelInput Componentの話

Delirには入力してるときにInputっぽくなって、そうでないときにはただのテキストっぽく見えるLabelInputというコンポーネントがあるんだが、こいつには、Enterを押すと「入力確定」としてテキストっぽい見た目に戻って内容を通知する処理がある。

そいつがEnterキーを押したときに「変換確定」のEnterでも反応してしまって面倒なのでどうしたもんかと調べたら どうやらKeyboardEvent.isComposingというプロパティで「変換中かどうか」が見れるらしい。

KeyboardEvent.isComposing - Web APIs | MDN

こいつは、「変換確定時のEnter」のときにはtrueになっているので、以下のような条件式にしたやったら変換確定のEnterを入力確定扱いしなくなった。

private onKeyDown = (e: React.KeyboardEvent<HTMLInputElement>) =>
{
    if (e.key === 'Enter' && !(e.nativeEvent as any).isComposing) {
        this.props.onChange(e.curentTarget.value)
    }
}

as anyとしてるのは、まあそういうことだ…(TypeScriptのDOMの型定義にはないプロパティ…)

Parameter Reference ExpressionAPIの話

エクスプレッションやp5.jsスケッチから、クリップ内のパラメータとかエフェクトのパラメータを参照できるようにする機能を作ってる。

先日のリリースでp5.jsをクリップとして扱えるようになったが、まだジェネラティブな映像しか書けない。 p5.js というか、クリエイティブプログラミング全般の話で、プログラムは「法則的 な動き」には強いが「非法則的な動き」に弱い。

この機能が入ると、非法則的な部分はキーフレームで入力して、それを踏まえた法則的な動きをスクリプトでかけるようになって 作れる映像が格段に増えると考えてる。

どういうAPIになるかはまあそのうちドキュメントに書かれるので待っててくれ。

MonacoEditorのフリーズの話

DelirではエクスプレッションとかのコードエディタにMonacoを使ってるんだけど、このエディタにフォーカスするたびに謎のWorkerの大量リロード祭りが始まって一瞬フリーズする現象が起きてた。 エディタにフォーカスした時に使用する型定義ライブラリを切り替える処理が走っていたことが原因ExpressionEditor.tsxで、同じライブラリセットに切り替えたときは切り替え処理をしないことで対応した。

そもそもなんでライブラリの切り替えが必要かというと、現時点でMonacoは「インスタンスごとに利用する型定義ライブラリを設定する」ことができないため、エディターにフォーカスされたときに、そのエディタに応じてライブラリセットの切り替えを行ってるという経緯がある。(ここ)つらい。

lov をリリースしました。

f:id:ragg:20180608013827p:plain

相変わらずごちうさにハマってます。ラグです。

先ほど、twitter#ごちうさ版深夜の真剣お絵描き60分一本勝負 ハッシュタグに投稿されたイラストに溺れられるサイト lov をリリースしました。

Eを探す日常のお供に、どうぞよしなに。

lov - http://lov.ragg.me/
Ragg-/lov on GitHub

サポートは @_ragg_で受け付けてます。

続きを読む