Fork me on GitHub
#nextjournal
<
2021-11-10
>
jlmr12:11:17

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.

mkvlr14:11:20

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?

jlmr14:11:38

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.

jlmr14:11:00

I presume Clerk chokes on it because it looks at counts for collections

jlmr14:11:11

(require '[hickory.core :as hick])

(-> ""
    slurp
    hick/parse
    hick/as-hickory)

👍 1
jlmr14:11:02

^ this should produce a data structure to test with

mkvlr15:11:03

@U56R03VNW I can reproduce the issue, thank you!

👍 1
bbss15:11:08

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!)))
But 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.

mkvlr15:11:45

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

mkvlr15:11:22

also Clerk has a threshold built in and doesn’t consider things that execute faster than that worth caching

mkvlr15:11:06

can you use some other mechanism like an atom or another side-effectful check to make sure this happens only once?

mkvlr16:11:04

I haven’t done much / any of stateful things like that so I’m eager to learn what the best approach here is 😼

borkdude16:11:54

(defonce node ...)?

1
bbss16:11:33

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 @U04V15CAJ said, in the cljs world I use defonce for this stuff!

bbss16:11:03

(declare node)

(def node
  (if (bound? (var node))
    node
    (start-xtdb!)))
seems to do the trick without turning into an atom

borkdude16:11:29

why not defonce ?

mkvlr16:11:58

oh that sounds like another bug in Clerk

bbss17:11:07

Oh, I haven't tried defonce, I thought that was a cljs only thing 😅

borkdude17:11:19

it's not ;)

mkvlr19:11:58

does that work? Though I think you should tag that with ^:nextjournal.clerk/no-cache then. Maybe something we should do automatically?

mkvlr19:11:33

but not sure, maybe you do want a defonce to be cached…

borkdude19:11:02

isn't that the idea of defonce ? execute only once, regardless of how many times you reload

mkvlr15:11:26

did a defonce end up serving your needs here?

bbss15:11:34

Is the letfn callback throwing this off maybe? Let me check.

bbss15:11:41

that was not it 😞

respatialized18:11:15

Is it possible in Clerk to render a form's output without its source code (like how Nextjournal provides a "hide source" option)?

mkvlr18:11:57

but certainly planned

mkvlr18:11:11

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

Carsten Behring09:11:48

I think there are 2 use cases: 1. hide all code 2. hide individual code forms How to realize this is indeed not simple