Fork me on GitHub
#re-frame
<
2016-08-17
>
mbertheau09:08:28

@mikethompson: Has anyone ever looked at components as subscriptions? They essentially transform data in app-db into hiccup. Subscriptions transform data in app-db into arbitrary data structures. The challenges around dynamic subscriptions, or having input signals for a subscription another subscription instead of the whole app-db, or possibly a parameterized subscription, aren't they the same? Another key difference between them is how components use other components vs. how subscriptions use other subscriptions. Subscriptions never use components as input, but components can use subscriptions or other components as input. The mechanism in components where a component's render function is called again if its input parameters have changed, is the same mechanism that re-runs a subscription when its input signals change, no?

mbertheau10:08:32

Of course a key difference is that components map to react components.

mikethompson12:08:22

@mbertheau: yes, you are absolutely right to make the link. Same process

lwhorton14:08:20

In 0.8 given the shift from middleware (which offers the benefit of closures) to interceptors, is there a way to forward something from :before to :after that might previously have been captured in a closure?

lwhorton14:08:25

(fn debug-handler
    [db v]
    (let [truncated (truncate-event v)]
      (console :log {"Handling re-frame event: " truncated})
      (let [new-db (handler db v)
            diff (clojure.data/diff db new-db)]
        (console :group {"clojure.data/diff for: " truncated})
        (console :log {"only before: " (first diff)})
        (console :log {"only after : " (second diff)})
        (console :groupEnd)
        new-db))))
consider the above debugger (that also truncates huge messages). within closures I only have to call a (potentially very expensive truncate) once, but can use it twice. as an interceptor is it “the right way” to just tack some data like this into context :coeffects :my-truncated-thing?

joshuanjordan14:08:15

@mikethompson: Yes, in my case this is correct. I will only ever have one active wolo at any given time. I thought this is how it was working, but I wanted to make sure there was nothing magic going on; I do not like magic.

joshuanjordan14:08:28

@mikethompson: But what about not closing over the subscribed value in the initial setup form and instead subscribing in the return lamda? This will update values on the screen in the same way that dynamic subscriptions intend to. Is this another way to accomplish the same goal as a dyn sub? Is there a detrimental performance issue with doing it this way?

lwhorton19:08:38

Has anyone played around with https://github.com/Day8/re-frame-forward-events-fx successfully?

lwhorton19:08:49

I cant get it to forward any events yet.. not quite sure why.

lwhorton19:08:38

On closer inspection, there seems to be an issue with using both async-flow and forward-events fx. Possibly related is unregistering on async-flow if providing a db-path will error: Assert failed: :forward-events asked to unregister an unknown id: :async/flow probably something to do with this https://github.com/Day8/re-frame-async-flow-fx/blob/master/src/day8/re_frame/async_flow_fx.cljs#L106

lwhorton21:08:44

Ill keep tracking it down and post an issue if I find anything meaningful

mikethompson23:08:24

@lwhorton: yes, put any data which needs to be shared between :before and :after in context under your own namespaced keyword.

mikethompson23:08:06

But don't put it into :coeffects (within context). That map is strictly for handler inputs. Just plonk it into context itself.

mikethompson23:08:59

This plonk-something-into-context capability is part of the reason why :context is threaded through.

mikethompson23:08:17

@joshuanjordan given active-wolo doesn't change, then what you have will be fine. Perhaps you need a subscription called :active-wolo-details ?

mikethompson23:08:10

@lwhorton: I've played around with re-frame-forward-events-fx successfully. 🙂

mikethompson23:08:14

Hmm. I've been sitting here thinking about this. I can't see any way that re-frame-forward-events-fx and re-frame-async-flow could interact badly. BUT ... I have a feeling that there's one circumstance which might cause re-frame-async-flow to try and deregister itself twice (maybe resulting in the sort of error you report). I haven't yet checked the code ... but I have a question for you ... Do you have a rule set in which the one event might triggers two rules, and both these rules have a :halt true ?? (I'm wondering if that causes two halts, the second of which would display the error you are showing)