Fork me on GitHub
#re-frame
<
2016-02-19
>
coyotespike18:02:54

I have a function which should update a handler, and then immediately display the corresponding subscription. However, the ratom isn't updated until the entire function has run.

(defn poll-button [stateclass emailclass]
  (fn []
  [:input {:type "button" 
           :class "btn btn-info" 
           :value "Vote"
           :on-click #(if (email-filled?)
                        (do
                          (dispatch [:enter-contact "Joy to the fishes in the deep blue sea."])
                          (js/alert @(subscribe [:contact]))
                          ;; close Modal window
                          (reagent-modals/close-modal!))
                        (reset! emailclass "has-error"))}]))

coyotespike18:02:53

I thought the do block might be to blame, so I pulled it into it own function :thinking_face: but no dice

coyotespike18:02:24

The second time I push my button, :contact has updated correctly. Any ideas greatly appreciated!

coyotespike18:02:42

Basically, I'd like the side-effect of calling dispatch (an updated Big Atom) to be reflected immediately. Which is what I thought do was for.

mikethompson20:02:43

dispatch-sync will do what you want, but what you are trying to do is something of an anti-pattern.

mikethompson20:02:17

And do does not do what you think it does (not often you get to say that line).

coyotespike21:02:51

That's very yoda of you 😉

coyotespike21:02:59

Thanks for the tip about dispatch-sync. And when you say it's an anti-pattern, is that because I should probably just send along my data directly, instead of through a handler-subscription duo?

coyotespike21:02:51

(I have an already-written function which subscribes to :contact, and which I will call instead of js/alert, so here I am lethargically using :enter-contact to send data to that pre-existing function)

mikethompson21:02:10

Not so much yoda, more Inigo Montoya simple_smile

mikethompson21:02:23

Using dispatch-sync in a Component feels very imperative. It is like the Component is trying to change the world. In re-frame Components do not try to change the world. They simply render the current state (including dispatches). They are a simple function of the state (which produces hiccup).

mikethompson21:02:37

It is event handlers which change the world

mikethompson21:02:06

So, I'd move whatever world changing (state changing) thing you are doing into an event handler

mikethompson21:02:07

The handler for that button click (everything in the do should live in an event handler). The on-click handler should just be (dispatch [:something-clicked])

mikethompson21:02:04

The associated event handler might perhaps alter the :modal-showing? piece of state. It might even put in place data for that modal to edit.

mikethompson21:02:42

Somewhere among your Components there is one which subscribes to the :modal-showing? and when it is true, it shows the modal.

mikethompson21:02:19

[:div (if @modal-showing-subscription [my-modal XXX])]

coyotespike21:02:29

....thinking....

coyotespike21:02:37

Yes, I see what you're saying. Here, I'm just sending a form to the back-end, and relying on a function with a subscription to do the sending. That function made sense before, but here jury-rigging a Component to send stuff is silly.

coyotespike21:02:14

Thanks for clarifying, I'm keeping your thoughts for future reference as well 😎

mikethompson21:02:52

Glad to help. Good luck. Be sure to read the re-frame Wiki.

mikethompson21:02:06

(yeah, I know, more reading!)

coyotespike21:02:13

lol it's surprising how many things I keep re-discovering in the Wiki

mikethompson21:02:39

It is a many-layered onion, as is the original readme.

coyotespike21:02:59

I've now built two (related) production apps with re-frame. I just started hacking stuff together with reagent and eventually found myself with state scattered here and there. Re-frame provided a graceful and even elegant solution and way of thinking about state.

coyotespike22:02:52

So I've appreciated the readme many times (along with the many jokes, ecclesiastical and otherwise ;-))

coyotespike22:02:18

I also find myself using more re-com components

coyotespike22:02:27

Anyway, thanks for both simple_smile

mikethompson22:02:20

Excellent! I'd love for re-com to get a bit more use out there.

mikethompson22:02:23

I must admit we are a bit slow on new releases, but there's a lot of hard-fought-for knowledge in there

coyotespike22:02:03

Well, I keep multiplying components needlessly - a sane way to abstract over components, and allow flexibility/customization, is helpful.

coyotespike22:02:11

So over time I get pushed toward re-com as well 👍