howdy re-framers

the following handler...

I think is done correctly

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

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

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

but only then

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

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

@mikethompson

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

hey that did it

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

in other words?

So I am not totally sure

but I think https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components#form-2--a-function-returning-a-function

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)

^^^ quote from section

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

and it detects that the component already is there

gotcha

appreciate it

rookie mistake

Well I might be wrong because I am a rookie too

¯\(ツ)/¯

@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.

@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)

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

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

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

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

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

If I'm reading between the lines correctly

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

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

almost. It will subscribe to/unsubscribe from corresponding resource

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

Have a read over this recent discussion: https://clojurians.slack.com/archives/re-frame/p1455506216000023

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

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.

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).

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

oh, yeah, excuse me for that.

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

it's a bit confusing

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

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

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)

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

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

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

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).

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...

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

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

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

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.

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

@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

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

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

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 ?

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

@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

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

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

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

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

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 ->