This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@djblue what pattern would you recommend for passing configuration options to a viewer? I can guess here that the answer is “rpc!” but I wanted to check. katex supports a bunch of configuration options, like custom macros: https://katex.org/docs/options.html I can pass them in here, in this options map:
(defn get-opts []
#js {:throwOnError false
:displayMode true})
(defn tex [_]
(let [opts (get-opts)]
(fn [text]
[:span
{:dangerouslySetInnerHTML
{:__html
(k/renderToString text opts)}}])))
actually I’m not sure RPC call is the right way; I can figure that out, but I think I want to be able to take these options as arguments to my start!
wrapper and supply them to the viewer
I love btw that with this {:on-load install!}
flag you have, I can make changes to the viewers and reload the Chrome page and all changes are picked up
I think https://github.com/djblue/portal/blob/master/src/portal/ui/options.cljs#L33 is probably what you want but it isn't available to sci just yet :thinking_face:
yeah that sounds like it!
I would use it for mafs, for example, to let the user select the default theme vs the mafs theme
and for tex of course there are a bunch of options w/ the link above
If you still have a copy of portal locally, you can quickly add it here https://github.com/djblue/portal/blob/master/src/portal/ui/sci/libs.cljs#L10
nice I’ll give it a try
I’m going to push today/tomorrow toward getting this all tested, documented and merged… I am taking the “get an enormous PR that does everything and then cut off tidy sections” approach
I would pull latest as well, you can pass in {:theme :portal.colors/zenburn} to open with a different theme:ok_hand:
@djblue so then I get access to all options that I’ve passed to p/open;
Do I have to wrap my component in with-options
, or does portal do that for me?
Yes for sure I was just wondering if I also have to call with-options to populate the context
Gotcha, yeah context gets populated on app init here https://github.com/djblue/portal/blob/master/src/portal/ui/core.cljs#L44
I accidentally passed :zenburn
vs :portal.colors/zenburn
and I kind of like the old macOS vibes!!
@djblue works great!!
(def portal
(p/start!
{:emmy.portal/tex {:macros {"\\f" "#1f(#2)"}}
:theme :portal.colors/zenburn}))
do you have opinions on a convention for passing options here? nested under :viewers
, or without the key prefix, etc?it might be nice to have a load-viewer
or something that takes a namespace symbol and does this automatically:
(-> (io/resource "emmy/portal/tex.cljs")
(slurp)
(p/eval-str))
I could see adding something like the following to portal.api:
(defn load-ns [ns]
(p/eval-str (pr-str (list 'require ns))))
Oh nice is that enough, instead of my explicit slurp and eval-str?
So good
I think it would work, however, now you might need to specify :reload to re-require the ns :thinking_face:
Maybe this instead:
(defn load-ns [& args]
(p/eval-str (pr-str (conj args 'require))))
sorry to overshare here but this is nuts… I:
• send out a Mafs chart using (of-x sin)
• it renders and wraps itself in the appropriate (mafs/mafs (mafs/cartesian) …)
shell
• I then SELECT THE GRAPH in Portal, which makes the original fragment available via @portal
• I can then build a new scene that includes @portal
(tap> (mafs/mafs
(mafs/cartesian)
@portal
(mafs/of-y exp {:color :green})))