Fork me on GitHub
#re-frame
<
2018-01-20
>
danielcompton07:01:21

@caleb.macdonaldblack there isn't one by default. You want to avoid depending on app-db except for layer 2 subscriptions (https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md), i.e. wanting to get db as an input signal is usually an antipattern

danielcompton07:01:45

re-frame 0.10.3-rc2 is out. Give it a go on your projects and let us know if there are any issues, we'll be releasing it shortly https://github.com/Day8/re-frame/releases/tag/v0.10.3-rc2

caleb.macdonaldblack11:01:18

@danielcompton In the re-frame docs you guys advise against doing this

(reg-sub 
   :extract-any-path
   (fn [db path]
     (get-in db path))

caleb.macdonaldblack11:01:17

Is it a good idea to dispatch an event like this: (rf/dispatch [:set-value idx key value])

mikethompson11:01:25

@caleb.macdonaldblack Well, events should capture/model user intent. They should capture what action the user wants to perform, rather than capturing any specific technical deailt. So, yes, they will quite often contain an id of the thing to be act upon. But, no, don't embed information about the strucutre of app-db in an event.

caleb.macdonaldblack11:01:51

@mikethompson Right so I might have some maps in a vector and I want to set a value in one of those maps. I could dispatch an event with the index, key and value and this would be fine?

caleb.macdonaldblack11:01:24

But dispatching an event with the path to the vector of maps is something you wouldn’t do?

caleb.macdonaldblack11:01:00

I want to keep index here because I need react to keep focus on elements when a row is removed

mikethompson11:01:48

Hmm. You appear to be thinking about events as you might a function call. Events, though, capture user intent. I know I'm repeating myself here, but its an important point. The event captures what the user wants to happen. The event handler interprets that into action/code/mutations. So, I can only answer you in the abstract - the event parameters should be sufficient to capture intent but should not go so far as to capture implementation details about the sturcuture of app-db (that is hidden away in the event handler)

caleb.macdonaldblack11:01:37

Okay thanks. Based on what you said I believe I’m doing things correctly in this situation.

joelsanchez22:01:50

what's the point of reagent.session when one is using re-frame? none, right?

mikethompson22:01:57

I'm not even aware of reagent.session or what it does. So, whatever it is, it certainly isn't essential :-)

joelsanchez22:01:25

😂 it's a very simple wrapper around an atom

joelsanchez22:01:03

thanks, good to know it's useless

joelsanchez22:01:01

ah...it's in reagent-utils, not in reagent...anyway, if you're curious: https://github.com/reagent-project/reagent-utils/blob/master/src/reagent/session.cljs

mikethompson22:01:14

No, you absolutely won't need that. Everything, including session information goes in app-db, not off to the side in another atom.