Fork me on GitHub

Is there a good way to replace a re-frame (reagent) type 3 component entirely when the relevant ratoms change


Context is, I have component-did-mount things that are bound to the original state created


(perhaps I need to bind them to component-will-receive-props instead?)


also, anybody know a good way to replace underscores with dashes when decoding json


via cljs-ajax or whatnot


@bpicolo: for the other question an example snippet might be helpful, not sure I understood 🙂


@bpicolo: you may be able to add a custom handler/format in cljs-ajax that does that for you


@bpicolo: as for your other question, you should bind both to component-did-update and component-did-mount


another trick is to separate the component into inner-component and outer-component , where the latter passes the data (get-in @global-state [:foo :bar]) to the inner component as a prop


then the inner component will be independent of the ratom changes and can take care of reacting to props changes through lifecycle methods


@bpicolo: personally I've found that underscores are OK-ish, one of the reasons being that they make it cleaner which fields came from the server


@mikethompson: I've found myself doing joins like this regularly: is it a bad thing/code smell? Am I right that the second style (`packages-better`) is more efficient, though more boilerplate-ish? I've looked hard at this and this , but it seems that the particular problem of data normalisation isn't covered there


@si14 1. :packages will re-run on every single change to app-db. Even if it has changed in an unrelated way. So :packages-better will potentially be more efficient. It's mapv computation will only run if package-by-id or package-ids changes. 2. I can't see much joining going on. I see mapv, but not much clojure.set/join? Not sure what to make of that. 3. You are right, this issue isn't covered in any of my cods because, in my apps, I don't run into this join problem. I query the database for the data I want, joining at that level, and that gives me the data in the client app already in the (joined) form I need. But obviously requirements vary, so that strategy may not work in your case.


Hi Mike, I'm really liking the changes to fx handlers from a philosophical perspective, but I'm having a bit of troubling with a bug that's making me think my implementation is whacky. I have a little test case set up for a textbox with typeahead . On its change event it fires an event-fx which does some ajaxy stuff. But after 2 to 10 keystrokes (it's seems random) the whole app resets itself to initial app state.


Here's how my handlers are set up:

  (fn [world [_ results]]
    (assoc (:db world) :suggestion-results results)))

  (fn [val]
    ; This used to grab some server side stuff in a go block
    ; but I removed that for simplicity. Fake it till you make it.
    (dispatch [:handle-suggestions (str "Fake Ajax Response from" val)])))

  (fn [db [_ term]]
    {:db      (assoc db :search-term term)
     :suggest term}))


:bounce-search is dispatched from the on-change event in a textbox. Have you come across a scenario where app-db resets? I'm stumped.


Also, I don't see :search-term associated with app-db ever.


Problem solved. I should have been treating the first parameter in the :bounce-search handler function as the world instead of in the :handle-suggestions function. 🙂