Fork me on GitHub
Sam Ritchie21:01:44

@borkdude I think it’s finally time to replace my code here with calls to sci/copy-ns… I’m reading the code and wondering if macros are simply ignored by this, or if there is some fancier way to handle them?

Sam Ritchie21:01:46

also curious @borkdude if it’s possible for dynamic variables to work inside of SCI; meaning, if I have a dynamic var outside, will the copied version from copy-ns be appropriately dynamic

Sam Ritchie21:01:28

anyway cleaning this up will be a great upgrade


yes, dynamic vars will be also dynamic in SCI but they won't be synchronized with the dynamic var they were copied from, you have to do this manually

Sam Ritchie21:01:27

I’m also curious what you think about the pattern of exposing, for example, this namespaces map as part of my library: the only downside I can see to putting that map into its own namespace is that I would gain an extra dependency on SCI; I don’t see a way to exclude it.

Sam Ritchie21:01:21

but it feels like it’d be a great pattern for all of these reagent plugin libraries i’ve been building to following some convention for installing their namespaces into the SCI context. then users can add their own aliases of cousre

Sam Ritchie21:01:00

would there be a bundle size penalty for copying everything at compile time? maybe not, if I do something like

(defn get-namespaces [{:keys [exclusions]}]
  (-> {'mafs
       (sci/copy-ns mafs (sci/create-ns 'mafs))
       (sci/copy-ns mafs.coordinates (sci/create-ns 'mafs.coordinates))

       (sci/copy-ns mafs.plot (sci/create-ns 'mafs.plot))

       (sci/copy-ns mafs.line (sci/create-ns 'mafs.line))

       (sci/copy-ns mafs.debug (sci/create-ns 'mafs.debug))

       (sci/copy-ns mafs.vec (sci/create-ns 'mafs.vec))}
      (dissoc exclusions)))


You can make these SCI configurations available as an optional dependency, either by putting them inside namespaces that are optional to load or in a different library. I've done that with configs I use frequently here:

Sam Ritchie22:01:27

Oh, and because it’s cljs … you’re saying just don’t ship the dependency and leave it up to the user

Sam Ritchie22:01:57

@borkdude do you know if that convert above matters at all - like if that optional namespace binds a var with a bunch of different namespaces, and the user only wants 1/100 or something, will that blow up the build?

Sam Ritchie22:01:06

or is Closure smart enough to trim the unused ones?


closure is smart enough

❤️ 2

you can test this yourself using the shadow-cljs build report

Sam Ritchie22:01:49

TIL, awesome

Sam Ritchie19:01:10

@borkdude the only thing I’m thinking of adding to this pattern is

(defn install! []


that's what I do a lot too :)

Sam Ritchie14:02:17

if I made a namespace that actually called this function, the the user wouldn’t have to write any cljs at all, just include emmy.sci-install in their list of required namespaces, and keep stacking namespaces to get more plugins…

Sam Ritchie15:02:18

is there any merit to that pattern? or is there some way we could take a data config into Clerk, like :plugins, :aliases etc and then generate a cljs file that does this, without the user having to write a cljs file?


I think it might be better to have the explicit install since the namespace loading order matters and there might not be a sci context in the sci ctx-store yet

Sam Ritchie15:02:19

yeah, you’re right. There is that mysterious side effecting import of Clerk’s sci-env that needs to happen too.

Sam Ritchie15:02:40

“mysterious” from the perspective of someone experiencing Clojure for the first time via Clerk, I mean