こんにちは。未だにロフトベッド周りの整備に時間とお金が取られているすえです。とりあえず一段落はついたので今後はなんとか休日の時間を開発に当てられそうです
さてフロントエンドの進捗報告のお時間です。
今週は直接のコードに追加や変更はありませんでしたが、フロントエンド部分の根幹の構造(の理想)を明確にする作業を行いました。
それがこちらです
一応各ブロックが何を指しているかについて解説します。
User
文字通りのユーザーです。
View
ユーザーが閲覧して操作するところです。つまりUIです。ここではUIに直接紐付いた処理(コンポーネントの状態変更など)以外は行わず、Coreから送られたデータの表示やCoreへのデータ送信に専念します。
Core
EXDeckの中核です。基本的にここでデータの処理や管理を行います。
Store
Coreで扱うデータの保管場所です。EXDeckで扱う保管する必要のあるデータはすべてここに集約されます。
Adapter
Backendとのデータのやり取りを担う部分です。
Backend
TwitterAPIと通信するバックエンドです。この部分はフロントエンドの管轄外のため省略します。
Extension
拡張機能を管理する部分です。この部分はまだ未確定なものが多く今後変更になる可能性が高いです。
そしてこの各ブロックは基本的に独立しているため、例えばViewを差し替えたとしてもCoreを全面改修する必要はありません。
……と、一応このようになっていますが、上でも述べたとおりあくまで理想であり、今後変更される可能性が高いです(特に拡張機能まわり)。
また、なんと現状のフロントエンドはこのアーキテクチャに則れていません。なんてこった
主な原因はCoreやStoreに相当する部分の状態管理がViewに相当するSolidJSのSignalという仕組みに依存してしまっているからです。
これの何が問題かというと、もしViewがSolidJSでなくなった場合にその部分を全部改修する必要が出てきてしまうことです。(既にこのフロントエンドはSvelteをやめる必要が出てきた際に作り直しを余儀なくされています。)
これを回避するには、SolidJSのSignalに代わる状態管理の仕組みを用意する必要があります。
で、探したのですがいいのが見つからなかったので作りました。Gastoreです。
既に普通に使える程度には完成しており、これをCoreやStoreに組み込む予定です。
余談ですが、このGastoreという名前はGas + Storeから来ています。GasはSolidからの連想(Solid → Liquid → Gas)です。
今回は結構長くなってしまった気がしますね。それでは