コメントシステムの開発を進める。
コメント送信時に送信したコメントの表示されるページまで自動で遷移する機構を加えた。フロントエンドがだいぶ複雑になってきており、責任の分割が難しい。正確には、どこのモジュールにどういう責任を与えるかという切り分けの基準作りが難しい。
とりあえず画面全体の状態に関わりうるものは下手にコンポーネントの責任に置かず、全体で共有されたPiniaのストアに管理させるようにしてみている。明らかに単一のコンポーネントの責任でしかないものだけをコンポーネントに管理させている。しかし、コンポーネントから画面全体の状態に関わり得るイベントが発生したときの切り分け方を決めかねている。
- コンポーネントからイベントをEmitして、上層のコンポーネントで処理を行う
- コンポーネントから直接ストアのactionを叩く
バケツリレーの回避的には後者で良いのだろうか。しかしどのコンポーネントも全体の状態に影響を与えうる感じになっていくのはグローバル変数的なアンチパターンのにおいがして怖い。
セットアップや管理者ユーザーの管理などを目的にバックエンドへCLIツールを追加しようと思ったのだが、RustのCargoにおいて複数の実行ファイルを置くやり方を調べるのにだいぶ手間取った。src/bin以下にファイルを追加すればよく、細かい設定がしたければcargo.tomlでの指定も出来るらしい。
サブの実行ファイルを作るにあたって一番調べるのに手間取ったのは、メインの実行ファイルとのモジュールの共有について。modとかuse crate::とかでモジュールを参照できない。
正しいやり方としては、まずmain.rsにmod ～～とか書いているならlib.rsに移して、さらにpub mod ～～として公開する。こうしないとサブの方からはアクセスできない。
そしてサブの実行ファイルのソースコードにおいてはuse crate::～～ではなく、use (パッケージ名)::～～という形でアクセスする。
Rustのモジュール周りの仕様がいまだに理解しきれていない。Rustの他の言語仕様は「良いC++を書くときに気を付けていること」を厳密なルール化したものという感じなので大体スッと頭に入るし納得できるのだが、モジュールはどうもC++文化とはかけ離れているし、他の今まで見たスクリプト言語などともなんか違うように見える。modとuseの使い分けみたいなあたりがどこから出てきたものなのかよく分からない。
今日摂取したコンテンツ。
https://github.com/CyberAgentGameEntertainment/UnityPerformanceTuningBible
Unityを使い倒している勢力の人間がどういう風な認知を行っているかという参考資料として面白かった。ゲームエンジン使いも結局パフォーマンスチューニングになると低レイヤに回収されるんだな。
Categories: 未分類