I'm getting a weird error that I can't seem to shake.

clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: defstyle in this context, compiling:(vbn/web.cljc:12:1)
             java.lang.RuntimeException: Unable to resolve symbol: defstyle in this context

Anyone know of a high-level io library that's pure cljs?

@futuro try using nodejs fs, with #lumo for example. No/few other ways I know of.

@hlolli yeah, I'm currently working on a cljs version of tools.nrepl, so I'm looking into ways to make it vm agnostic

hi, does anyone have a recommendation for lein or boot for starting new node.js (NPM module) ClojureScript projects? and if so, any example or template I can follow?

@johanatan Is your intent to use CLJS to generate a JS file and then publish that JS file to npm? Or are you creating a library that would be useful to use from CLJS?

@chrisoakman the first-order goal is to do the former although the latter is a secondary concern. FWIW, the current lein-based version of my library is consumable via both languages

@chrisoakman I am looking to update it as the project was started almost 2 years ago and a lot has changed in the CLJS world since then

it's also a bit fragile from a maintenance standpoint (I forget specifics at this point) so bringing it up to date is the first step to remedy that

here it is if you want to take a look at it: https://github.com/johanatan/speako

Clojars is probably the best place for a CLJS library. Easiest to consume for CLJS users.

Never tried but maybe you could use none, filter out your files and turn it into a Closure module.

I'm not sure if Babel and other tools understand that format but at least it should be easy to incorporate into CLJS while still being regular JS

probably on the JS side it would get hard to make sure dependencies are met though

my primary concern here is merely starting a state-of-the-CLJS-art Node.js [library] project publishable to NPM. the CLJS use of it is secondary (and not important at first)

I just imagined that there would be some sort of template for this sort of thing for at least one of: {boot, lein}

this library only exports a single function. the difference between using it from CLJS or JS is to merely call cljs->js on the inputs or not.

see: https://github.com/johanatan/speako/blob/master/src/speako/consumer.cljs#L186-L187

I don't know much about lein templates, but sounds like you just need to produce a single JS file that is consumable by node.js and then make sure it does module.exports() with what you want.

& https://github.com/johanatan/speako/blob/master/src/speako/consumer.cljs#L194-L196

@chrisoakman yes, that is exactly what i'm doing

but that isn't what I'm asking on here how to do

The [atom-parinfer](https://github.com/oakmac/atom-parinfer) plugin might be helpful. It is written in CLJS and publishes a JS library to apm (basically the same thing as npm; just for atom packages).

So, there's no std template for either boot or lein for starting a new node.js project?

Seems like one of the very first things that people would want to do with ClojureScript.

That may exist; I wouldn't know.

ahh, a bit of Googling turns up a few things but none have been touched in the last year (which is barely better than the 2 year-age of my hand-rolled-from-a-few-blogs-somewhere solution).

And, it seems "hand-roll-[piecemeal]-from-a-few-blogs-somewhere" is a sort of modus operandi about many CLJS things. 🙂

I suppose that's one way to look at it.

Feel free to copy the atom-parinfer project.clj as a template: https://github.com/oakmac/atom-parinfer/blob/master/project.clj

That should get you 99% of the way there.

🙂 yea, i will try. I recently did the same with a different project and it got me 95% of the way there but the remaining 5% was a show stopper.

@chrisoakman anyway, thanks for the input.

Anytime 🙂

ahh, I remember now what the show-stopper was on my previous attempt: https://github.com/lbradstreet/instaparse-cljs/issues/20

It seems after updating to the latest CLJS and such and updating the project template/compilation, that bug/mis-compile or whatever it is was exposed in instaparse.

But the instaparse maintainer doesn't think it is an instaparse bug (and he couldn't reproduce it).

Hey @johanatan, I never got around to investigating your bug after you followed up with the more concrete issue; I'll take a look tomorrow

Hi, const {block} = this.props; (block.getEntityAt(0)) —> snip… (aget props “block”) (.getEntityAt block 0) snip… right?

Is there any way to make pprint to print function definition instead of string representation of JavaScript function? i.e. for

(pp/pprint {:my-fn (fn [x] (+ 2 x))})

{:my-fn #object[Function "function (x){
return ((2) + x);
}”}}

@crankyadmin i haven’t done regular JS in a while, but one thing that seems different between the two code snippets you’ve given is that on the left, something seems to be assigned to the name “block”, whereas on the right that doesn’t happen

maybe a (let) would be helpful, so you can assign (aget props “block”) the name block

if that’s not what you’re looking for, more info about what you’re trying to do and what you’re seeing would be helpful 🙂

@jrheard Its cool. I cheated. (js->clj (.valueOf block 0) :keywordize-keys true)

Sorry if I wasn’t clear. I did have a let in my code already. I cut it right down to the bare min for pasting in here.

aha, gotcha

@aengelberg: ahh, awesome! Thanks!

I'm afraid there's a critical piece of information I'm missing in regards to the repl

