@metametadata so it looks like Carry provides a more organized signal dispatch system, based on a pseudo FSM blueprint model, and you can basically plug-in any of the other frameworks with it (e.g. reagent) ?

@albaker I think it does resemble a FSM, in a sense, but the the terminology is not the same and it happened accidentally anyways 🙂 Yes, using any UI framework (reagent, rum, etc.) was one of the goals. Another goal was being able to implement time traveling debugger. This explains why there are 2 kinds of "events" distinguished: signals and actions. Only actions (model mutations) can be replayed. In this regard it looks very similar to VueX architecture (https://github.com/vuejs/vuex). Funnily enough, I haven't used the provided debugger for work because its GUI is not useful with big models yet 🙂

quite close to using in production here

although if starting anew, would reconcider re-frame, for it has subscriptions and maybe more eyes are looking at it 🙂

might be that the “any ui framework” goal made understanding how data is passed to reagent a bit complex, at least for me

@viesti do you mean the carry signals have some issues compared to re-frame subscriptions? I kind of liked the blueprint/signal as a way to tie everything together

signals/actions are for changing state, subscriptions (in re-frame) are for observing state

@viesti nice to know that someone uses it! Yeah, although re-frame is definitely more battle tested, I feel pretty confident about the Carry pattern since it closely resembles the other "proofed" frameworks like Redux and co. Speaking about hidden bugs, there's not much LOC to break in the core, so potentially error-prone code can be mostly in additional packages, e.g. carry-history. I see your point about passing data. Maybe I could a better job explaining the Reagent reactions, at the moment it's kinda terse and points the reader to learn about them elsewhere.

Do you have any examples of particular pain points that subscriptions could solve better (vs. using raw Reagent reactions as in Carry examples)?

maybe a case when app state becomes larger

on how to pass state onwards from root component to leaves

I'd think that explaining reactions would help too

I had made one React Native app so redux was familiar and the lack of behind-scenes global state made carry appealing (although the latter point might not be a deal-breaker for me now)

Got it, thank you for your input! Speaking about Reagent, I think I also stumbled upon the same problems: it was not always obvious how it would redraw the screen depending on the wiring between the components. I think that it's primarily a problem with Reagent and one would have the same struggles at first with any React wrapper 😄

To deal with a bigger app I use the approach from this example: https://github.com/metametadata/carry/tree/master/examples/blueprint-splitting-hof. E.g. view-model is merged from several smaller view-models residing in independent folders (where folder is created per screen).