This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (98)
- # boot (18)
- # chestnut (2)
- # cider (90)
- # cljdoc (3)
- # cljs-dev (1)
- # clojure (64)
- # clojure-dev (14)
- # clojure-dusseldorf (4)
- # clojure-italy (11)
- # clojure-nl (5)
- # clojure-spec (9)
- # clojure-uk (69)
- # clojurescript (63)
- # code-reviews (2)
- # core-logic (20)
- # cursive (13)
- # datomic (52)
- # dirac (2)
- # emacs (4)
- # figwheel (6)
- # hyperfiddle (13)
- # luminus (4)
- # nrepl (1)
- # off-topic (7)
- # onyx (9)
- # overtone (3)
- # parinfer (3)
- # pedestal (1)
- # re-frame (31)
- # reagent (74)
- # reitit (34)
- # rum (3)
- # shadow-cljs (51)
- # spacemacs (22)
- # specter (7)
- # tools-deps (23)
- # uncomplicate (3)
- # vim (9)
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.
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
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
@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
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