Fork me on GitHub

@drewverlee re-frame originally used middleware but switched to use interceptors instead because they achieve the same thing, but in a "data oriented" way rather than a "higher order functions" way. As a result, interceptors are more flexible than middleware.


But I'm not sure if that answers your question. Hard to tell.


Both middleware/interceptors provide mechanism by which you can wrap core functionality (event handling in the case of re-frame) with code that handles cross cutting concerns like logging, integrity checking, coordination, etc. In re-frame we've taken that further and made interceptors responsible for effects and coeffects (thus providing a way for event handlers to be pure).


So they are kinda important/useful in a number of ways.


@drewverlee > This might be obvious, but why call the larger app state “coeffects” Hmm. App state is one example of a coeffect. An important one, yes, but just one example. Be sure to read through all the docs. I feel that many of your questions will be fully answered by what is available in:


I have always wondered the same thing, not knowing the word “coeffect”. The Google did not help. Is that a Britishism?


Good info on coeffects can be found at - the first couple of paragraphs covers it pretty well for a quick definition. I think the terminology comes more from math than anything else but I could be so wrong about that (I tend to ascribe anything I don’t understand to math in one way or another)


Ok, so it is a well-established term, along with context. The term itself sounds wrong for what it denotes, but as you suggest the math term coefficient makes me feel better about the whole thing. 🙂

🙂 4

@ferossgp > Hi! How is better to wrap a component with data fetcher in re-frame? Views in re-frame are not imperative. They simply render the state in app-db. This is at odds with the way things are often done in the js React world. Some further explanation here:

👍 4

Storing data in ratoms which are closed over by renderers is ... to be avoided as much as possible, and is absolutely not the design place to be starting from.


Hi, I’m reading but I understand what would be the reason not to use @(subscribe [:x]) inside a normal reg-sub


I know about input signals but I’m still not sure about all their benefits


@jvuillermet One point is that if you conditionally deref something in the subscription handler, you won't get notified on the changes. With signals, you'll always be notified.


A fragment from the above link that points to this: "Remember to deref any use of app-db and subscribe. It is a rookie mistake to forget. I do it regularly."


Thanks @p-himik ! I’m not sure to understand the first point nor how to reproduce it. Would you have an example ? Also I realise signals allow to have a pure function


Hmm, while providing an example I realized that there's no reason for a user to want the sub to be updated when some sub is not derefed, so disregard my statement above.


The the quoted fragment just refers to forgotten @.

👍 4