you don’t tablecloth to run in sci for this, here’s the basic structure that should work regardless of where the data is coming from:

(ns scratch
  (:require [nextjournal.clerk :as clerk]))

^{::clerk/sync true}
(defonce !offset (atom 0))

(comment
  (swap! !offset inc))

(clerk/vl
 {:data {:values [{"a" "A" "b" (+ @!offset 28)} {"a" "B" "b" 100} {"a" "C" "b" 43}
                  {"a" "D" "b" 91} {"a" "E" "b" 81} {"a" "F" "b" 53}
                  {"a" "G" "b" 19} {"a" "H" "b" 87} {"a" "I" "b" 52}]}
  :mark "bar"
  :encoding {"x" {"field" "a" "type" "nominal" "axis" {"labelAngle" 0}}
             "y" {"field" "b" "type" "quantitative"}}
  :embed/opts {:actions false}})

(clerk/with-viewer {:render-fn '(fn [_] [:div [:button.bg-sky-200.p-2.rounded {:on-click #(swap! !offset inc)} "inc"]])} {})

Thanks for that @U5H74UNSF 👍

@U5H74UNSF should these buttons work when "built" an exported as html?

(clerk/build! {:paths    ["notebooks/scratch.clj"]
                 :bundle   true
                 :out-path "."})

Currently it seems to only produce a static version of the notebook with whatever the value of the atom was at build time

correct, they won’t work in the static build

thanks

@U5H74UNSF can you advise whether it's possible to create a version/build that would have working buttons? Just not sure where to start working towards

you can get working buttons if you move the state fully into the frontend and do things with cljs only

but that means pushing everything to the browser which might or might not be viable, depending on the size of your dataset

also it limits the libraries you can use, certainly tablecloth won’t work in the browser afaik

that's really helpful thank you 👍 Seems like a lot more development for something I use quite casually, so maybe at this point not worth the effort. And as you say it may not even work!

yeah, also wouldn’t recommend going down this path for now. We also have something in the works that should make it easy to deploy a clerk notebook with a JVM so the buttons would work in that case. Will keep you posted here when it’s ready to try out.

Sweet, thanks!

Nice monkey saddle 😄

I'm running off of a branch, which is a few weeks old, if that helps provide context. I'm not well-versed in how clerk determins that URL, so I may be missing osmething obvious

I'll keep digging...

ah yeah, so this is a branch of clerk?

try running with bb dev to have clerk build its js

thank 8^)

bb dev works for me on that branch

I'll circle back to figuring out how the local resource load vs loading assets from clerk.garden works

Me having issues running from a branch is not a priority for your time, IMO

I got enough material now to figure this out

what you’re seeing is expected

I'm assuming that somehow my frontend assets hash changed so I'm looking for one that doesn't exist

when you don’t run bb dev (which starts shadow-cljs and compiles it’s own js) clerk computes a hash using https://github.com/nextjournal/clerk/blob/d80187013d7b7b96db3d8b114b8d99f687170668/src/nextjournal/clerk/render/hashing.clj. If you have local changes we won’t have a js bundle for that hash (this will only be built & uploaded on CI on push).

yah, am surprised at the "having local changes part" but I'll get to the bottom of that

yeah exactly. If you touch any file that’s part of the hashing you’ll run into this problem.

and found it...

the hashing part is only mean to be used when using clerk as a library, not when developing on clerk

I'm just confused as to why that worked after I made that change, but that was on June 15th, so my memory of details there will just lead me astray 8^)

yah, changed a cljc file... that would do it.

also you’d see the effect only after a restart

(I think, I always use bb dev)

yah, that's almost assuredly what happened

might be nice to show a good error when this happens pointing folks at bb dev

it was the change to remove the print-method on keywords...

but can’t think of an easy way now, problem is without a js bundle it’s hard to show a good error 🙃

my first thought goes to building the bundle and then serving it up from the clerk webserver as a resource

and checking if the file exists at the url is also not always possible from the JVM thanks to stupid enterprise IT firewalls…

that’s what bb dev does

but if you started without the :dev alias we can’t build it

yah, so in my use case, I'm using clerk as a dep in my project. We start up a repl or clerk...

ok, but you were using a :local/root dep of clerk?

no actually, a git commit

ah but a commit of a fork from you

and now I get why that doesn't solve this..... because that's not running from an explictiely built jar, but just a checkout...

which doesn’t have clerk’s CI setup

so the bundle wouldn't be there...

ayup

yep

and I don't really wanna be yarning in my clojure app 8^)

right

hmm, maybe I should just use "bb jar" ...

there’s an override to fix this

Hmm, all I can think of that is relevant would be the :ssr one for static building

in my case, I am wanting to support dynamic notebook dev

it's a big data collection/analysis tool... want to have clj -M:run clerk start up a clerk server and analysts can existing ntoebooks and create their own

clj -M -e "((requiring-resolve 'nextjournal.clerk.render.hashing/dynamic-asset-map))"
{"/js/viewer.js" ""}

run this from clerk upstream (e.g. main)

then add this to your deps.edn alias

:jvm-opts ["-Dclerk.resource_manifest={\"/js/viewer.js\" \"\"}"]

this way you can override the asset map from the computation to a fixed value

oh, sweet

that's pretty baller

the versions should line up though, so best use e.g. the closest ancestor commit that’s upstream

that resoruce_manifest indirection is handy eh

thanks, this will let me use the clerk notebook sin the workshop I'm doing with analysts next week

glad to help

oh and I learned about requiring-resolve

which I swear I end up writing every project...

yeah, that’s fairly recent (added in 1.10) and useful