Fork me on GitHub

Hmm. An easy issue from which to get a paper cut.


I wonder how we should better communicate that


Maybe create another [sub]tab for the current state of app-db and show a small but noticeable warning when the shown state is different from the current one? Even if that doesn't make sense, I think having an ability to view the current state of app-db would be useful.


re-frame-10x is epoch oriented.


it allows you to step forwards and backwards


It shows you what "happened" in the processing of each epoch etc.


So the right design will need to fit into that central paradigm


So the challenge is to communicate that events don't get collected when the panel is not showing.


Or, more on the point, just show a warning to the user when they open the re-frame-10x panel "events dispatched which this panel was closed will not have been collected". Or, maybe, always clear out all trace when the re-frame-10x panel is openned.


Just thinking out aloud


> epoch oriented That's not entirely true. In the Trace tab, you can see traces real-time.


I don't think that re-frame-10x would become less useful or intuitive with some not epoch-oriented tools.


The epoch oriented approach is baked deeply into the design. It influenced all thinking. Not sure I want to abandon all that just to handle a small communication problem ("no events were collected when the panel was shut")


I'm not talking about abandoning anything. I'm just saying that there're different ways to help a developer.


Sure. I'm saying that there is a paradigm (epochs) around which everything in re-frame-10x is designed. Everything. Seriously, it completely permeates the entire app. So, it is hard for me to see value in breaking (abandoning) that model, to handle one side case where a simple bit of well placed warning text might well suffice.


So, my original question was "I wonder how best to communicate ..."


Not everything. I already mentioned "Trace" tab, it has "Only show traces for this epoch?" checkbox. How is it handled then if it does not break the epoch model?


Note that unchecking the checkbox not only shows traces for other epochs, it also shows traces real-time. E.g. reagent's :render.


Being able to (optionally) see trace across epochs or intra epochs does not mean epochs are not critical or central. In fact, just the opposite IMO. But let's move on because my design aesthetic is not going change. I'll figure out a way to make the necessary communication, and hopefully this problem will disappear


If your goal is to simply see the current state of app-db re-frisk does a great job. It will give you exactly what you want.


re-frame-10x tries to do something else/more


Hmm, thanks for reminding me about re-frisk. I completely forgot about it after I moved to re-frame-trace.


what do people do for things with global scope ? we've currently got a couple of global vars around (including re-frame.db/app-db ) and i'm considering adding another var - but wondering if there are any more principled approaches around


@mccraigmccraig Except for things with very local scope, I've been pretty happy stuffing it all into app-db.


@eggsyntax ah, i should have clarified - i'm looking at things which are not "pure serializable data" such as a websocket and now an app-context map... all the pure serializable data goes in to app-db

✔️ 4

I haven't had to confront that particular problem with re-frame, so no useful input there, I'm afraid. If you can count on them being singleton-ish, I'd be inclined to make them global vars like you are.


yeah, that will be my approach if no-one comes up with anything better


@mccraigmccraig maybe something like mount/component?


it’s actually for my own app-context builder (along the lines of component, but less invasive and promise-friendly) that i’m wanting this global... but it doesn’t help me with where to put it


For WebSockets I created a separate fx handler. The global atom is stored just where the fx handler is defined.


cool - that's where i'm leaning towards - a bunch of global atoms with corresponding fx handlers