In this specific example from the quick-start, we see an implicit argument against a separate store, namely reactive state that no one else needs to know about, meaning creating subscriptions for it in a separate store would be needless coding nuisance:
(div {:class "intro"}
(span {:class :push-button}
"Cat Chat")
(speed-plus #(mset! (fmu :cat-fact (evt-md %)) :get-new-fact? true))
(div {:class :cat-chat}
{:name :cat-fact
:get-new-fact? (cI false
;; The "plus" widget will just set this property repeatedly to the same value, 'true'.
;; Declaring this input Cell "ephemeral?" means it will fire each time that same value is set.
:ephemeral? true)
:cat-request (cF+ [:watch (fn [_ me response-chan _ _]
(when response-chan
(go (let [response (whenever the XHR responds, we just `mset!` the waiting input cell
(with-cc :set-cat
(mset! me :cat-response response))))))]
(when (mget me :get-new-fact?)
(client/get cat-fact-uri {:with-credentials? false})))
:cat-response (cI nil)}
(if-let [response (mget me :cat-response)]
(if (:success response)
(span (get-in response [:body :fact]))
(str "Error> " (:error-code response)
": " (:error-text response)))
"Click (+) to see a chat fact.")))
When we move this component around, the state stays with it. If we drop it altogether, we do not need to go clean up the separate store. Bottom line, this state is fine where it is, and the code benefits not at all from having it in a separate store. The component is nicely self-contained.
At the same time, if someone wants to add a "translation widget" alongside this and display the cat-response in French, that would work with the right navigation: the chat widget is still part of the implicit application DB.
Hth.