Fork me on GitHub

maybe a bit offtopic here, but I am using transit-js and if I understand correctly it seems like it is not supporting json streams, can anybody confirm?


I was hoping to go "append-only" all the way but I got:

  return this.decoder.decode(JSON.parse(a), b);
SyntaxError: Unexpected token { in JSON at position 213


transit should be able to decode the stream of data, JSON.parse returns objects doesn’t it?


oh, wait, I misunderstood


yeah I am reading a stream, I think the clojure one does it


yeah, that’s a really weird error


Oh I found: > Unlike the Java and Clojure implementations it relies on the non-streaming JSON parsing mechanism of the host JavaScript environment.


I guess that answers it then


yep, too bad, thanks for sharing the pain 😄


So I was thinking that the reason functions like (constantly 1) couldn't be sent over to a web worker with their string versions was because CLJS somehow decomposed some functions into separate functions. I finally grokked that CLJS is creating a JS closure. And after some research, there is no way to reflect/introspect to get a JS closure's values.


Eventually, you've gotta learn the host platform either way 😕


I'm starting to get it though 🙂


Sending closures over a network connection is a bad idea anyways


Either you send just the function and hope the environment exists on the other end, or you try to send the environment and may end up transmitting the entire state of your vim.


Send data, that's what it's there for


Yeah, that's pretty much the tradeoff I've settled on. Only sending a limited class of functions and the rest is data.


@metametadata thank you, I will opt for a global registry. I want to write test-code that is more clojurian as possible, and using fixture seems to be recommended :thinking_face: do you know where I can find some test code well written? Or any books or documentation either? 🙂


Hey all, ES7 has the await for working with promises, instead of using .then and callbacks. If using a js library that returns promises (or uses .then), is core.async the way to go to avoid callbacks? Or can await be translated to cljs in another way?

(defn some-fn []
  (let [ch (chan)]
      (-> something 
          (.js-method #js {< bunch-of-pars >})
          (.then #(>! ch %)))
      (<! ch))))
Or would there be a (better) way? (e.g. using - not sure if it makes sense) Or should I be updating some kind of state and have a listener on that state, instead of returning values?


(Using core.async-channels looks nice, but I suppose they add quite some overhead and garbage - I may be wrong and I maybe shouldn't worry about it)


@giovaferra surprisingly, fixtures can also be considered a bad practice because they make reading test cases harder (you have to keep in mind the implicit execution context and jump to the top of the file to figure out what's going on), e.g. see this post by one the authors of NUnit - Books I always recommend on the topic: "Test Driven Development: By Example" by Kent Beck "Growing Object-Oriented Software, Guided by Tests" by Steve Freeman and Nat Pryce "xUnit Test Patterns: Refactoring Test Code" by Gerard Meszaros


@kurt-o-sys recently I tried using core.async for async AJAX functions and return channels kinda like in your example but then opted out to simply passing callbacks. It looks just fine because I don't need some more complex scenarios/orchestration of async stuff.


or maybe scratch my note about multiple puts, maybe your version also supports that now when I think about it more


anyways my version is more straightforward, because you don’t need to create the wrapping go block


@darwin You're returning only the channel here, right? So changing the last line with (<! ch) would return the value.


I actually don't need a go-block?


your original function returned a channel, go returns a channel with last evaluated form as value


oh, the go-block will result in problems, I see.


no, it won’t result in problem


go just returns a channel, which was the thing returned from your fn


it is perfectly fine to pass channels around


Can one show more complex example with core.async? How it would be with "promises chain"?


@metametadata yeah, I've been thinking about it as well... but I wanted to avoid that 🙂


@darwin Yeah, its fine to return channels, although I wanted to avoid to require core.async everywhere in my code. But than again, maybe that's not really possible.


@kurt-o-sys yes, in general core.async is infectious, similar way as callbacks are - it forces other code to use it as well


but there are ways around it and that is pretty deep topic, you might want to watch recent @tbaldridge’s talk about this:


allright, thx!


btw. if anyone wanted to see real-world cljs core.async code for inspiration, you could look at my chrome extension code, most chrome extension apis are async (callbacks), and I decided to convert them to core.async channels and write my code in core.async-style:


@metametadata mmm really interesting :thinking_face: , I will make some try to see what's better, it is the only solution, thanks! 😉


@kurt-o-sys I created manifold-cljs in order to implement some cross-platform manifold-based functionality. If you’re not already using manifold on the backend, going with core.async is a better idea for cljs


@dm3 yeah, I saw your library. nice work!


hi there. Which package should I add to :dependencies in order to be able to :require cljs.spec.alpha please? I'm using cljs 1.9.521.


cljs 1.9.542 😉


@fdserr we didn’t break out spec nses into a separate dep like Clojure did


Solved, thanks Thomas @thheller! David, get some sleep ffs 😜


Reading the cljs pprinter, it seems like it's impossible to override the default (simple-dispatch) to include custom records, is that correct?


@dominicm not familiar so can’t say, but if it’s not a limitation of clj pprint then it shouldn’t be in cljs


@dominicm looks pretty simple to fix though, so patch welcome


@dnolen what is the class equivalent in cljs? type?


@dnolen IPersistentMap doesn't directly translate & it seems that clojure's respects IPersistentMap for PersistentArrayMap (I guess through the inheritance chain somehow? Not sure on that). I think I recall that cljs doesn't have I* equivalents, does it also switch between implementations for {} etc. automatically?


@dominicm you can’t cover protocols in multimethod like that in ClojureScript - that’s a fundamental limitation


if you want a catch all for records then it needs to be added


the other option is to write one for each record type you care about


you could remove the boilerplate with a macro of course


@dnolen Hmm, don't think I am fully grasping your solution. I don't think it will work with the record type cared about, as these are in clients. Unless there's a general way to match records to turn them over to another dispatch?


you can’t capture interface like Clojure can


that’s why there’s hard coded dispatch in ClojureScript but that’s actually a bit of a mistake


the final clase of the dispatcher should be type


but if you want to cover a protocol then it needs to be hard coded


IRecord is a protocol btw


Oh, derp. Got it.


happy to take a patch that does both of these enhancements at once


The current behaviour for records pprints the same as Clojure (at a glance).


Hey folks, I'm looking for some advice/critique on this namespace. It's super hacky at the moment and I suspect that most of the namespace can probably be reduced to something much simpler and more resilient. I'm literally rewriting pr-stred functions. Is there a less hacky way to do (apply (fancy-translation (pr-str my-fn)) args)?


I don't know but this strongly resembles my attempts to extract deftype field names after advanced compilation 😎


A lot of the current complexity of the namespace has to do with trying to clean up escaped characters in the pr-stred output, but that's probably a lot of unnecessary code.


@miika yeah, I basically banged on it till it worked. Didn't bother cleaning it up too much since I doubt the whole method is going to be the "right way" anyway.


I should note that in another namespace I'm doing this: (cljs.reader/register-tag-parser! "object" #(str "#object" %))


And with respect to JS closures making some CLJS functions un-round-tripable, I've been reading on SO at least a half a dozen ways to define JS closures such that their private variables can be made accessible from the outside. If CLJS emitted such code, it would definitely make CLJS more reflective/introspectable/round-trippable and would align closer with the "code is data" philosophy. No idea about the performance tradeoffs though.


could use a few more brave alpha testers 😉


I'm thinking of writing a library in cljc. Are there any recomended lein templates or similar with the basic setup (testing, cljs build (for browser and node) etc.). I found on github, but it uses a 0.0-xxxx cljs version, so I'm a bit wary of that.


cljs.core.async/promise-chan never really worked correctly, I believe the issue is finally solved in master -


if you have time to take it for spin that would be great


honest question - what does this when check do that doseq alone wouldn’t ?

+              (when (seq take-cbs)
 +                (doseq [f take-cbs]
 +                  (dispatch/run f)))


I'm trying to use goog-define/`:closure-defines` to read config at compile-time, but it doesn't work. In my project.clj:

:profiles {:dev {:dependencies [[figwheel-sidecar "0.5.8"]
                  [com.cemerick/piggieback "0.2.1"]]
          :source-paths ["src" "env/dev"]
          {:builds [{:id      "ios"
                     < ... >}}
                    {:id      "android"
                     < ... >
                     :compiler {:output-to   "target/android/not-used.js"
                                :main     ""
                                :output-dir  "target/android"
                                :optimizations :none
                                :closure-defines {conf "from project.clj"}}}]}
I'd expect that the output of (goog-define conf "from code") in my code would set conf to from project.clj. It doesn't. It shows from code.
(defn init []
 (goog-define conf "from code")
 (.log js/console conf)
 (.registerComponent < ... >)
What am I missing?


move the goog-define out of init, it is basically a def


did that, same result.


thanks for confirming


in this case just taking care to match the Clojure implementation for future patchers


there’s definitely a lot of low-hanging fruit if people want to jump in and help. I’ll be checking on this repo at least on Fridays along with my usual combing through ClojureScript JIRA - so if you want to contribute this is a great place to start.


Is it possible to force the use of a foreign-libs :file-min for a build that isn’t using advanced compilation?


I don’t see any way to override it besides forking the cljsjs package, which seems a bit drastic