Fork me on GitHub
#re-frame
<
2016-02-17
>
samueldev04:02:30

howdy re-framers

samueldev04:02:35

the following handler...

samueldev04:02:15

I think is done correctly

samueldev04:02:26

but the component that subscribes to the same property...

samueldev04:02:04

only gets the initial value in app-db, not the updated one when I dispatch :show-add-form

samueldev04:02:25

and, curiously enough, when I save a file and figwheel reloads the files, it then picks up the app-db change from the aforementioned dispatch

samueldev04:02:26

but only then

samueldev04:02:12

not sure why simple_smile if anyne has any idea that'd be cool. here's the component as well for reference...

samueldev04:02:53

^ first component contains the dispatch, 2nd component contains the subscribe

kamn04:02:24

@samueldev: move the second display(in the let) to inside the function

samueldev04:02:41

hey that did it

samueldev04:02:46

so when I deref it has to be inside the render fn

samueldev04:02:48

in other words?

kamn04:02:35

So I am not totally sure

kamn04:02:53

Let's be quite clear what is going on here: timer-component is called once per component instance (and will create the state for that instance)

kamn04:02:02

^^^ quote from section

kamn04:02:41

then even though you are reloading with figwheel it does not call that since there is some "state" in React <- Not totally sure about this either

kamn04:02:52

and it detects that the component already is there

samueldev04:02:31

appreciate it

samueldev04:02:33

rookie mistake simple_smile

kamn04:02:05

Well I might be wrong because I am a rookie too

kamn04:02:06

¯\(ツ)

hugobessaa09:02:03

@samueldev: when your file is reloaded, it eval all forms. If you are rendering the component within this file, it will render the new state.

hugobessaa09:02:03

@samueldev: reagent will note when you deref a reagent/atom (the return from a subscribe call) inside the second function, making the component rerender if it's value change overtime (e.g. after dispatching)

hugobessaa09:02:02

@samueldev: read through the reagent README.md and you will understand this https://github.com/reagent-project/reagent

hugobessaa09:02:51

Also, make sure you read the re-frame wiki page. It has a lot of useful content about reagent basics

nidu11:02:46

Hello, could anyone please tell me - i there some kind of subscription middleware in re-frame?

mikethompson11:02:08

@nidu that question does not really parse for me. Can you explain what you are trying to do?

mikethompson11:02:29

There is a piece of middleware called on-change which may be what you are after

mikethompson11:02:37

If I'm reading between the lines correctly

nidu11:02:19

@mikethompson: sure. I'd like to execute one action when first subscriber arrives and another action when last subscriber leaves. Kind of initializer/finalizer

mikethompson11:02:34

Would this action be loading and unloading data from a server?

nidu11:02:26

almost. It will subscribe to/unsubscribe from corresponding resource

mikethompson11:02:51

Okay, so in reframe you wouldn't really do it the way you are thinking

mikethompson11:02:52

It isn't an exact match for your scenario, but it might save me some typing

nidu11:02:06

Totally agree that fetching itself should be done in handlers. I just wanted subscription to call specific handler when first subscriber arrives. This way the actual job remains inside handlers. I guess this server subscription approach can be implemented with some mixins or component wrappers instead.

nidu11:02:23

There's just a pattern when you subscribe in component-did-mount, resubscribe in component-will-receive-props and unsubscribe in component-will-unmount. It definitely can be done with some mixin factory, but embedding it into some kind of re-frame subscription hooks sounded so tempting (though confusing and complicating).

mccraigmccraig12:02:46

@nidu are you using the term subscriber to refer to both the re-frame concept and some application concept ?

nidu12:02:32

oh, yeah, excuse me for that.

nidu12:02:57

maybe it's not clear sometimes where i refer to which subscriber

mccraigmccraig12:02:32

it's a bit confusing simple_smile

nidu12:02:52

there's re-frame (client only) subscription and kind of client-server subscription

mccraigmccraig12:02:08

by client-server subscription do you mean a websocket or SSE type thing ?

nidu12:02:27

websocket. For some kinds of resources there are methods on the server to subscribe and to unsubscribe a client. When client is subscribed - he receives changes related to the model (as simple as that)

mccraigmccraig12:02:48

i have something similar in my re-frame app... there's a core.async go block which consumes from the websocket and dispatches re-frame events to update the app state

