Clojurians Log v2

@trost.mario the communication in that notebook happens via clerk-eval, which lets the front end send a form to the backend for evaluation 🙂

@jackrusher clerk-eval is so incredibly useful I can’t believe I didn’t discover it earlier. Thanks so much! Should we make it more discoverable by adding a docstring to clerk-eval or mentioning it in the main Book of Clerk?

The examples show a round trip to the JVM backend from the Clerk interface. When you have a sync’d atom you get dataflow reactivity on updates to those values.

For another example, check out this one: https://github.com/nextjournal/clerk-demo/blob/main/notebooks/dictionary.clj

when the input field is modified the backend recomputes the results automatically

Today I was looking at the #application-garden datomic local Todo app example https://datomic-example.apps.garden/. Pretty cool that it's "just" a clerk notebook. I was wondering how the edited todos get to the backend, but the frontend code was hidden, so I checked out the https://github.com/nextjournal/datomic-example.apps.garden/blob/main/notebooks/datomic_example.clj Is this doing the same?

@jackrusher It took me a while, but I think I see the round trip now. Thanks!

You can see some examples in this notebook: https://github.com/nextjournal/clerk-demo/blob/main/notebooks/controls.clj

Thanks! I see that in these examples, the :on-input callbacks use plain cljs.core functions (such as reset!). My question is, is there a way to trigger clojure.core functions (like slurp) on input events instead?

We are still thinking about whether we want to expose a different interface between the front and back end in Clerk because of potential security problems for hosted notebooks.