This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (3)
- # announcements (1)
- # aws (3)
- # beginners (41)
- # boot (109)
- # braid-chat (2)
- # braveandtrue (5)
- # cider (11)
- # cljs-dev (38)
- # cljsjs (15)
- # cljsrn (5)
- # clojure (87)
- # clojure-berlin (16)
- # clojure-ireland (1)
- # clojure-japan (10)
- # clojure-madison (3)
- # clojure-nl (3)
- # clojure-poland (6)
- # clojure-russia (115)
- # clojure-sg (1)
- # clojurebridge (35)
- # clojured (8)
- # clojurescript (36)
- # core-async (24)
- # cursive (18)
- # datavis (1)
- # datomic (27)
- # dirac (22)
- # editors (1)
- # emacs (3)
- # events (19)
- # hoplon (149)
- # ldnclj (7)
- # lein-figwheel (1)
- # luminus (1)
- # off-topic (70)
- # om (196)
- # onyx (63)
- # parinfer (155)
- # proton (36)
- # re-frame (69)
- # reagent (2)
- # ring (2)
- # ring-swagger (1)
- # slack-help (4)
- # spacemacs (9)
- # testing (11)
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
not sure why if anyne has any idea that'd be cool. here's the component as well for reference...
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)
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
@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)
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?
@mikethompson: sure. I'd like to execute one action when first subscriber arrives and another action when last subscriber leaves. Kind of initializer/finalizer
Have a read over this recent discussion: https://clojurians.slack.com/archives/re-frame/p1455506216000023
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 ?
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
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-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
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
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
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