Fork me on GitHub
#re-frame
<
2017-03-29
>
kenny02:03:07

@danielcompton Ah I see. People are worried about it being in their production deps even though it would not be outputted in the :advanced compiled JS file?

danielcompton02:03:14

yeah, like it brings in a d3 dep

danielcompton02:03:35

makes it cleaner

danielcompton02:03:36

so two things: 1. closure defines turns on tracing within re-frame, 2. if you don't want re-frame-trace in your production build then you need to work around it, maybe with dev/prod namespaces, or DCE if you're happy with that

kenny02:03:07

Ah gotcha

andre08:03:45

hi everyone, maybe someone has the information or experience writing a script for automatic code migration from 0.6 to 0.8 ?

mikethompson08:03:58

@andre it only comes down to about 3 global search and replaces (not even that if you can put up with deprecation warnings). Unless you wrote your own middleware, in which case you'll have to rewrite as interceptors

andre08:03:19

thank you, I'll write a migration script

lsnape15:03:48

Is there a way for a :before interceptor to prevent the event handler it’s wrapping around from being called?

danielcompton21:03:04

@lsnape can you give some more context on the usecase?

danielcompton21:03:05

That's what context looks like:

{:coeffects {:event [:a-query-id :some-param]
                  :db    <original contents of app-db>}
      :effects   {:db    <new value for app-db>
                  :dispatch  [:an-event-id :param1]}
      :queue     <a collection of further interceptors>
      :stack     <a collection of interceptors already walked>}
So you could manipulate the queue and the stack in an interceptor

lsnape11:03:33

I have event handlers in the app that are essentially restricted to users with a paid subscription. My idea was to write an interceptor that prevents the event from being fully handled unless the user has a valid subscription.

lsnape11:03:02

I can, however, easily achieve the same with middleware wrapping the function that is registered as an event:

(rf/reg-event-fx
 :show-premium
 (-> (fn [effects _]
       {:db (db/set-view db :premium)})
     (wrap-premium pred on-fail-events)))

lsnape11:03:30

I think for my use case it’s actually more flexible than using an interceptor because I can return side effects in addition to blocking the ‘meat’ of the event handler.

danielcompton17:03:53

I think I'd probably block the events from even being called by not exposing them in the view, but whatever works for you 🙂

danielcompton21:03:50

not quite sure how that would interact with other interceptors though, could be a little bit tricky as their after would be run, but not their before

danielcompton21:03:03

Kinda depends on what exactly you're wanting to do