This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # asami (3)
- # babashka (3)
- # beginners (45)
- # boot (3)
- # calva (6)
- # clojure (26)
- # clojure-dev (16)
- # clojure-europe (15)
- # clojure-norway (6)
- # clojure-uk (6)
- # clojurescript (34)
- # community-development (4)
- # conjure (3)
- # datascript (4)
- # datomic (4)
- # emacs (21)
- # events (1)
- # fulcro (16)
- # graalvm (5)
- # jackdaw (1)
- # kaocha (5)
- # lsp (74)
- # malli (8)
- # nbb (37)
- # off-topic (50)
- # pathom (5)
- # reagent (19)
- # ring (1)
- # shadow-cljs (60)
- # sql (3)
Hi. I'm playing around with the canvas element and stuck on some rendering issue. The following code is triggered at a button press. It compiles without errors, the console logs the message, but the canvas doesn't update. I can then run the code from
(.fillRect...) in the repl and it will correctly appear in the canvas element however.
Similarly, when I click on the "stop" button, the following code is executed. I'll get the console message, and the buttons appropriately disabled/enabled, but the canvas won't clear. If I then run the
(defn draw-board [board canvas] (js/console.log "drawing board") (set! (.-fillStyle (:ctx canvas)) (:color-1 canvas)) (for [[idx cell] (keep-indexed (fn [j val] (when (pos? val) [j val])) board) :let [row (int (/ idx row-width)) col (mod idx row-width)]] (.fillRect (:ctx canvas) (* row res) (* col res) res res)))
(for ...)expression in the repl, it clears everything as desired. What am I missing between the behavior in the repl vs executed in these function blocks? Thanks for your insights!
(defn end  (js/console.log "ending") (for [ctx (reduce (fn [acc el] (conj acc (:ctx el)))  [canvas-1 canvas-2 canvas-3])] (.clearRect ctx 0 0 width height)) (set! (.-disabled (.getElementById js/document "stop")) true) (set! (.-disabled (.getElementById js/document "start")) false))
for is lazy and does not execute since you never consume the result. just swap
doseq and it'll do what you expect
doseq is just for the side effects and has no return value. if you need the return value then you need
@roman01la (+ Pitch crew) — I know you’ve invested a bunch in performance lately… I would be super curious to understand how you’re identifying bottlenecks. Do you profile in a synthetic environment? Do you instrument in production?
Hey. Custom performance metrics on the client (DataDog) + customer feedback + internal feedback via dogfooding. We didn't have any success with synthetic performance testing, I know some are running Lighthouse on CI to measure loading time and Web Vitals, but we are mostly interested in runtime performance (UI interactions, navigation, FPS while moving stuff, etc.)
yeah we’re also more interested in runtime performance. One thing we’re doing is pointing a bunch of chrome instances at the same shared space to generate and measure behavior under load. That does provide some insight but I think we haven’t quite figured out how to capture runtime performance metrics. Do you measure component render times or stuff like that? Curious what you’re tracking specifically
We are tracking UI interactions and router navigation. It's time from user input (click) to when expected UI was painted. The measurement is done via performance.mark/measure.
I have this deck that touches on measurements https://pitch.com/public/60124cc4-0674-4253-955a-1f8540866ae7
(defn get-questions "Call the API and return the data in clj"  (-> (.fetch js/window (str config/api-server-base-url "/v1/questions")) (.then #(.json %)) (.then (fn [resp] (-> resp (tap>) (js->clj :keywordize-keys true)))) #_(tap>) #_(.-body)))
I would have expected it to be resolved by then and return me the proper Clojurescript map?
The promise is resolved. But it's still a promise.
Promises never get "unpacked" within the context where you use them.
.then exists specifically for you to be able to access those "packed" values.
Well, no way around that - that's just how JS operates. I'd just do exactly what you deem ugly. :) It's both the simplest and the easiest solution.
And I'd also change that docstring to reflect the fact that the function does not really return the value itself. ;)
I understand this is likely due to async, and the 2nd call actually does return the expected count of 3 i’m looking for
That's not a problem by itself because you are not supposed to use subscriptions outside of a reactive context (i.e. views or other reactions used in views). When you update app-db with a help of an event, any deref'ed subscriptions will notify their reactive context in due time, and those contexts will update themselves (views will be re-rendered, reactions will be recomputed - but only if they're themselves deref'ed in a reactive context).