Fork me on GitHub
#re-frame
<
2017-08-18
>
mattly05:08:01

events don’t affect components – they can affect the app-state, which in turn affects components

mattly05:08:26

so, what I do typically is give each instance of a component some sort of identifier

mattly05:08:49

pass that to the event dispatch, use it in the app-state and subscriptions

mikethompson06:08:26

@joelsanchez The question you ask is puzzling. In re-frame, components don't communicate. In OM.orig, core.async is often used as an event bus for Components, but that's not done in re-frame. There's a very different notion of "events".

mikethompson06:08:17

To build up your re-frame muscles, I'd suggest you chip away at the docs, and look at the examples.

mikethompson06:08:17

OM.orig and re-frame are very different in approach.

qqq06:08:49

did re-frame suddenly change where ^{:key i} [:li ...] become deprecated and I have to use [:li {:key i} ... ] }

mikethompson06:08:38

Sounds like a question for Reagent (instead of re-frame). But I'm not aware of any changes.

scknkkrer08:08:18

Guys, any nested value in app-db isn’t writeable ? i.e; (app-db {:a {:b 1}}) (subscribe [:a :b]) ;; (-> db :a :b) so Can not I write this returned value ?

scknkkrer08:08:00

My first sight is update the value we get.

scknkkrer08:08:12

with swap! or update.

scknkkrer08:08:18

Am I wrong ?

joelsanchez08:08:23

thank you both for your replies > what I do typically is give each instance of a component some sort of identifier > pass that to the event dispatch, use it in the app-state and subscriptions makes sense to me, I just remembered that the re-frame-datatable component takes an identifier argument, which it uses for identifying that instance's state in the app db, and then you need to use that in your dispatches, so I will follow that

mikethompson11:08:50

@scknkkrer you can't "write" to a subscription, they are read only

scknkkrer13:08:38

Sorry for my silly question, I need rest, I think. 😊