Fork me on GitHub

@pppaul Some folks have tried various inline css schemes, like and


Not sure if that's what elm's style elements are though


How is this supposed to look like:

(defn content []
   (let [ctx (-> js/document
                (.createElement "canvas")
                (.getContext "2d" #js {:antialias true}))]
      (set! (.-font ctx) "30px Arial")
      (let [m  ((ctx (.-measureText) "some text here"))]
        [:p (str "m:" (.-width m))])))
I just want to find the width of some text using the canvas object


Reading I would expect the last let to be (. .-measureText ctx "some text here") but I fail at this


ah, field vs method


yep, that was it, nevermind


well, for others to learn, this works:

(defn content []
   (let [ctx (-> js/document
                (.createElement "canvas")
                (.getContext "2d" #js {:antialias true}))]
      (set! (.-font ctx) "30px Arial")
      (let [m (.measureText ctx  "some text here")]
         [:p (str "m: " (.-width m))])))


I've found this function useful for making sure a resource is only created once:


Especially when reloading with figwheel, you often want to ensure that there's only one resource of a certain type, like a setInterval, and event handler or some kind of stateful object. Often you need to dispose of the resource before creating a new one.

👍 12

not sure what the right channel for this is, but is there a way to copy files with cljsbuild? I want to copy some styles from a node_module into the directory with the rest of my resources

Garrett Hopper17:08:54

When using a node library that requires es2015 classes, is there a way I can create them in ClojureScript? Do I need to do some sort of Object/create magic?



cljs.user=> (def o (reify Object (hello [this] (prn :ok))))
cljs.user=> (.hello o)

Garrett Hopper17:08:52

@pesterhazy I don't think this is actually what I'm looking for. I need to create a new es2015 class that extends a class provided by a library.

Garrett Hopper17:08:02

I'm not sure what about the es6 class this library really needs. I'm attempting to replicate it somehow. seems useful


yes, something like that should work

Garrett Hopper17:08:43

That looks very promising, thanks! 😄


@ghopper lmk if that works out for you


Hi, can someone point me to an example of using the :npm-deps option of the clojurescript compiler in upstream packages? Is it possible to have clojurescript project A use clojurescript library B (via a deps.edn reference) and then have the compiler download the npm deps required for library B when I compile project A?


Thanks for any tips, just having a bit of trouble wrapping my head around how npm dependencies work when creating a clojurescript library...


@drcode B must declares its dependencies in a deps.cljs at a source root with just {:npm-deps {"the-lib" "version"}}


that just covers the "download the npm deps part". for the compilation I don't actually know.


@drcode before going down that path I’m assuming you’ve made sure that said library will get through Closure compilation - it’s still a coin toss at this point


OK @thheller I think that explains the piece I was missing, that sounds correct- Let me give that a shot


@dnolen thanks- yes, I hope so. I'm taking some libraries I have that use cljsjs and am trying to get them working with just npm packages, so in theory at least I should be past the compilation hurdle already.


@drcode right I would be careful going down that path


you’re foisting a very alpha feature onto users - CLJSJS works


whether library X will work is not up to us at all


but a matrix of JS practice and what Closure understands


@dnolen good to know 👍 I think I understand there's limitations at this point with externs inference, just personal experimentation right now


nothing to do with externs inference


externs inference works


I’m using that all the time with non-trivial libraries + Webpack


:npm-deps pushes random JS libraries fully through Closure compilation


Thanks for this insight!

Garrett Hopper20:08:06

@pesterhazy I think I managed to get the prototype extend stuff working, though I never really understood it. Eventually I realized with the library I'm using, I can call the call function directly and it'll work. I though I'd tried that to begin with. :man-shrugging: Thanks for pointing me in that direction.


totally different thing


if you’re using :npm-deps you don’t need externs-inference


@dnolen I can (sorta) see that, hopefully with some more learning/experimentation on my part will help me understand these subtleties


orthogonal features


but suffice to say you’re not the only person confused about this, and it’s not the user’s fault


we need more docs clearly documenting what is for what


still - rewinding a bit - curated CLJSJS libs are still the best way forward for transitive deps for end users


now with externs-inference and :global-exports it doesn’t have to be non-idiomatic


nor do you have maintain externs


@dnolen OK, maybe then I need to rethink what I'm doing then... hmmm.


publishing random JS libs to CLJSJS has never been easier


you don’t have to do anything


other than bundle X up into a JAR and write the deps file for it


and based on my experience so far with random JS libs - the curation of CLJSJS is actually value


so much bad stuff out there


and the dep chains are completely out of control

✔️ 8
👍 4

@drcode To clarify, as the cljsjs homepage says: > Since ClojureScript 0.0-2727 the :foreign-libs option provides an excellent way to integrate Javascript into ClojureScript applications. CLJSJS provides Javascript libraries and their appropriate extern files packaged up with deps.cljs. CLJSJS aims to concentrate packaging efforts to make everyone’s life a little easier. i.e. what you get from CLJSJS is a prepackaged foreign-libs declaration along with correct externs. That means that your "advanced compilation" will be [advanced compilation of your code, respecting included externs in the renaming phase] + [JS lib], both in the same file, but without the JS lib ever going through the Closure compiler (though generally you do get a minified version). On the other hand, when you include a library with npm-deps it does go through the full Closure compiler along with the rest of your code. So no externs involved and DCE and all the goodness IF that library happens to be compatible with Closure, but a lot of JS code out there is not compatible with Closure at all and can yield anything from compilation errors to compilation going fine but the resulting code not loading to code running fine under whitespace and simple but completely breaking down in advanced compilation.


I agree that CLJSJS provides actual value but overly optimistic or unaware users could still get ‘Caught in the Pit of Despair’ as explained in this talk by @spinningtopsofdoom:;t=8m10s

👍 8

I'm not sure where the best place to ask this is, so I will try here first. Say you have a Clojure/ClojureScript app which is bundled into a JAR. The Cljs part is browser based. It has resources for the cljs/js stuff in usual place resources/public/.... Now when this thing is used - deps pull it in and requires (in both Clj and Cljs) make it available - is there a way to add new 'resources' (in the common sense) that augment those in resources...?? I suppose this is a general web/web-server/browser question...


Like the app is a lib?


@darwin a lot of this stuff is pre (to be fair, working) externs-inference


I’ve not written externs since the last release


@jsa-aerial or do you just mean adding more at run time for a certain instance?


Yeah, the 'app' is a lib


hmmm I have some vague ideas on how that could work with the new tools deps system, but not absolutely sure, and would depend on the build tool. For lein I'm not sure. I don't recall trying it.


@U050PJ2EU To be honest, I just don't know enough to have an idea. Thanks for the response though!


But I mean, I'd imagine you could slurp some files and populate some java properties io/resource


Which is where all those files are held, right?


I have a couple of React components, in JS, which I'd like to compile alongside my ClojureScript app (using :foreign-libs). Unfortunately, they're using ES6 imports to import each other, which CLJS doesn't support (reportedly due to Closure not yet supporting it). What are my options for being able to compile these components with CLJS?


I've tried transforming them to CommonJS, with babel, but CLJS still doesn't handle the requires. I've tried combining them, with webpack, but I get back a bundle that does a bunch of eval calls and, when I require it within CLJS, the ns object I get back is empty. I don't know enough about the JS ecosystem to try much more just yet, so I'm hoping there's a more trodden path.


if you are up for using a completely different build tool 😉


@jeaye or just use Webpack for that stuff


I'm up for any solutions which work, really, provided I can still use leiningen as well. Looks like shadow-cljs can, but I've never used it.


your bundle is a single foreign lib that can provide whatever you want - and with global exports you get externs inference automatically


and your requires look like normal CLJS requires


re: Webpack eval calls


Right, as mentioned, I have give this a go and webpack was the only way I could get CLJS to require the JS without issues. However, the object I get back when I require (if I js/console.log it) is empty.


webpack --mode=production


eval be gone


the empty ns object thing I don’t really understand


but anyways - that’s the trodden path - far as I know it’s working for people and I’m using it myself on something for work


Generating the bundle with npx webpack. All is as intended?


Similarly, if I require it from Node, I get an empty object just the same. Is that supposed to be the case?

const dist = require('./dist/bundle');
console.log(dist); // {}


@dnolen Ok, found it. Seems to me like the webpack CLJS guide would need to be updated.


I needed:

output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
    libraryTarget: 'commonjs', // added
    library: 'UI' // added