Fork me on GitHub
#re-frame
<
2016-12-09
>
cmal02:12:47

Hi, I am reading the doc of interceptors and have a question: I am using the re-frame-template, default-db is defined in db.cljs. If I want to use reg-event-fx, should I define default-db to be the structure of context, which has the keys :coeffects, :effects, :queue, :stack? Or should I just use the default-db as the :db in :coeffects, while the context structure has already been pre-defined by re-frame? Thanks.

cmal03:12:53

some refs

{:coeffects {:event [:some-id :some-param]
             :db    <original contents of app-db>}   ;; <== is this :db just the default-db?

 :effects   {:db    <new value for app-db>
             :dispatch  [:an-event-id :param1]}

 :queue     <a collection of further interceptors>
 :stack     <a collection of interceptors already walked>} ;; <== or should I define the whole structure to be default-db? 

mikethompson03:12:35

@cmal

(def-event-fx  
  :initialise
  (fn [cofx v]
     {:db  default-db}))
An -fx event handler returns a map, which represents the effects it wishes to be made. effects are returned in a map. Each key of the map identifies the effect. The value represents "further values"

mikethompson03:12:16

The :db effect is how you say "please change the application state (app-db) to this value"

mikethompson03:12:16

So just to be clear: - the parameter cofx is the :coeffects out of the context - the returned map will become the :effects in the context

mikethompson03:12:05

The above is exactly the same as this -db version:

(reg-event-db 
   :initialise
   (fn [db v]
      default-db))

mikethompson03:12:02

In the case of -db handler, the only coeffect supplied (1st parameter) is the current application state. And the only effect returned is the new application state.

cmal03:12:43

@mikethompson Thanks. Sorry for my English, not clearly understood the docs. So is there an overall context that contains :coeffects and :effects which defined by re-frame? Or should I define it myself?

mikethompson03:12:02

a context is what is passed along the interceptor chain. re-frame provides it

cmal03:12:58

So the thing being passed to reg-event-db as db , and to reg-event-fx as cofx is not the same, right?

mikethompson03:12:03

Best I can do here is to encourage you to read over the docs again

mikethompson03:12:27

cofx contains :db

mikethompson03:12:09

-db handlers are a simple way of doing the same thing as -fx, at the cost of being more limited

cmal03:12:51

Ok. Thanks for your help. I'll treat the docs as my textbook and read it till clearly understand. It's lucky to be a student of you.

samueldev04:12:12

Is using a (reagent/atom) still the idiomatic way to handle form input values?

mikethompson05:12:37

@samueldev probably. re-com does it a similar way

samueldev05:12:16

thanks @mikethompson - and refresh my memory, do you know the name of the library that automatically handled dispatching things for REST requests?

samueldev05:12:18

success fail etc

samueldev05:12:31

yes! thank you šŸ™‚

samueldev05:12:27

can I ask you things about that lib @mikethompson or is that best saved for @danielcompton ?

mikethompson05:12:53

Daniel is probably better to answer, although his weekend just started

samueldev05:12:07

Iā€™m wondering why some of the handlers have a double colon ::

samueldev05:12:19

is that by convention or any particular reason?

mikethompson05:12:38

where are these :: ?

mikethompson05:12:54

Oh, in the docs?

mikethompson05:12:20

Right. No particular reason for the ::. Ignore if it does not suit you.

samueldev05:12:59

Thanks šŸ™‚

akiroz07:12:54

@samueldev those are ns-qualified keywords. if you have a big app with multiple modules (say, foo and bar) and each needs a sub called name or something generic like that. writting ::name in foo will result in a sub-id of :foo/name so it won't clash with the ::name inside bar

akiroz11:12:02

@andre very nice! but shouldn't there be a view function that generates hiccup between subs and Reagent ?

akiroz11:12:56

would also be nice if it shows events coming from ajax responses

andre11:12:08

@akiroz there is no view function, reagent wathes the deref of ratom wich subscribtion returns

andre11:12:19

ajax responses - i'm thinking, there are a lot of things

akiroz11:12:51

so... maybe a view function inside reagent?

akiroz11:12:31

I guess the views are technically not part of re-frame

andre11:12:14

i understand, viewes should be inside reagent, not insude the dom

andre11:12:10

it's complicated

andre11:12:38

ok i'll try

andre11:12:42

thank you

akiroz11:12:56

keep up the good work~ I freakin' love diagrams šŸ™‚

andre12:12:30

looking on the diagramm i have two questions about subscriptions, all subs will be running on app-db changes. so is it better to unsubscribe ? and what if run subs only if some value changed in the db?

andre12:12:47

i'm talking about subs performance

mikethompson12:12:32

@andre I love what you have done. But it scares me too. Diagrams always worry me. They invariably make something look hugely complex. Intimidating. I've got a feeling that dominos 1 2 and 3 should be on the one Diagram and 4 5 6 should be on another

andre12:12:18

yes, i'm scared too šŸ™‚ so i'm thinking to create some interactive diagrams from simple to complex

mikethompson12:12:41

Yeah, the hard thing to communicate in a static diagram is the passage of time

mikethompson12:12:54

Regarding your subscription questions ...

mikethompson12:12:24

.... I'll explain it this way ...

mikethompson12:12:24

1. At run time there is a signal graph 2. At the root of the signal graph is app-db 3. At the leaves are views 4. In between are nodes created by reg-sub

mikethompson12:12:48

The in-between nodes only exist because a view does a subscribe

mikethompson12:12:53

That's a key point

mikethompson12:12:09

reg-sub just says that a node might exist

mikethompson12:12:21

And if it is requested then "here's how to do it"

mikethompson12:12:51

But no signal graph exists (is instantiated) until a subcsribe in a view happens

andre12:12:12

right. thank you

andre12:12:28

so , on my chart , there shouln't be an arrow from db to sub-key3 , because i don't have subscribtion in views

andre12:12:22

and to :a too

mikethompson12:12:34

Unless a view has done the necessary subscribe, that part of the graph does not exist

andre12:12:03

yes. thank you

mikethompson12:12:13

So the CREATION of the signal graph is driven from the leaves of the graph (the views)

mikethompson12:12:43

However, the later data propogation thought the graph originates from app-db

andre12:12:56

how does re-frame understand that view was removed? to unsubscribe

mikethompson12:12:24

The view is itself actually a reaction :-)

andre12:12:39

:thinking_face:

mikethompson12:12:34

So when it gets destroyed its its component-did-unmount runs around all the direct nodes in the signal graph and say "I don't need you any more"

mikethompson12:12:47

Those nodes in turn tell their upstream nodes etc

mikethompson12:12:09

When anyone of those nodes get to having 0 upstream nodes, they dispose of themselves

mikethompson12:12:30

And the whole tree unwinds

andre12:12:43

re-frame is not as simple inside as it looks from the outside šŸ™‚

mikethompson12:12:01

Ahh, that's the trick :-)

mikethompson12:12:04

From a design point of view, the part of re-frame I'm most pleased with is the subscriptions side of things.

mikethompson12:12:14

You can be quite ignorant and it all just works

mikethompson12:12:21

That's a good thing

andre12:12:43

ā¤ļø

cmal14:12:53

Thanks for your discussions.

danielcompton22:12:53

It's weekend for me now, will look at this next week. I'm usually pretty responsive on GitHub issues, so no extra pings needed :)

samueldev22:12:51

sounds good thanks daniel