This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-24
Channels
- # aws (3)
- # aws-lambda (1)
- # beginners (16)
- # boot (36)
- # cider (3)
- # cljs-dev (90)
- # cljsjs (1)
- # cljsrn (27)
- # clojure (240)
- # clojure-austin (1)
- # clojure-berlin (3)
- # clojure-dusseldorf (2)
- # clojure-france (2)
- # clojure-germany (12)
- # clojure-russia (19)
- # clojure-spec (20)
- # clojure-uk (56)
- # clojurescript (218)
- # clojurex (1)
- # cursive (21)
- # datomic (10)
- # events (1)
- # hoplon (18)
- # instaparse (19)
- # jobs-discuss (3)
- # lein-figwheel (3)
- # luminus (3)
- # lumo (14)
- # off-topic (4)
- # om (76)
- # onyx (67)
- # protorepl (12)
- # re-frame (54)
- # reagent (35)
- # ring (2)
- # spacemacs (5)
- # specter (2)
- # sql (11)
- # untangled (144)
- # yada (34)
@lgessler Well, inject-cofx
is an interceptor (or actually returns one when you call it) that lets you add a coeffect registered with reg-cofx
. All interceptors can add to the coeffects (so you are right in that they are equivalent in some sense), but using these two functions is a bit easier and more explicit. Check out https://github.com/Day8/re-frame/blob/master/docs/Coeffects.md if you haven't already.
in the docs, reading data from a server is implemented as an effect. to me it sounds more like a coeffect. i would have thought POST=effect, GET=coeffect. what is the reasoning here?
well, GET can be used to mutate state server-side, but i'm thinking of a simple read operation
@shem it’s not quite that way. I can see how that would seem but when you do an HTTP GET you aren’t “just reading from a server” the GET itself is a request that gets sent from your code to the server first to get the information. That request itself is a side effect from the point of view of your code.
any HTTP call is the same request -> result so a POST and a GET is the same side effect.
even trying to think how to implement the GET request as a coeffect I can’t even fathom. You’d have to make a synchronous call and even then I don’t know how you would specify where you call.
Maybe if you had like a remote config you wanted to query every time you did something, but even then that would be jumping through hoops. It’s still easier to use an effect to generate the GET request and deal with the GET’s response with a plain old event
You can write a co-effect that provides the contents of the Local Storage the same way you would access the re-frame db
and sometimes you need both a coeffect and an effect to handle a single stateful resource
the db effect takes the modified db that your event handlers return and replaces the re-frame db with it.
That’s the beauty of the co-effects and effects. They take something inherently stateful like your app state, and remove all the “state” from most of your code, only pushing it to the far fringes (the db coeffect and effect)
so now your event handlers are just pure functions that take in an immutable db, and return a modified immutable db and all the icky state management is handled for you elsewhere
and since the db handling is all done for you by re-frame if you replace all examples above with Local Storage, then there is an example of where you would write both co-effects and effects to allow your app to read and write to Local Storage.
and I can see how that may be confusing if you equate a GET with reading and a POST with writing, but a GET and a POST are reading and writing for the server, not for your app.
aka if you write a HTTP POST in your app. Does anything mutate in your app? Not normally.
From app point of view, reading from local storage and reading from server are not that different.
They are slightly different, enough to warrant. To read from local storage you don’t have to send an asynchronous request first. The local storage is already in your app’s memory.
if you had to make a side effect change first to get the local storage then it also would implemented as an effect
So sending the HTTP GET would be an effect, and then reading the response could be a co-effect. However, since the response is not stateful you wouldn’t really do it that way. You can’t “change” the response.
Is there a way to get rid of the reframe: overwriting :event handler for :foo
warning messages I get when reloading? I get one for every event/fx I have registered and it is really noisy in the console. The function that is called when the app reloads is this:
(defn mount-root
[]
(rf/clear-subscription-cache!)
(reagent/render [views/app-start]
(.getElementById js/document "app")))
I am using boot-reload if it matters.It seems like lots of other people have this problem. Do you guys just deal with the possibly 100s of warning messages spammed to the console?
It's worth noting that the warnings only occur when reloading your events.cljs
file(s) but it is still very noisy and unnecessary. 🙂
well, it works for when you do a fresh reload of the whole page in development too, i guess
@mikethompson Thanks.
You can see WIP here: https://github.com/Day8/re-frame/pull/254