Fork me on GitHub
#re-frame
<
2018-04-11
>
robert-stuttaford03:04:57

@danielcompton if i get Error compiling debux/common/util.cljc when integrating the newest 10x, what’s the remedy?

danielcompton03:04:15

Not quite sure, I haven't figured out what the problem is

danielcompton03:04:25

It seems to be related to the ClojureScript analyzer not being available

robert-stuttaford03:04:31

using :none; no advanced compilation stuff involved

danielcompton03:04:33

But I can't see why it wouldn't be available in your project

danielcompton03:04:02

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

robert-stuttaford03:04:23

just in case it helps, here’s the full strace

danielcompton03:04:42

Yeah the actual exception thrown above that one talks about analyzer api IIRC

robert-stuttaford03:04:42

it occurs when i cider-refresh

robert-stuttaford03:04:55

interesting, (require 'debux.common.util) works fine before i attempt a refresh. so perhaps it’s some sort of odd race issue

robert-stuttaford03:04:48

anyway, i’ve rolled back to the previous version for now 🙂

danielcompton03:04:32

Hmm, so it works ok with the previous version? Will need to do a diff. Remind me which versions you were trying?

danielneal11:04:39

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

danielneal11:04:05

(in cases when both would work technically)

mikethompson11:04:22

effect handler should be the first weapon you reach for. :after handler in an interceptor the second

danielneal11:04:37

ah ok - so if I can do something in an effect handler - do it...

mikethompson11:04:00

effect handlers are simpler

mikethompson11:04:14

:after in interceptors more powerful, but a bit more work

danielneal11:04:29

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 🙂

mikethompson11:04:47

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

deg12:04:03

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)

kanwei18:04:59

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

javi18:04:55

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

kanwei18:04:16

you have to start the process with (reagent/render [search-plugin] attached-element)

kanwei18:04:57

ok, seems like you can just add parameters in the vector

javi18:04:56

> (reagent/render [search-plugin] attached-element) sure and yeah, pass parameters in the call

kenny20:04:49

Why are handlers (e.g. effects, subs, etc.) defined with keywords instead of something like a symbol (i.e. a function-like definition)?

mikethompson20:04:40

@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

mikethompson20:04:46

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

kenny20:04:57

Symbols are data and can be namespaced.

kenny20:04:38

Oh interesting. I didn't realize you could technically use a symbol for the reg-* functions.

kenny20:04:18

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.

kenny20:04:46

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 []))

mikethompson20:04:00

Good to know. Any gotchas? Any improvements?

mikethompson20:04:48

Also, any reason to want to use symbols over keywords?

kenny20:04:13

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

kenny20:04:54

The attrs map can contain the Spec, signals, or any other re-frame specific attributes.

kenny20:04:21

This will also play really well with editors because it mimics the defn format.

kenny20:04:28

I've also found namespacing everything provides a good structure.

mikethompson20:04:38

Can you explain the [fx event-vec] part?

mikethompson20:04:20

Also, wouldn't it have to be 'my-event

mikethompson20:04:21

Oh, wait, you mean for def-event-fx to be a macro.

mikethompson20:04:19

But still trying to understand [fx event-vec]

mikethompson20:04:30

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

mikethompson20:04:59

Which is interesting.

danielcompton20:04:13

Btw, those docstrings are kind of a lie

danielcompton20:04:07

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

kenny20:04:20

[fx event-vec] are the args to the handler.

kenny20:04:57

(reg-event-fx
  ::thing
  (fn [fx event-vec]))

mikethompson20:04:19

AH, got it. Maybe [cofx event]

kenny20:04:27

Yeah, sorry 🙂

kenny20:04:25

But I think that structure is good. I haven't written any code to implement it yet.

mikethompson20:04:19

Yeah, interesting. Will dwell.

4
kenny20:04:29

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.

kenny23:04:28

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.