This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (15)
- # beginners (186)
- # boot (11)
- # bristol-clojurians (1)
- # clara (1)
- # cljdoc (2)
- # cljs-dev (5)
- # clojure (57)
- # clojure-austin (1)
- # clojure-dev (87)
- # clojure-italy (7)
- # clojure-spec (5)
- # clojure-uk (56)
- # clojurescript (18)
- # cursive (29)
- # data-science (10)
- # datomic (84)
- # duct (83)
- # figwheel-main (4)
- # fulcro (42)
- # jobs (3)
- # lambdaisland (2)
- # off-topic (28)
- # parinfer (3)
- # portkey (3)
- # re-frame (28)
- # reitit (7)
- # remote-jobs (8)
- # shadow-cljs (29)
- # spacemacs (30)
- # specter (6)
- # sql (8)
- # tools-deps (60)
he has a couple sample apps, but i opened the only two issues on the repo so far asking 1) is there a simpler example and 2) how do you expect this to be used 🙂
Hi all: from the re-frame docs: > Reagent re-runs reactions (re-computations) via requestAnimationFrame. So a re-computation happens about 16ms after an input Signals change is detected, or after the current thread of processing finishes, whichever is the greater. So if you are in a bREPL and you run the lines of code above one after the other too quickly, you might not see the re-computation done immediately after n gets reset!, because the next animationFrame hasn't run (yet). But you could add a (reagent.core/flush) after the reset! to force re-computation to happen straight away. Is this actually true? If you run the lines of code as described synchronously and quickly in the repl, you always see the update. Same thing if you run the same code in a reagent render method.
You'll notice the call to
rea-enqueue in https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.cljs#L400-L409
Which ultimately leads to processing in: https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/batching.cljs
browsers target 60fps, which is just over 16ms per frame. that's not very long by human standards; even a fast typist at 100WPM only makes a keystroke every 120ms on average.
if you try both commands in a
(do ...) block I think you can see the old data.
I'd like to record all reframe client events to an aws endpoint for analytics. Probably kinesis firehouse. I especially want error details to measure client error rates. Has anyone done this before? If so, any samples out there or advice?
I’d look what AWS X-Ray has to offer. It’s a tracing/monitoring tool like New Relic. If also rest of the infra is on AWS, you could setup end-to-end monitoring and get nice service graphs etc. This might be overkill though.
Hmmm on client-side X-Ray it seems like you’d have to use Cognito pools to authenticate in order to be able to talk to the AWS-API via the client-sdk. So it’d be a bigger buy-in to the AWS-stack.
Another valid option would be to use Kinesis and stream the events to ElasticSearch or whatever is the place where you’d roll-out the analysis part. In order to send events to Kinesis directly from Client you need to either a) use the JS-sdk with Cognito pool (as you’d have to with X-Ray) b) use API-Gateway as proxy.
Thanks for the ideas. I'm using cognito so x-ray or kinesis seems sensible. I'm planning to use x-ray for server side observability. I had thought about doing the same in the client but not all events cause http calls which x-ray uses. I'll dig deeper
No problem. There are also dedicated services (outside AWS) for client-side error tracking such as https://sentry.io/ that are probably the easiest way to get started.
You probably only need to create a custom re-frame effects handler for spamming errors to Sentry.
@mikethompson: thanks for the response! I guess I just haven't been able to reproduce the behaviour where "you run the lines of code above one after the other too quickly, you might not see the re-computation done immediately after n gets reset!". If you run the example in the repl:
You see the updated value immediately with the second deref. If you run a similar pattern a render body:
(do (def n (reagent/atom "re-frame")) (def hiccup-ratom (reaction (greet n))) (println @hiccup-ratom) (reset! n "blah") (println @hiccup-ratom))
You also see the updated value the second dereference. This is obviously not what you're supposed to do in practice, just trying to understand the principles by which the reaction machinery works. It just appears that what the computation is re-run with the second dereference, rather than enqueued later?
(do (.log js/console @hiccup-ratom) (reset! n "blah") (.log js/console @hiccup-ratom))
As context, my mental model for this is sort of like what happens in om, where during the render phase, dereferencing a cursor doesn't ever actually return the underlying state of the cursor, regardless of how many times it's changed, it a sync'ed "snapshot" so everything during the render phase sees a consistent app state.
dirty? flag gets set which might allow simple reactions over ratoms to work via a shortcut without animation frames (been changes since I looked deeply), but animation frames are the general mechanism. reactions are processed at the front of the annimation frames before renders
Gotcha, I noticed that dirty flag, but couldn't quite trace it thru the machinery. So barring some non-recommended mutation of app state, allowing the reagent machinery to handler the scheduling of the reactions, you should see a consistent app state throughout the render phase, but that there is nothing inherent in the reaction machinery that enforces that, if you do something non-conventional like a
reset! or a
swap! in the middle of a computation?
Yeah, re-frame will update
app-db (the base ratom) in one step. Thereafter there shouldn't be glitches.
One of the advantages of re-frame is that it causes the "transaction-like" (all at once) update of
app-db, not a piecemeal update process.
Yeah, it makes total sense the benefit that re-frame brings to the model, really love working with re-frame btw, so thanks for that, and also thanks for these pointers, this was really helpful.