Fork me on GitHub
#re-frame
<
2016-07-31
>
bpicolo01:07:47

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

bpicolo01:07:11

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

bpicolo01:07:30

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

bpicolo01:07:19

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

bpicolo01:07:23

via cljs-ajax or whatnot

martinklepsch10:07:20

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

pesterhazy10:07:07

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

pesterhazy10:07:02

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

pesterhazy10:07:12

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

pesterhazy10:07:08

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

si1420:07:05

@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

si1421:07:07

@mikethompson: I've found myself doing joins like this regularly: https://gist.github.com/si14/db0ed40123c14a28b6f5808e3a824c1d 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 https://github.com/yatesco/re-frame-stitching-together/blob/master/src/cljs/demo/views.cljs and this https://github.com/Day8/re-frame/blob/be6c53131d5a457b641bb657ac2935c6f1489969/examples/todomvc/src/todomvc/subs.cljs , but it seems that the particular problem of data normalisation isn't covered there

mikethompson21:07:04

@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.

joshkh21:07:58

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.

joshkh22:07:29

Here's how my handlers are set up:

(reg-event
  :handle-suggestions
  (fn [world [_ results]]
    (assoc (:db world) :suggestion-results results)))

(reg-fx
  :suggest
  (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)])))

(reg-event-fx
  :bounce-search
  (fn [db [_ term]]
    {:db      (assoc db :search-term term)
     :suggest term}))

joshkh22:07:22

: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.

joshkh22:07:43

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

joshkh22:07:52

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. 🙂