Fork me on GitHub

good question @josh.freckleton. There are libraries to do that sort of thing but here's an approach you might find useful:


basically it's a mashup of how reagent typically does input updating and dispatching via re-frame.


(defn password-valid? [password-str] (> (count password-str) 5))
(defn email-valid? [email-str] (and email-str (re-matches #".*@.*" email-str)))

(defn validate [{:keys [password email] :as login-form}]
  (boolean (and (email-valid? email)
                (password-valid? password))))

(defn fake-login-view []
  (let [loading?   (subscribe [:loading?])
        login-form (subscribe [:login-form])
        email      (reaction (:email      @login-form))
        password   (reaction (:password   @login-form))]
    (fn []
       [:form#login-form {:class (str "ui large form" (when @loading? " loading"))
                          :on-submit (fn [e] (.preventDefault e))}
        [:input {:type "text"
                 :name "email"
                 :placeholder "Email"
                 :value @email
                 :on-change #(dispatch [:update-login-form
                                        (-> % .-target .-value)])}]
        [:input {:type "password"
                 :name "password"
                 :placeholder "Password"
                 :value @password
                 :on-change #(dispatch [:update-login-form
                                        (-> % .-target .-value)])}]
         {:on-click #(when (validate @login-form)
                       (dispatch [:login-request]))}


Then, here're the subscriptions:

 (fn [db]
   (reaction (:signup-form @db))))

 (fn [db]
   (reaction (:signup-form @db))))


and finally the update handler:

 (fn [db [_ field value]]
   (assoc-in db [:signup-form field] value)))


Hi, I have this component structure, I’m trying to figure out why when prop1 changes, although two gets the updated prop, one doesn’t, even though it is being re-run but with the same initial value of prop1 every time.

(defn one [prop1]
  [:div prop1])
(defn two [prop1]
  [one prop1])
(defn three []
  (let [prop1 (subscribe [:get-prop-one])
    (fn []
      [two @prop1])]))


Is there a best-practice for naming subscriptions/handlers as the app grows larger? Looking at - would i be naming handlers something like and That's my first inclination, anyway, but if there's something more "oh, everyone just does it like this", I'd be curious to hear it. Thanks!


@hoopes: I’m new to re-frame but have started naming my subs/handlers namespaced like this :users/delete (since clojure uses / for accessing namespaced functions rather than .). Also for subs i’v settled on :users/all , :users/?id (gets a user by id), :users/?ids (gets multiple users by id), :feature/?user-id (you get the drift). I don’t know if there’s a common approach


that's an awesome idea - i think i'm gonna borrow that


@afhammad: is it all the code? i reproduced your example here - approximately and it seems to work just fine


@nidu: Its not all the code, I just tried to simplify it for demo. Thanks for the fiddle, it must be something in my code, i’ll tinker a bit more and see


@afhammad: if components one or two return fn instead of hiccup don't forget that parameters in component should match params of returned fn. That's often the case for me.


@nidu: not sure i got that. are you saying the factory fn and the fn it returns need to accepts the same params?


in my case both one and three return a fn but neither take any params, only parent defn accept params