nidu12:02:35

yeah, i guess that's how re-frame (or any clojurescript app) should communicate with websocket, but my question was specific to some subscription technique. I wanted to "merge" my client and server subscriptions a bit

mccraigmccraig12:02:57

@nidu: i'm not sure what that means - can you elaborate ?

nidu13:02:46

sure. We had an idea in our application - use websocket instead of ajax entirely. That opens doors for server push and the we thought - what if we will keep client side up to date with server all the time? Sounds pretty nice. So we decided to introduce a kind of subscriptions. When client needs some resource - it doesn't emit fetch operation. Instead it emits sub when it needs resource (usually when component mounts or it's props are changed) and unsub when it doesn't need resource anymore (usually when component unmounts or it's props are changed). While client is subscribed to specific resource - it receives updated from server related to this specific resource. Actually this approach solves a couple of problems on client for me - 1) I no longer have to decide when data on client becomes stale because it's always up to day and 2) it's clear now when i can unload data on client (when nobody is subscribed to it), but that's another story. I try to use this approach on client now for most resources, but server usually just returns data on subscription cause our backend doesn't track changes at the moment (because it's messy). Approach has cons as well of course. Then i thought that this client-server subscription approach is a bit close to re-frame subscriptions. I could subscribe server resource automatically when first subscriber subscribes re-frame resource and unsubscribe from server resource when last subscriber unsubscribes from server resource (excuse my tautology). This way component doesn't have to initiate server subscription on his own and he's not actually interested whether resource is fetched from server or taken from client db when he requests it (maybe it's not so good).

mccraigmccraig13:02:03

it sounds like you have some higher-level concept of remote-subscription which you would want to wire into :component-will-mount and :component-will-unount or something...

mccraigmccraig13:02:09

but this remote-subscription seems quite different from a re-frame subscription, in that it's got a bunch of behaviour which seems more appropriate to re-frame handlers than subscriptions, and while it may have a re-frame subscription or reaction associated with it, it's considerably more than that

nidu13:02:51

agree. I wanted to trigger some re-frame handlers or sub/unsub. Probably that's out of re-frame scope

mccraigmccraig13:02:39

just a function which sets up the remote-subscription and the servicing go block then dispatches, and dispatches again when the go block terminates ?

nidu13:02:57

i didn't think that it would have dedicated go loop for entire subscription life time. Just dispatch a message on first subscription and dispatch another action on last unsubscription.

nidu13:02:30

and certainly there should be different client-server subscriptions for different arguments in case of dynamic re-frame subscription

mccraigmccraig13:02:52

@nidu: i meant a go block to service each subscription - that can then dispatch when that subscription starts/ends and the handler logic can determine if it's the first/last subscription for a particular resource based on accumulating something in your app state

nidu13:02:48

there's no need to utilize app state for tracking subscriptions if re-frame have some kind of subscription counter (with atom add-watch or something like this, unfortunately i don't know re-frame well enough), but storing it in app state gives some advantages

nidu13:02:56

you mean one go loop per subscription with internal counter inside loop?

mccraigmccraig14:02:55

re-frame subscriptions are reagent reactions and they iplement IWatchable... so you might have some mileage there, i dunno. but why wouldn't you use your app-state for tracking subscriptions ?

nidu14:02:28

actually there's no reason for that, just didn't want to burden app state with it if it can be done without app state. What i was asking is the ability to hook into re-frame subscription lifecycle

mccraigmccraig14:02:33

@nidu: you could certainly look at the Reaction impl ... i have no real feel for it, but at first glance it looks like the on-dispose options may be of use to you https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.cljs#L472

nidu14:02:14

@mccraigmccraig: thanks a lot! Gonna do it when have some time

mccraigmccraig14:02:31

but i would just use the app-state unless there is good reason not to - one of the best features of re-frame is it's great simplicity, making it very easy to reason about and introspect

nidu14:02:23

sure, why not, the real question for me is these hooks

jakehow21:02:48

Hey all, anyone have any insight into how to always service index.html for an SPA using figwheel? More details here-> https://github.com/bhauman/lein-figwheel/issues/344

jakehow22:02:18

Also, slightly easier question, what is the correct way to create components that accept a list of components as an argument? Here is the basic idea of what I want to do ->