Fork me on GitHub
#re-frame
<
2016-01-28
>
mbertheau09:01:02

@danielcompton I think I understand dynamic subscriptions, but why you're asking? My question earlier about when components update don't have anything to do with dynamic subscriptions, right?

danielcompton09:01:00

oops, sorry, meant to mention @yenda for that

danielcompton09:01:12

@yenda: do you understand dynamic subscriptions now, or is there something still unclear?

yenda09:01:24

@danielcompton: I'm not sure. It didn't fit my use case, the way I understood it is that you had to have a subscription to the "current id" of the entity you want to dynamically track, and a second one that subscribe to it

yenda09:01:03

I think the exemple in the wiki is not clear enough, is (q/get-query active-list) a function to get the active-list that is supposed to be defined elsewhere ?

danielcompton09:01:45

I think I need to update that example to be clearer, you’re right

yenda09:01:29

that would be great, could you go with a minimal exemple, kind of standalone ?

yenda09:01:48

I wanted to use it because I have deeply nested datastructures with mixes of maps and lists that are edited in subcomponents

yenda09:01:36

so at some point to "make things easier" I started to use refs and uuids in my datastructure and it started to look like a relationnal db

yenda09:01:48

I'm not sure what the best solution is for that kind of things, I went back to nested datastructure but I have to pass some parents props to be able to edit fields

yenda09:01:35

my schema is like this

yenda10:01:03

The most tricky thing was to modify the parameters of a request because it's a map so I didn't know how to change the name properly. my solution was to turn parameters into a vector in the editor and change it back into a map when saving. I also have to pass the request index to the parameter component to be able to send it in the event

yenda10:01:01

with this solution it is easier to effectively remove a parameter from a request

yenda10:01:57

it requires these few utility functions

yenda10:01:22

Did I get totaly lost in the wrong path or does it seems like an ok idea ?

yenda12:01:20

actually it is silly, my afterthought is that it would be easier to just keep the parameter, dissoc the old name and assoc the new one when it changes

yenda13:01:46

the problem when you edit a field that is defined by a key is that you lose focus of the component you are editing though

yenda13:01:14

so you can only type one param at a time 😄

mbertheau13:01:01

@danielcompton: If you don't mind. is it correct to say of a Form-2 component, 1. the inner render function is called again when an atom that was deref'd inside it, changed since the last call 2. the outer function is called again when the function argument values are different from last time

yenda13:01:28

I thought outer function only renders once

jaen13:01:46

The outer function doesn't "render" per se, it only returns a render function.

mbertheau16:01:01

Why can't/shouldn't I just use (reaction (some-transformation @re-frame.db/app-db)) instead of subscriptions?

samueldev16:01:42

I mean... I guess.. you could... ?

mbertheau16:01:40

The act of registering a subscription is not functional but imperative in nature.

jaen16:01:38

True, but you do it once at the boot of application, so during the run of application it's effectively immutable.

mbertheau16:01:15

But what's their purpose?

jaen16:01:58

I suppose it's only to have a common place to have subscriptions in.

jaen16:01:16

You could achieve the same defing them in a namespace.

mbertheau16:01:32

That's my current understanding as well.

yenda16:01:41

what if you use the subscription twice ?

jaen16:01:05

Yeah, but that's reason enough - better have a common place to have subscriptions in, instead of duplicating code.

jaen16:01:21

And you can start composing them that way.

jaen16:01:16

like

(def users (reaction ...))
(def sorted-users (reaction (sort-by :join-date @users))

jaen16:01:59

Maybe there was some reason to make subscriptions dynamic, thought I'm not sure what could that be; I don't really see any upsides to being able to register subscriptions dynamically.

mbertheau16:01:26

The dynamic reloading that happens in the figwheel-like development process may be a reason.

mbertheau16:01:17

If you just def them they are all there and will always be run if an input atom changes, regardless of whether they are needed anywhere.

mbertheau16:01:34

subscribing to them allows keeping track of which subscriptions are in use.

mbertheau16:01:54

That's all under "maybe" though, I don't understand it well enough to say with certainty.

jaen16:01:29

Hmm, I don't think reactions are run automatically unless you create them by run! instead of reaction.

jaen16:01:41

But I must say I don't know 100% to be sure.

mbertheau16:01:51

Yeah, that's in the middle of the part that I don't understand at all yet simple_smile

jaen16:01:13

But as far as I understand it, defs should be equivalent.

jaen16:01:10

One more reason I can think of (apart from dynamicity; but then again it seems of little value, unless in development and then you have boot-reload/figwheel) is that you also have reactions with parameters

jaen16:01:32

It's probably easier to hide that behind a function, instead of writing a macro that would encapsulate it in a def-like case.

jaen16:01:56

But probably the maintainer would be better at answering those question; he knows his reasons, we can only guess at them.