Is it safe to deref an external atom inside an event handler?

[JordanSkousen]

Hi all,

Propose I have the following code:

(def !monkey-business (atom 69))

(reg-event-fx
  :harvest-banana
  (fn [{:keys [db]}]
    (let [number-of-bananas @!monkey-business 
          max-bananas 420]
      (if (>= number-of-bananas max-bananas)
        {:db (assoc db :alert "Too many bananas!")
         :dispatch [:throw-a-fit]}
        {::do-harvest-banana nil}))))

(reg-fx
 ::do-harvest-banana
 (fn []
   (swap! !monkey-business inc)))

Is it safe for me to deref the !monkey-business atom inside the event handler? It's not being modified inside the handler, just read, so it seems safe to me, but I just wanted to clarify.

I've been only deref'ing atoms inside fx handlers just to be safe, but things can get convoluted very quickly and I'd like to keep the dispatch flow easier to follow.

[hipitihop]

@JordanSkousen Atoms read or modified in a fx handler should be fine, assuming all atoms are only modified via re-frame event handlers.

However this raises a fundamental design question: Why is this state managed outside of app-db in other atoms as opposed to properties app-db db ?

[JordanSkousen]

You are right, in the example I gave it would make more sense to store the monkey-business value inside the re-frame db.

In my actual usage case, I am storing megabytes of data in external atoms, including AudioBuffers which I thought should be kept outside the db to keep it light. Idk though, maybe that's not necessary.

[hipitihop]

Just to note the obvious, app-db is already an atom, so I'm not too sure what the gains are vs the benefits of not managing distributed state. Obviously I'm not familiar with your actual use case which may justify the trade-offs. Anyway, hope that helps.

[JordanSkousen]

You're right, I guess I was "afraid" to store things inside the app-db haha. I've got some refactoring to do then!
Thank you for your help!