This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-12
Channels
- # ai (1)
- # aleph (11)
- # announcements (9)
- # aws (1)
- # beginners (61)
- # chlorine-clover (2)
- # clj-kondo (1)
- # clojure (35)
- # clojure-australia (1)
- # clojure-china (1)
- # clojure-europe (1)
- # clojure-filipino (1)
- # clojure-france (2)
- # clojure-hk (1)
- # clojure-indonesia (1)
- # clojure-japan (1)
- # clojure-korea (1)
- # clojure-my (1)
- # clojure-sg (1)
- # clojure-taiwan (1)
- # clojure-uk (1)
- # clojured (14)
- # clojurescript (45)
- # cursive (8)
- # data-science (2)
- # events (1)
- # fulcro (2)
- # gratitude (4)
- # helix (1)
- # honeysql (3)
- # introduce-yourself (1)
- # malli (4)
- # minecraft (4)
- # nbb (23)
- # off-topic (57)
- # polylith (4)
- # reagent (2)
- # sci (23)
- # shadow-cljs (7)
- # vim (1)
- # xtdb (17)
Q on best practices… I am currently making a cljs wrapper of mathbox-react, which will expose 54 reagent components.
I want users to be able to easily use those from, say, Clerk, which means they need to be exposed inside SCI.
My plan now is to build a ready-to-go :namespaces
context entry by calling sci/create-ns
on all of the namespaces (one for each component), so the user can merge than in to their context.
Is this the right pattern for making a library simple to consume via SCI?
@sritchie09 That's absolutely the right pattern :) That's what we're doing here too: https://github.com/babashka/sci.configs
Okay awesome. @U04V15CAJ I'll embrace this style and make a separate repo for the SCI config, as that looks like the slimmest option for the user
Actually @U04V15CAJ just to confirm, the idea here is that this ships NO dependencies… but that's fine since if you Don't require a specific library’s namespace this wont cause an error?
Is a dot in a project name allowed for a maven artifact btw?
re https://clojurians.slack.com/archives/C015LCR9MHD/p1655039426067049?thread_ts=1655039125.208389&cid=C015LCR9MHD yes, this is the approach taken in sci.configs too
re https://clojurians.slack.com/archives/C015LCR9MHD/p1655039472635889?thread_ts=1655039125.208389&cid=C015LCR9MHD I think so, why not?
I see dashes all the time, just assumed there was some restriction!
nice. then maybe I’ll do mathbox.cljs
instead of mathbox-cljs
@U04V15CAJ would you recommend moving the sicmutils config OUT of the main project?
Slightly different case since sicmutils has an sci dependency already for its own use. I do need to migrate to copy-ns
@sritchie09 What are the pros/cons?
The main pro is it the current style is going to be quite awkward to maintain as I split up the build
Which didn’t occur to me until you asked that question :)
awkward because I will need one SCI config for each module, and the current one is equivalent to all of those merged together
(phew, I just caught a delayed train alternative in time on my way home from Berlin)
I gotta check that out then. Maybe the idea we had @mkvlr about making an interactive README for your cljs library could be achieved with a clerk static build
https://github.com/sritchie/programming-2022/blob/sritchie/reactbox/src/demo/viewers.cljs
I guess you’d have nothing to ADD to the custom context unless you also took over the cljs build process for clerk like I do here: https://github.com/sritchie/programming-2022/blob/sritchie/reactbox/dev/user.clj#L15-L19 so, no fork, but mildly involved especially when producing a custom static build (which I haven’t managed yet)