This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-03
Channels
- # announcements (8)
- # aws (2)
- # babashka (16)
- # beginners (173)
- # calva (13)
- # cider (4)
- # cljfx (6)
- # cljs-dev (108)
- # clojure (63)
- # clojure-australia (2)
- # clojure-dev (10)
- # clojure-europe (73)
- # clojure-italy (8)
- # clojure-nl (4)
- # clojure-norway (5)
- # clojure-uk (4)
- # clojurescript (49)
- # clojureverse-ops (4)
- # community-development (3)
- # core-async (23)
- # cursive (3)
- # data-science (5)
- # datomic (25)
- # emacs (3)
- # events (1)
- # fulcro (13)
- # helix (5)
- # introduce-yourself (1)
- # lein-figwheel (1)
- # lsp (36)
- # malli (1)
- # meander (2)
- # membrane (4)
- # music (8)
- # nextjournal (51)
- # off-topic (47)
- # other-languages (5)
- # pathom (31)
- # pedestal (5)
- # planck (14)
- # polylith (5)
- # portal (1)
- # re-frame (30)
- # react (2)
- # reagent (24)
- # releases (1)
- # rewrite-clj (18)
- # ring (9)
- # sci (33)
- # shadow-cljs (49)
- # testing (3)
- # tools-build (21)
- # tools-deps (29)
- # vim (19)
- # web-security (1)
- # xtdb (12)
Hello, I am generating a static version of a notebook by calling clerk/build-static-app!
, and was hoping to be able to use the :git/url
:git/sha
params to generate the nice link back to the git repo of the source, but the url it generates doesn't work if my code (deps.edn) isn't at the root of the git repo. I'm wondering if i'm missing a way of doing this, or whether a new option such as :git/root
would be necessary to support my use case?
How do you generate this url? 'build-static-app' generates a html file. Why not just use absolute url?
I've created an issue and PR for this, sorry for the delay in doing this https://github.com/nextjournal/clerk/issues/99
The idea. Currently every form is treated separately and result is rendered directly under the code, form after form. Is there a way to make a block of forms, rendered them in one piece and results in another under as a one block?
What about this?
(some-form 1 2 3)
(another-form 1 2 3)
;; first result
;; second result
I think block of code lines + block of results would be better here. It can be my personal feeling though
Thinking aloud: I think it's a matter of more compact view and/or ability to overwrite certain styles.
you can do this today:
(clerk/with-viewers
[{:pred vector? :render-fn '#(v/html (into [:div.flex.flex-col] (v/inspect-children %2) %1))}
{:pred #(and (string? %)
(re-matches
(re-pattern
(str "(?i)"
"(#(?:[0-9a-f]{2}){2,4}|(#[0-9a-f]{3})|"
"(rgb|hsl)a?\\((-?\\d+%?[,\\s]+){2,3}\\s*[\\d\\.]+%?\\))")) %))
:render-fn '#(v/html [:div
[:div.inline-block.rounded-sm.shadow.ml-2
{:style {:width 16
:height 16
:border "1px solid rgba(0,0,0,.2)"
:background-color %}}]
[:span.font-mono.text-xs.ml-2 %]])}]
["#571845"
"rgb(144,12,62)"
"rgba(199,0,57,1.0)"
"hsl(11,100%,60%)"
"hsla(46, 97%, 48%, 1.000)"])
mhm... (with jupyter, I wanted to show that several froms can be combined to get forms block + results block, instead of interleaved view)
I mean I have to write another function for seqence of colors/palettes/gradients. Or add some logic to my viewer function (🎨)
I don’t yet see how we can automatically do it… We need some way to signal that it should render multiple results?
Maybe double newline can be an indicator to render a block?
(code 1)
(code 2)
(code 3)
(code 4)
(code 5)
Anyway, that's just an idea. I'm aware that's a breaking change request but maybe there can be an option to set by user to choose the method of block vs line-by-line rendering.
still would like to understand a bit better what you don’t like about the vector option?
I'm not saying I don't like 🙂 I need to write a piece of code which will render it properly. That's all.
(clerk/set-viewers! [{:pred vector?
:render-fn '#(v/html (into [:div.flex.flex-col] (v/inspect-children %2) %1))}])
another possibility would be for us to add this as a default named viewer to Clerk, then it would be selectable via metadata like this
(clerk/set-viewers! [{:name :flex-col
:render-fn '#(v/html (into [:div.flex.flex-col] (v/inspect-children %2) %1))}])
^{::clerk/viewer :flex-col}
[:one
:two
:three]
yes, been talking to @U07SQTAEM about this and we want this as an option as well.
I’m a bit concerned about adding it too soon though because then it’s no longer obvious how to do some of those things. @U4FSZE57V maybe we find a elegant way to unhide it on demand.
(ns {^:nextjournal.clerk/options #{:no-cache :hide-tags :some-other-option}} notebooks.color)
yeah, possible. (Btw think we also want to move those options out from the namespace to the form ^:nextjournal.clerk/no-cache (ns notebooks.color notebooks.color)
)
We've been thinking about this too, @U1EP3BZ3Q. But our approach with Clerk is the opposite of "move fast and break things", where we really want to make sure that everything fits together well to give the most power with the least API surface. 🙂
Ha! I'm the last person who expect moving fast and breaking things 🙂 Just sharing my observations and conclusions, which are subjective for sure but may be helpful (I hope).
I just meant that we're listening and trying to meet everyone's concerns, even if it seems like we're a bit slow shipping a solution or we don't take someone's pull request as is. 🙂