Fork me on GitHub
#re-frame
<
2021-04-06
>
andre07:04:15

hm force update is pretty useful metric

andre07:04:48

this one also useful

andre07:04:16

dunno how to do a tree, if you have any ideas would be great

Alex09:04:43

Hi :spock-hand: Is there any good practices about components local state managing? Is it ok to pass ratom into event and then in callback event effect clean it:see_no_evil:

(rf/reg-event-fx :event
 (fn [_ [_ state id]]
  {:mutate [... id [:on-success state] [:on-error state]]}))

(rf/reg-fx ::reset-input #(reset! % nil))

(rf/reg-event-fx :on-success
 (fn [_ [_ state result]]
  {...
   :reset-input state}))

(defn component [id]
  (r/with-let [state (r/atom nil)]
    (let [{:keys [loading? value visible?]} @state
          on-submit #(rf/dispatch [:event state id])]
     ... [:input {:value value}] ... [:button {:on-click on-submit}])))
Keep such local state in app-db feels bad - than i need to make sure that it was cleaned. And pass callback into event feels bad, to call it above re-frame dsl.

p-himik09:04:31

Passing a callback would IMO be better. In that case, there would be a more generic :call effect instead of the :mutate effect. Alternatively, just don't use re-frame at all for such a component. Just treat it as if you were using pure Reagent.

3
p-himik09:04:43

The alternative looks especially apt given that :event seems to know a lot about state.

Alex09:04:14

Ah, I see, why it was only event option as :on-success - under the hood of :mutate we use re-graph which uses events as callbacks… And it is a bit intertwined with our app-db for default error-handling…