re-frame 2020-08-03 | Slack Archive

sandbags11:08:16

If I am understanding my bug right then I think I've been caught out by this before. That a single signal to a subscription is passed as a value, multiple signals are passed as a vector. Most of the time I am doing single signals and I get used to the idea they are values, then forget when I have multiple signals and get confused. If so, I might prefer that signals always be passed as a vector, even of 1 element, but I suspect that would break too much now.

p-himik16:08:39

They can also be passed as a map.

p-himik16:08:56

And nothing prevents you from wrapping even a single signal in a vector. It's all very simple - the shape of what you return from the signal function is preserved, that's it. A single value becomes a single value, a vector becomes a vector, a map becomes a map.

sandbags16:08:34

I realise now I wasn't clear, I'm taking about using the sugared :<- [:signal] syntax

sandbags16:08:41

if you use one you get a value, if you use more than one you get a vector of values

p-himik16:08:53

Ah, right, I see.

herald18:08:36

I feel you, made the same mistake with :<- many times! Same with forgetting to skip (`_`) the event ID when destructuring. Now all those things are second nature

p-himik18:08:36

Regarding _ - I just always add the trim-v interceptor to my event handlers. :)

herald18:08:29

I sometimes consider that, but then some other part of my brain decides that typing _ is shorter. 😅 What I probably should is write a wrapper around reg-event-*... I wonder if you can do the same for reg-sub to have single :<- return a vector?

p-himik18:08:29

> What I probably should is write a wrapper around reg-event-* That's exactly what I did initially. And then I started using kee-frame that already has that functionality. Regarding reg-sub - you would have to copy and alter the whole implementation of re-frame.subs/reg-sub.

2020-08-03

Channels