Clojurians Log v2

@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

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

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

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

Thanks @mikethompson react-table it is then!

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

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. https://github.com/sansarip/peanuts

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

(defc a 
  (fn [& {:keys [a b c]}]
    [:div a b c]))

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

overall, pretty neat

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.

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!

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

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}
      text])
  {:exempt [size]})

[my-button :small "Click me!" #(js/console.log "clicked!")]

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

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?

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

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

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

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

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

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.

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

Exactly my thoughts

ideally:

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

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

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.

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

Yup!

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

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