2016-11-27 29 views
0

Om.nextの入力フィールドのデータを使って状態を更新する際に問題があります。Om.nextの入れ子状態の更新

Om.nextの読み込み状態は、クエリとクエリによって解決され、コンポーネントがコンテキストに依存しないフェッチ状態を実装できるようになります。これは、コンポーネントが状態アトムの構造を知る必要がないことを意味します。それに直接関連する状態原子のローカルスニペットを理解しなければならない。

残念ながら、私はこれを反対の方向に行う方法、つまり状態原子のコンポーネントの位置と結合しないようにユーザーとコンポーネントのやり取りに基づいて状態を変更する方法を特定できませんでした。

ウェブ上のほとんどの例は、ルートから開始して、状態アトム内の特定のパスを変更するmutate関数を持っています。

(defonce app-state (atom {:badge {:credentials {:user "" :password ""}}})) 

は、だから今、私はコンポーネントをレンダリングするために行く:

Object 
(render [this] 
(dom/div nil 
     (dom/input #js {:onChange ??? 
         :value {:user value}}) 
     (dom/input #js {:onChange ???? 
         :value {:password value}}))) 

それはむしろ、粗例だが、ときに、ユーザーの種類どのように私はそれがパスの下に保存されているという事実に結合せず、状態を更新します[:badge :credentials]

読み込みはクエリによってスコープされますが、突然変異はそうではありません。これは単純な人工的な例ですが、(符号化時に)未知の形状でネストされたツリーをレンダリングして更新しようとすると悪化します。

答えて

0

あなた:onChangeは、あなたの突然変異のいずれかを呼び出すことができます:

:onChange (fn [_] (om/transact! this `[(app/set-name { :person 1 :name ~n })])) 

以外のパラメータ、および変異がから呼び出された場所から、何のカップリングはありません - 突然変異は、名前以外の何ものでもない - ここapp/set-name 。もちろん、突然変異は実施されなければならない。ここにある:

(defmethod m/mutate 'app/set-name 
    [{:keys [state] :as env} key {:keys [person name] :as params}] 
    {:action (fn [] 
    (swap! state update-in [:people/by-id person] assoc :person/name name))}) 

突然変異コード自体がデータの構造、形状はツリーではないことを意味する正規化されたアプリケーション状態を扱うであろう。

この例は、から取られました:http://localhost:3449/#!/untangled_devguide.G_Mutation

関連する問題