@franklineapiyo You might have to use a React component for your table @grant.isom Assuming that HTTP work is done by something like re-frame-http which is is an effect So what you do is to overwrite the effect handler so it does nothing

Grant Isom 2020-08-10T15:18:30.308200Z

@mikethompson I want to instead of queue a http-xhrio event, call a mock response function but struggling how to structure the handler in a straightforward way.


So the "event handler" would still produce the effect (please do this HTTP work), but the effect which would normally action that work wouldn't be mocked out to not actually do it


Maybe: also see re-frame-test ? Not that it provides a solution to the exact problem you raise, but it might be adjacent to your requirements. BTW, to mock an effect handler just registering a new effect handler using reg-fx replacing the previously registered effect handler

dpsutton 2020-08-08T01:57:59.256400Z

Anyone know of any work towards integrating dev cards and reframe?


@dpsutton It is not straight forward because of the global state in re-frame Some have worked out a way to break through that via various hacks ... but I'm not sure what they are


Perhaps the easiest way is to isolate the views themseleves from re-frame itself. Ie. do the subscriptions in an "outer" component, and pass in data and callbacks to an inner component, which is re-frame free


Then the inner component is re-frame free (just Reagent) and that can be plonked into devcards.


But this is all theory from me. I've never done it for real

dpsutton 2020-08-08T04:26:50.261Z

Yeah. Looking at that now. Not sure how it will work out in real life but just seeing if there was anything better

Franklin 2020-08-08T05:31:09.261200Z

Thanks @mikethompson react-table it is then!

genekim 2020-08-08T07:10:39.262800Z

Another fun discovery, when I accidentally created an endless dispatch cycle — very obvious in the graph! 🙂

uosl 2020-08-08T11:28:55.263200Z

I had no idea re-frisk had accumulated all these features! I thought it was just a app-db explorer.

thelittlesipper 2020-08-08T21:16:56.270Z

Not sure if something like this already exists, but I made a couple lightweight macros for decoupling Re-frame subscriptions from Reagent Form-1 component-functions. I've been using them pretty successfully for a couple months now, so I thought I'd share. There's a gif in the readme that I think demonstrates the use-case + usage well.

phronmophobic 2020-08-08T21:40:15.270800Z

are there any examples of using a component with keyword args?

(defc a 
  (fn [& {:keys [a b c]}]
    [:div a b c]))
is this the usage? [a :a "A" :b "B" :c "C"]

phronmophobic 2020-08-08T21:41:47.271Z

are default args supported?

(defc my-component
  (fn [& {:keys [a b c d}
        :or {a "A" b "B" c "C" d "D"}]
    [:div a b c d]))

phronmophobic 2020-08-08T21:42:03.271200Z

overall, pretty neat

thelittlesipper 2020-08-08T21:43:59.271400Z

Function arg syntax should work the same as expected in regular-shmegular functions. But the default values for a b c d ("A" "B" "C" "D") can be overwritten if their values are subscription keys and they're not exempted from being subscribed to.

thelittlesipper 2020-08-08T21:44:59.271600Z

If you're referring to subscription args, then that's supported atm with the sub-args option. There should be a section in the readme addressing that use-case. I admit, it can definitely improve!

phronmophobic 2020-08-08T21:53:42.272700Z

what's the reasoning for a component author exempting an argument from being bound to a subscription?

thelittlesipper 2020-08-08T21:58:16.272900Z

If you know that an arg is always going to be / could be a static keyword that you want to use as is, you can exempt it from being subscribed to. For example, here I decide to expect that size could be a static keyword:

(defc my-button 
  (fn [size text on-click]
    [:> semantic-button {:size size :on-click on-click}
  {:exempt [size]})

[my-button :small "Click me!" #(js/console.log "clicked!")]
If I didn't exempt it, then it would be subscribed to, and an error would probably be thrown as I never registered a sub named :small.

thelittlesipper 2020-08-08T21:59:54.273200Z

If defining exemptions from the component-definition side doesn't float your boat, you can also do so dynamically with the exempt metadata from the component-usage side.

[my-button ^:exempt :small ... ]

phronmophobic 2020-08-08T22:02:51.275400Z

right, but what happens if you want to do a gallery or dev cards of all your components and want to see how the component looks under different sizes (ie. you do want to use size as a subscription). can you unexempt?

thelittlesipper 2020-08-08T22:08:06.275800Z

Hmm not sure if I'm understanding the question. In devcards for that use-case you could do something like:

    (fn [size] [:> my-button size (name size) 
                 #(js/console.log (str "Clicked "(name size)))

thelittlesipper 2020-08-08T22:09:07.276Z

You'd only want to unexempt if you'd expect that the size arg could be a subscribable keyword. And, I don't reckon you'd be using subscriptions in devcards, right? You'd just use regular ol' ratoms if anything.

[:> my-button @my-ratom "Size can change according to the ratom's value" ... ]

thelittlesipper 2020-08-08T22:14:24.276600Z

In any case, my recommendation is that if an arg can be a subscribable keyword, don't hard exempt it in the component definition. Just attach the ^:exempt metadata to the size arg when you're passing it in: not subscribing:

[:> my-button ^:exempt :small ...]
[:> my-button ::subs/small ...]

phronmophobic 2020-08-08T22:16:51.278400Z

the question is if it’s possible to override exempt if the component’s creator marked an argument as exempt

thelittlesipper 2020-08-08T22:17:28.278600Z

Ah, atm no. If the creator marked something as exempt in the component definition, then it takes the highest precedence over all other options. But, I reckon I could introduce a feature to override exemptions via a metadata attachment like ^:subscribe.

phronmophobic 2020-08-08T22:23:06.279Z

yea. really cool. I've always kind of though the parent component should decide the subscriptions for its child components

thelittlesipper 2020-08-08T22:23:33.279200Z

Exactly my thoughts

phronmophobic 2020-08-08T22:23:44.279400Z


[my-component 1 (s! ::my-subscription)]

phronmophobic 2020-08-08T22:24:12.279700Z

but in such a way that subscription is tied to my-component, rather than the parent of my-component

thelittlesipper 2020-08-08T22:25:06.279900Z

Right-o, and in a way that one could also just pass in raw data instead of a subscription and expect that to work too - like when testing.

phronmophobic 2020-08-08T22:25:11.280100Z

because [my-component 1 @(rf/subscribe ::my-subscription)] would unfortunately rerender the parent component when ::subscription changes, right?

thelittlesipper 2020-08-08T22:25:22.280300Z


thelittlesipper 2020-08-08T22:25:47.280500Z

That was what I was doing before peanuts, unknowingly, until I started noticing performance hits.

phronmophobic 2020-08-08T22:29:48.280700Z

yea, I'm not sure unexempt is a good idea, but I've been thinking about some similar ideas and was interested to hear what someone else thought