case等のビジネスロジックを前面に押し出すように、アプリケーションを書くことに挑戦してみます。re-frame等のフレームワークを使わず、clojure.core.asyncに頑張ってもらいます。LibraryやReagentは普通に使います。Architectureの影響を受けています。今回書くのは、下のようなタグを編集する機能です。一つ一つ実装してみます。Entities概念の定義を置く場所をentitiesとしています。タグタグやタグの編集等、今回のアプリケーションで取り扱う概念を定義します。タグのIDと名前で表現します。全部のタグと、付与されているタグにより、編集状態を表します。追加するタグの名前で編集状態を表します。[name])Transaction現在の状態を取得、現在の状態を更新するプロトコルを、Transactionと呼ぶことにします。アプリケーションが状態を取得したり状態を更新したりするときは、このプロトコルを経由します。f]))例えば、以下のようなStateを考えます。[counts])Stateのcountsをインクリメントするコードは下ようになります。これにより、非同期でStateが更新されます。diff))))短く書くと下のようになります。diff)))なお、一貫性をもったStateをどうやって保持し続けるかは、Transaction実装時の関心です。したがって、Transactionを利用する側はこれを考えないようにします。Requestを投げる場所です。(実装はしません)ここはライブラリが必要になるでしょう。すべてのTagをmapとして取得します。keyはtag-idで、valueはTagです。取得した後はそれを引数にcallbackを実行します。nameを名前としてTagを追加します。追加後は無引数でcallbackを実行します。付与されたTagをリストとして取得します。付与されたTagのリストを保存します。Casesアプリケーションのコードを書く場所はuse_casesとしています。api等を使って、アプリケーションのアルゴリズムを書く場所です。アプリケーションのアルゴリズムは、基本的に、状態を引数にとって新しい状態を生成する関数を生成します。現在のStateの、new-tag-editとattached-tag-editを変更する。tags)))))Componentscomponentを置きます。Reagentをフルに使いますが、詳細は省略。casesを見れるコンテナコンポーネントや、純粋にどう見せるかだけに関心を持つプレゼンテーショナルコンポーネントに分けるとよさそうです。mainmainはアプリケーションの起点となるところです。Transactionの生成、ページとTransactionの対応付け等を行います。今回の場合、ページが関わるStateはuse_cases/Stateの一つだけです。一般にページは複数のStateからなりえます。すると、Stateに対応するTransactionも複数必要です。ここで、ページで扱うTransactionをまとめた概念をStoreと呼ぶことにします。storeはTransactionの集まりです。今回のstoreはただ一つのTransactionを持てば十分です。Stateが更新されるように設定します。upLoginユーザーは見つかりませんでした。