Clojurians Log v2

This has helped me zero in on where the complexity/messiness is — not surprisingly, it typically is around operations that have multiple asynchronous steps. Like this one:

[:graph/archive-card :graph/next-card]
 [:graph/callback-archive-card :graph/generate-materialized-cards]
 [:graph/callback-archive-card :graph/load-card-comments-attachments]
 [:graph/callback-archive-card :graph/load-list-card-counts]

We ended up mostly breaking our event.cljs up into files under events that matched our views using namespaced keywords for the events. We kept the subs in a global subs file at least for now.

Whoa! What a super, super idea!!! Thank you!!!

Thanks so much for the suggestion, @rberger. PS: as I’ve been studying what has been tripping me up in the events, one of them is the lack of “information hiding.” In the global db, I have the raw list of Trello cards, and a “materialized view”, where filters are applied and other things I don’t remember. I had some events inappropriately accessing the raw list, instead of the materialized list… I’m now pondering how to keep certain parts of code from seeing the raw card list, lest I make the same mistake again… (Maybe I nest certain elements in the global db into an area called, :private-do-not-look-or-touch` — as they are the “model,” not for the view?)

I support the idea of namespaced events. I usually partition my app by views/usage with an additional general “components” folder for generic components. I think the challenge is to make a trade off between generic events and reasonability/locality of your logic. Moreover, you need the discipline to avoid calling events from other views, except the general one.

@neo2551 This sounds super interesting, as well — so to make sure I’m processing this all correctly: Option 1: @rberger suggests breaking up the events namespace, which I’m guessing are all required into the main events.cljs. This has the benefit of organizing the events, modularizing, information hiding, etc. Option2 : @neo2551 suggests going beyond just splitting up the events namespace, but actually creating separate dbs/events/subs, as per: http://day8.github.io/re-frame/App-Structure/ I think in my case, I’m going to try Option 1, because I’m not quite ready to distangle everything yet — but making separate piles of events is something I can manage. 🙂 thank you, all!

The advantage of having fully qualified namespace is also to know where they are defined. But good luck :)

@genekim We don’t require the events/*even.cljs in the top level / global events.cljs. We just require them as needed in the usually parallel views/*view.cljs files. Our current project did evolve from a global events.cljs to this model and I susepct we may eventually evolve to something like what @neo2551 suggests. But evolution is good. Learn as you go. One thing good about having them all in a global events though, is no worry about circular dependencies. It hasn’t bit us hard, but it has bit us a few times. Usually a bit of refactoring/rethinking fixes that.

I’ve seen this problem in Redux too. I think this is a problem with event-driven architectures. Maybe these could help make sense of the dependencies: 1. Logging: you see what event happens before/after another event. Even while running tests or playing around with the app (checkout https://github.com/day8/re-frame-10x) 2. Make the other end visible: similar to what you did but make subscriptions visible - what view listens to what change? (view -> sub -> event) could complement your event list

I second using re-frame-10x. Our app has an event call graph at least as convoluted as yours, but I find it very manageable with 10x. Instead of trying to discern the flow of events or the contents of app-db from the code, I simply run the application and observe its behavior using 10x. To make event flows more explicit in the code, you can use https://github.com/day8/re-frame-async-flow-fx but it has a lot of overhead so it's only recommended for the initial boot of your app, after which it gets disabled. The call graph program you created sounds very cool! I think 10x could be made even more powerful if we had a visual representation of that (I know there's a similar issue for visualizing subscription graphs).

Love the syntax https://github.com/day8/re-frame-async-flow-fx#flow-as-data @regen This makes event-chains easy to read. The docs say the main purpose is for sequential app-boot logic. Why isn’t this flow-syntax used for chaining events in any stage of the app’s life-cycle? My hunch is it’s too much overhead for chaining 1-2 events together, and if you have long chains you’re probably doing something wrong by structuring your flow of data that way?

@joservarelaf I think there are scenarios where you are forced to structure long event chains of HTTP requests during an app's lifecycle, maybe because of a badly designed backend API. The overhead of async-flow-fx comes from it using forward-events-fx to forward all events to the async-flow event handler, in effect causing everything to be dispatched double. I wonder if you can make something similar using an interceptor instead, and then injecting that into all the participating event handlers. I think there are some places in our app that could benefit from this, as currently we're manually checking some part of app-db in every event handler in the chain, to be able to tell which parallel events have completed and which have not, and when it's ready to move on to the next step. It's something I'll try exploring when I find an excuse to do it during worktime. 😼

Holy cow! I LOVE the idea of `re-frame-async-flow-fx`!!! Thanks for all your help on this — I’ve had a bit of a breakthrough that has allowed me to build what I want to build… but it’s made it pretty clear that I need to clean my mess up somehow. But I’ve been thinking about all y’all’s advice on how to think about reorganizing — I’ll keep you posted on my plans. (After I finish building this one feature, that’s got me so excited, I woke up early this morning to tackle! 🎉)

And here’s the graphviz rendering of my horrible event dispatch graph. :)

Thanks for sharing the graph! That is very nice, I imagine it would be useful to have for every re-frame project.

For y’all’s consideration and comment — I wrote up how this graph helped me get something done. If y’all think it’s solid enough, I’d love to post to this channel and @ mention Mike Thompson.

Many thanks in advance!

Ooops! Forgot to post the link!!! https://docs.google.com/presentation/d/1yf6f7OYFWYADZ59nrSSNWjiw8zf-yt60yBjWqrJFPdA/edit#slide=id.p

Nice!

@genekim in this case, what did you end up doing with the output? Did you rearrange some of these relations?

Got it, “Countermeasure” explains what you ended up doing

Great catch — new title. :)

Thx @joservarelaf !

It’d be awesome to show a chart like that and highlight the bubbles as the events are ocurring. Imagine running your app at ‘slow speed’ and seeing the event flow go through the graph.

Or a debugger step-through.. click, click, click and the graph moves

That blows my mind — that’d be amazing! (Maybe motivation to get a wrapper around MermaidJS… could dynamically render the graph…)

@joservarelaf Just added screenshot of your idea to the deck. 🙂

haha thanks! what’s this deck are you giving a talk?

hmmm maybe this is a great excuse for me to get started with clojure

Oh, just the Google Slides you already saw — no intent to present it. It’s just easier to write in bullet points than actual full prose. 🙂 (PowerPoint/Slides is the tool for the lazy, which isn’t always a bad thing — it’s so efficient. 🙂

Agree! Been doing something similar too: when there’s something I want to think more about, I schedule a talk at a local meetup (nothing fancy) to force myself to come up with a coherent story hehe

I would look at react-cytoscapejs for rendering networks with a functional interface. I am using it at work and it seems decent.

Looks awesome! Thanks for the tip

Check this out, similar to re-frame-10x: https://github.com/flexsurfer/re-frisk Has a feature similar to what we’ve been talking about: https://github.com/flexsurfer/re-frisk#graph-accumulated-for-an-app-life-with-weights-important-with-lots-of-subscriptions-rendering-might-be-slow

I had no idea re-frisk had accumulated all these features! I thought it was just a app-db explorer.