re, om/next -- i am thinking the answer to this question might solidify some things i'm missing. why does om/next need to deal w/ remotes? couldn't remoting have been left out entirely, leaving the user to make async calls and merge the state back into the reconciler out-of-band. what am i missing? what can/is om/next doing for us by being the middle-man for :remotes?

(I'm using Leiningen repl currently.) The REPL starts in some generic "cljs.user" namespace that doesn't seem to be populated with any user-defined functions. I can switch to particular namespaces, but those namespaces seem not to have loaded clojure? Alternately, I can require those namespaces from the cljs.user namespace, but that doesn't appear to make those definitions available in cljs.user.

What am I doing wrong ?

The takeaway I'm getting from googling this issue is that the correct way to load specific namespaces into the REPL might depend a little bit on your clojurescript version

What would be a performant translation of this JS to cljs:

function addScrollListener() {
    var timeout;
    window.addEventListener('scroll',function(e) {
      if (timeout) {
        clearTimeout(timeout);
      }
      timeout = setTimeout(recordScroll, 1000);
    });
  };

@borkdude I think you can translate it directly with a let

the variable would be closed over by the callback function so the JS semantics would be maintained

@anmonteiro you can’t mutate let bindings

oh right I didn't see that part

since this is triggered on every scroll event it better be fast as possible 🙂

you can probably use a volatile!, though I don't think it's any faster than an atom

maybe just less memory because it implements less protocols?

@anmonteiro an atom does some extra work, like calling watchers right?

not even sure that's correct

yes, that's right

volatiles have no watchers

also no validators

So roughly:

(defn add-scroll-listener []
  (let [timeout (volatile! nil)]
    (.addEventListener js/window “scroll”
      (fn [e] 
        (when-let [t @timeout] (js/clearTimeout t))
        (vreset! timeout (js/setTimeout recordScroll 1000))))))

It might be interesting to see if something horrific like this flys: (let [x 1] (js* "x=2") x)

(defn add-scroll-listener []
  (let [timeout nil]
    (.addEventListener js/window "scroll"
      (fn [e]
        (when timeout (js/clearTimeout timeout))
        (let [x (js/setTimeout recordScroll 1000)]
          (js* “timeout=x”))))))

This is extremely hacky but it worked:

(defn add-scroll-listener []
  (js* "var timeout")
  (.addEventListener js/window "scroll"
  	(fn [e] 
      (when (js* "timeout") (js/clearTimeout (js* "timeout")))
      (js* "timeout =" (js/setTimeout record-scroll 1000)))))

Frankencode 🙂

oh hey @mfikes I see you were also hacking with js* 🙂

Yes!

There might be some cljs.core.truth_ call you can eliminate too.

this is extremely useful for testing these kinds of things: http://app.klipse.tech/

@borkdude planck -v or lumo -v will also print the generated JS source

@anmonteiro cool!

I wonder if (when ^boolean (js* “timeout”) … is semantically correct, but it gets rid of a call to truth_

The nice thing about Klipse is that I can test also if the scrolling thing worked 🙂

oh that's right

but it makes me think if that should be the default behavior

I would rather if it ran my JS input in a "sandbox"

@mfikes you’re right, it eliminated the call 🙂

Hah… yeah, it looks practically like your original JS now.

late to the party - in a hot loop, i’ve definitely noticed that getting rid of truth_ makes a noticeable difference, i got rid of 7% of the work one of my loops was doing by adding ^boolean in the right places per above (this was months ago, actual specifics/details escape my memory)

+1 to using klipse for getting the actual syntax right, will also try -v in planck/lumo

I’m wondering why ^boolean (js* “timeout”) gets rid of truth_ but ^boolean timeout won’t, in this code:

(defn action []
  (println "foo"))

(defn add-scroll-listener []
  (let [timeout nil]
    (.addEventListener js/window "scroll"
      (fn [e] 
        (when ^boolean (js* "timeout") (js/clearTimeout timeout))
        (js* "timeout=" (js/setTimeout action 1000))))))

(add-scroll-listener)

(btw “scroll” doesn’t work well in Klipse since there is nothing to scroll, so for testing I put it to “resize”)

putting the type hint in the let worked btw

@borkdude: if that ultimately fails under :advanced perhaps using set! on a top-level def would work, assuming only one scroll listener is started up

@mfikes Actually, I was just wondering how to accomplish this, but I’m not going to use it. If I would write it in cljs I’d probably go for volatile, because that just uses a field in an object, which should be fast enough.

(hopefully, I’ll see when the need arises)

hey all am I missing something when doing this

(js->clj “{‘a’:1”} :keyworddize-keys true)
outputs "{'a' : 1}” 

I was expecting the clj dict with a as a key. I am pretty sure I’ve seen that working somewhere

wow, that is related to the previous conversation kind of. does this work?

(js->clj (js* "{'a':1}") :keyworddize-keys true)

yeap that works..

thanks moving between js cljs sometimes makes me dizzy

(js->clj (.parse js/JSON "{\"a\":1}") :keywordize-keys true)

funny, I wish I could tell you where js* is defined, but I can’t find it

if it is json, then yeah, that’s better

no worries thanks js->cljs get me sometimes

yw