Clojurians Log v2
nextjournal
Hi! Just started playing with Clerk, wonderful tool! One question though: is it possible to prevent a form from rendering? I have some deeply nested forms that Clerk tries to render completely and it slows down the browser to the point it is not usable anymore.
Hi, is that using the latest version of Clerk (0.3.220)? If not, please try an upgrade. If yes, I'd love to see the date, can you share it?
Yes it’s the latest version. Basically it’s a any data produced by libraries like https://github.com/davidsantiago/hickory that parse HTML into edn. So it’s basically trees where each level does not have that many children, but the depth of the tree can be huge at places.
I presume Clerk chokes on it because it looks at counts for collections
(require '[hickory.core :as hick])
(-> ""
slurp
hick/parse
hick/as-hickory) ^ this should produce a data structure to test with
I'm trying out Clerk, it's really promising to me, I like it seems to be similar to a hot-reloading clojurescript project where you keep your namespaces fresh. I do have an issue:
(require '[ :as io]
'[xtdb.api :as xt])
(defn start-xtdb! []
(letfn [(kv-store [dir]
{:kv-store {:xtdb/module 'xtdb.rocksdb/->kv-store
:db-dir (io/file dir)
:sync? true}})]
(xt/start-node
{:xtdb/tx-log (kv-store "data/dev/tx-log")
:xtdb/document-store (kv-store "data/dev/doc-store")
:xtdb/index-store (kv-store "data/dev/index-store")})))
(def node (let [_run-at #inst "2021-11-10T15:09:43.090-00:00"]
(start-xtdb!))) start-xtdb! seems to be called again, which causes the notebook page to error because of lockfiles in the db. I expected the _run-at trick would work for this kind of issue.great to hear you find it promising. So in general I’d advise against using the run-at / inst trick for stateful things you only want to happen once since they will not be called if clerk caches them across restarts
also Clerk has a threshold built in and doesn’t consider things that execute faster than that worth caching
can you use some other mechanism like an atom or another side-effectful check to make sure this happens only once?
I haven’t done much / any of stateful things like that so I’m eager to learn what the best approach here is 😼
(defonce node ...)?
Ah, the threshold thing explains my surprise. I'm also doing a bunch of stateful mutations to the db in the namespace but it's not a big deal. Although perhaps meta for "cache this anyway" would be useful. Or as @borkdude said, in the cljs world I use defonce for this stuff!
(declare node)
(def node
(if (bound? (var node))
node
(start-xtdb!)))why not defonce ?
oh that sounds like another bug in Clerk
Oh, I haven't tried defonce, I thought that was a cljs only thing 😅
it's not ;)
does that work? Though I think you should tag that with ^:nextjournal.clerk/no-cache then. Maybe something we should do automatically?
but not sure, maybe you do want a defonce to be cached…
isn't that the idea of defonce ? execute only once, regardless of how many times you reload
did a defonce end up serving your needs here?
Is the letfn callback throwing this off maybe? Let me check.
that was not it 😞
Is it possible in Clerk to render a form's output without its source code (like how Nextjournal provides a "hide source" option)?
not yet
but certainly planned
main difficulty is the names of the options, think we might want to allow hiding the code and/or results with and without the ability to unhide them
I think there are 2 use cases: 1. hide all code 2. hide individual code forms How to realize this is indeed not simple
Another small Clerk release following yesterday’s table viewer release: Clojars: https://clojars.org/io.github.nextjournal/clerk/versions/0.3.233 Changelog: https://github.com/nextjournal/clerk/blob/93c19314e4e657075176667781d38c0c15fa29ef/CHANGELOG.md#03233-2021-11-10