@dfcarpenter some example apps listed in here https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md

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

Have a read through: https://github.com/Day8/re-frame/blob/master/docs/Interceptors.md and look at the standard interceptors: https://github.com/Day8/re-frame/blob/master/src/re_frame/std_interceptors.cljc

@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: https://github.com/Day8/re-frame/blob/master/docs/README.md

@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: https://github.com/Day8/re-frame/blob/master/docs/FAQs/LoadOnMount.md

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.

IMO

Hi, I’m reading https://github.com/Day8/re-frame/blob/master/docs/SubscriptionFlow.md#reg-sub-raw 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 @.