Clojurians Log v2

Input signals can have something resembling an ID only if you provide it yourself, as nothing prevents you from reusing the same sub in the :<- sugar. So you can do stuff like this:

(rf/reg-sub :x
  (fn [[_sub-id val1 val2]]
    {:val1 (rf/subscribe [:y val1])
     :val2 (rf/subscribe [:y val2])})
  (fn [{:keys [val1 val2]} _]
    ...))

Thanks @p-himik, would you mind sharing it? Side question, how does re-frame know that the subscriptions inside the map have to be deref-ed ?

Sorry, can't - it does a lot more and it was written for a client. But that particular bit is trivial to write. > how does re-frame know that the subscriptions inside the map have to be deref-ed ? Because it requires signal functions to return the data in a specific shape and with specific data.

I see, thank you. So a map in reg-sub is a valid pattern that re-frame is actively seeking, not an arbitrary one

Yes, of course. All of the re-frame's impl is rather straightforward and easy to follow. :)

Thanks!

That would be a nice feature. It reminds me that I've been wondering if subscriptions and flows could become the same construct. Because flows do structure their inputs with a map.

@kimo741 what do you mean by flows ?

It's an alpha feature in the latest re-frame.

https://day8.github.io/re-frame/Flows/

Interesting, thanks

It's so trivial to write - doesn't seem like it would justify potentially creating a rift in the ecosystem where some code bases rely on their own :promise effect (not too hard to imagine, given the generic name) and others rely on what re-frame provides. Those two would become incompatible with each other.

It is indeed trivial, but that's not a reason to exclude it (and to document the process). It is useful for newbies to see how it is done. Many effects are borderline trivial. In terms of a "rift", are you simply arguing for backwards compatibility? Ie. you'd prefer for an id which is less likely to clash with ones used in existing code bases?

As a counterpoint, for my custom effects I use namespaced keywords, so mine wouldn’t collide with this.

It is useful for newbies to see how it is done.What about putting it inside the docs? Newbies rarely browse the actual code, it seems. > Many effects are borderline trivial. Right, but all the ones that are built into re-frame deal with re-frame itself, not some random promise. > In terms of a "rift", are you simply arguing for backwards compatibility? It's like a... second-level compatibility? Or something like that. You won't break any existing code - the worst that would happen is a warning about the :promise effect handler being overridden. However, you will enable people to use the handler instead of writing their own thing that they fully control. And all such code will automatically become incompatible with any other code that has a custom :promise handler. > Ie. you'd prefer for an id which is less likely to clash with ones used in existing code bases? I'd prefer fully qualified keywords for any global things created by libraries and not application code. Even though I myself tend to avoid FQNs, I think library code suffers without them. > for my custom effects I use namespaced keywords, so mine wouldn’t collide with this. Right, but there are other people. :) Of course, it might very well be that not a single person on Earth uses (reg-fx :promise ...). But given that the handler of :promise has absolutely nothing to do with re-frame, personally I'd put it in the docs.

I love these lines from re-frame-fetch-fx: >

(reg-fx :fetch (partial fetch-fx false)) ;; deprecated
> (reg-fx ::fetch (partial fetch-fx true))

I left a comment https://github.com/day8/re-frame/issues/808#issuecomment-2459443081. Please let me know what you think about my idea.