This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-11
Channels
- # aws (6)
- # beginners (167)
- # cider (41)
- # cljs-dev (6)
- # cljsrn (3)
- # clojure (399)
- # clojure-dusseldorf (1)
- # clojure-nl (2)
- # clojure-spec (3)
- # clojure-uk (47)
- # clojurescript (16)
- # core-async (8)
- # cursive (56)
- # datomic (14)
- # devcards (1)
- # docs (2)
- # duct (2)
- # editors (3)
- # emacs (3)
- # fulcro (178)
- # graphql (10)
- # off-topic (107)
- # onyx (7)
- # pedestal (21)
- # planck (13)
- # re-frame (58)
- # reagent (76)
- # ring-swagger (3)
- # shadow-cljs (85)
- # slack-help (2)
- # sql (1)
- # tools-deps (11)
- # uncomplicate (5)
- # vim (24)
- # yada (4)
@danielcompton if i get Error compiling debux/common/util.cljc
when integrating the newest 10x, what’s the remedy?
Not quite sure, I haven't figured out what the problem is
It seems to be related to the ClojureScript analyzer not being available
using :none
; no advanced compilation stuff involved
But I can't see why it wouldn't be available in your project
I will probably use macrovich to gate the function that uses the analyzer to only run in ClojureScript macros, but I haven't got it working yet
just in case it helps, here’s the full strace
Yeah the actual exception thrown above that one talks about analyzer api IIRC
it occurs when i cider-refresh
interesting, (require 'debux.common.util)
works fine before i attempt a refresh. so perhaps it’s some sort of odd race issue
anyway, i’ve rolled back to the previous version for now 🙂
Hmm, so it works ok with the previous version? Will need to do a diff. Remind me which versions you were trying?
I've been working with re-frame for some time but I'm still not sure on this one thing, and would love to know if anyone has a rule of thumb or guideline: when is it best to use an effect handler and when to use an interceptor...
(in cases when both would work technically)
effect handler
should be the first weapon you reach for.
:after
handler in an interceptor the second
ah ok - so if I can do something in an effect handler - do it...
effect handlers
are simpler
:after
in interceptors more powerful, but a bit more work
thanks!
the specific case that got me asking was implementing error breadcrumb tracking. (And similarly analytics). The effect would be a side effecting js call to sentry.js
to capture breadcrumbs, but I was contemplating doing it as an interceptor - I'm not sure why, just had this kinda feeling like I should get a second opinion 🙂
interceptors approach: - bad because you have to add this interceptor to all registrations (see FAQ #13) - good because the event handler doesn;t have to explicitly create the effect all the time
How can I get my env to "forget" existing subs or events? (use case: I have just refactored my code, moving a pile of events to a new namespace. I want to test that I've not forgotten anything, without having to restart everything)
question: in re-frame/reagent, it doesn't seem like you can pass stuff into the render
function. How do you pass identification data to the component then? Use case is that I'm trying to load 3 different copies of the same component
@kanwei What do you mean by identification data? reagent components are functions... used them like a function except you call them with [...]
(defn my-component
[msg]
[:div (str msg)])
(defn my-composite-component
[]
[:div
[my-component "one"]
[my-component "two"]
[my-component "three"]])
> (reagent/render [search-plugin] attached-element) sure and yeah, pass parameters in the call
Why are handlers (e.g. effects, subs, etc.) defined with keywords instead of something like a symbol (i.e. a function-like definition)?
@deg there's no easy method of removing previously-existing-but-now-deleted events. Restart the easiest option. (unless you want to start dissoc-ing the registrar
data structure which re-frame uses internally to map ids
to handlers
@kenny you want your ids
to be data. keywords are easy to work with. Keywords can be namespaced. In theory you can use anything as an id
in re-frame - even a vector of things, or, indeed, a symbol.
Oh interesting. I didn't realize you could technically use a symbol for the reg-*
functions.
FWIW, I saw you post this doc on Twitter https://github.com/Day8/re-frame/blob/master/docs/EPs/0001-CaptureHandlerMetadata.md. We are using an internal re-frame wrapper that has an API almost identical to the one described. It has been working well for us.
Example:
(rf/reg-event-fx
::transact-workload-tx-data
{::rf/spec (s/cat :on-success ::rf/event-vec)
::rf/cofx [[::dbu/ds-db]]
::rf/subs [[::settings-subs/workload] [:app/customer-id]]}
(fn []))
Good to know. Any gotchas? Any improvements?
Also, any reason to want to use symbols over keywords?
I've been toying with this idea in my head for the past couple days, which is why I brought up the symbol thing. It seems like all handlers could be defined as functions. Something like this:
(def-event-fx
my-event
"docstring"
{:attrs ""}
[fx event-vec]
)
The attrs map can contain the Spec, signals, or any other re-frame specific attributes.
Can you explain the [fx event-vec]
part?
Also, wouldn't it have to be 'my-event
Oh, wait, you mean for def-event-fx
to be a macro.
But still trying to understand [fx event-vec]
I'm looking at the docs on defn
... and seeing:
(defn name doc-string? attr-map? [params*] prepost-map? body)
(defn name doc-string? attr-map? ([params*] prepost-map? body) + attr-map?)
Which is interesting.
Btw, those docstrings are kind of a lie
They tell you what the behaviour is, but the behaviour is defined by the macro parsing the args, not that that is a valid argument list
AH, got it. Maybe [cofx event]
The Spec doesn't necessarily need to be declared in that attr map either. You could probably find a way to use the built-in function spec definition fdef
.
Not sure if I like this idea yet but if you take this idea to an extreme, you could remove the need for dispatch
. def-event-fx
could declare a function that, when called, takes the event-vec and dispatches the event for the given name
passed in. The def-event-fx
would also register the event handler as the function explicitly declared. For example:
(defmacro def-event-fx
[name docstring attr-map params body]
`(do
(defn ~name
~docstring
[event-vec#]
(rf/dispatch event-vec))
(rf/reg-event-fx ~name (fn ~params ~body))))
(def-event-fx my-event
{}
[cofx event-vec]
;; handle my event
)
;; dispatch the event
(my-event [event args])
Again, not sure I like this approach yet. Just opens interesting possibilities.