This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-15
Channels
- # adventofcode (1)
- # beginners (79)
- # boot (23)
- # cider (15)
- # cljs-dev (14)
- # cljsrn (27)
- # clojars (4)
- # clojure (172)
- # clojure-dusseldorf (23)
- # clojure-india (2)
- # clojure-italy (1)
- # clojure-nl (23)
- # clojure-russia (43)
- # clojure-spec (29)
- # clojure-uk (70)
- # clojurescript (97)
- # clr (8)
- # cursive (10)
- # datomic (69)
- # events (3)
- # garden (12)
- # hoplon (120)
- # immutant (34)
- # lein-figwheel (9)
- # leiningen (4)
- # off-topic (4)
- # om (10)
- # onyx (51)
- # rdf (1)
- # re-frame (15)
- # reagent (23)
- # ring-swagger (8)
- # test-check (3)
- # untangled (96)
- # yada (1)
I am using google-maps with #reagent in production though, but had to write my own integration.
Does anyone work with websockets and a non-clojure backend? What library/ies, if any, do you use?
sente appears to be for a clojure/clojurescript pairing, chord looks like it might be useful.
Slightly off topic… 401
is the correct response to send when failing a login over a API, right?
Yes, 401 "Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided."
Cheers guys! http://www.restapitutorial.com/httpstatuscodes.html This was useful as well!
@renlinx There’s also a #garden channel if you want to re-post there. Not a lot of traffic but you might catch someone’s eye.
@manutter51 try to answer if you can ..
I would but I’m just lurking there hoping to learn something about garden — sounds like a neat idea but I’ve never used it
@renlinx I found this which might possibly be of interest: https://github.com/reagent-project/reagent-cookbook/tree/master/recipes/reagent-server-rendering
seems like its server side rendering :thinking_face: , will check 🙂 thanks the question is about precompiling garden/hiccup files to html & css
^--- EOF while reading, starting at line 18 and column 1
what does this mean? definitely no end of file in the middle of the file, this file has exactly 36 lines...
@ashnur when does this happen ?
if this is in the REPL, I usually see this when my strings or dates are badly formatted
@ashnur I meant in what circumstances
maybe unbalanced parens?
@val_waeselynck i know what you meant, i was trying to jokingly explain that i don't know what the good answers are to that question
"I was loading a CLJ file" would have helped 🙂
thanks @val_waeselynck it was paren mismatch, i checked 2 times before asking if it's not that, but because you mentioned, i checked again and indeed it was that
obviously we still have progress to do w/ error reporting
what editor are you using, out of curiosity ?
ok, not my area of expertise unfortunately
@ashnur check for unbalanced parenthesis
https://gist.github.com/ashnur/af62ecc560ed167248f47b9037e99955 so, how would you do this?
particularly the grow function i wish it did not had lambdas in it, i am fairly sure this should be possible in a nicer way, or maybe different but more idiomatic
ok, i rewrote it a bit, maybe its better? https://gist.github.com/ashnur/43f57cb21df375998e04a7b5e6a44eac
is there a guide or even an automated way to use npm modules (that are not on cljsjs)? i think i first need to bundle the npm deps using something like webpack and then write an externs file, correct?
@tobiash yes that’s how it’s done, Google Closure has a coming feature to consume node_modules under review but many caveats will apply
I suspect it will take at least a couple of months before anybody will have any real confidence in it
ok, i might give it a try. I'd like to use https://github.com/react-toolbox/react-toolbox with om.next, but the API is pretty big, so externs inference might be really helpful here
it's a bit unfortunate, i really prefer clojurescript over javascript and i like om.next as a framework, but I keep running in these tooling issues and that's also whats keeping me from using cljs in my day job
@tobiash understandable point of view, but note for a lot of users it’s really not a significant barrier
and integrating with seamlessly with the wider JS system is always going to be a non-goal
we can make it better, but up to a point, after which we’re not interested since conflicts arise with things we consider more important - dead code elimination etc.
yes, I understand, and even when I can use JS libraries, dealing with the interop code often leads to repetitve boilerplate code
hm, in my noodling around with cljs i’ve found that i can usually hide interop behind cljs utility functions i write, and so i don’t usually see repetitive boilerplate code in that context
@tobiash ok, but that’s not really my experience after doing this for a long time now. when I do have significant boilerplate - helper fns and/or a convenience macro goes a long way
ok, I probably have to get a lot more practice to figure these things out. I am using firebase in a react-native/re-natal project and the firebase api calls look pretty ugly and don't really fit in. I know there is firestack and some other clojurescript wrappers for firebase, but they didn't work with react-native
@tobiash it might be helpful to see what type of “boilerplate” you find yourself writing - it may or may not be avoidable
I'm not sure whether this was discussed before, but Closure compiler supports ES7 async/await, also generators (https://github.com/google/closure-compiler/issues/1391), and IMO this could greatly simplify core.async
CLJS implementation. The state machines that the go
macro generated are both hard to debug, and also increase the size of emitted code a lot.
@alexmiller @dnolen do you think this is worth looking at, eventually refactoring cljs.core.async
to make use of it? Does CLJS compiler need some additional stage so that the go
macros is first compiled to ES7 async/await and later on transpiled by Closure compiler to something lower like ES5 or ES6?
we are aware of it and we have thought about it - but there’s a non-trivial amount of assessment that needs to take place
@skrat no idea, the first thing is to figure out what’s involved and what the benefits/tradeoffs are
@dnolen is there a place where we could collaborate and accumulate the information on some structured way? ie. not a Jira ticket, more like wiki page
I wouldn’t bother with steps since we’re not going to consider anything until after tradeoff / benefits
I will say that having talked to people that transpile ES6 generators to ES3, the debugging story isn’t exactly great
I don't think anyone needs to target ES3 at this point, ES5, optionally ES6 via build options would do
I think debugging story is a good goal to have, it's one of the things that people complain a lot when dealing with errors in cljs.core.async
code
yepp, agreed. the output size evidence can be very objective, but the debugging story is very subjective, like the readability of stack traces, async debugging tools in Chrome/FF
although I feel this appeals to many devs, I'm not sure how to gather evidence on that 🙂 survey perhaps? See how the 2016 comes out
> CLJS code becomes signficantly simpler to maintain
do you mean maintainability of cljs.core.async
itself?
@skrat code size matters, but I suspect dead code elimination trumps any smaller optimization
not in my experience, those state machines are huge and dead code elimination does nothing on them
we have our own little compiler that rewrites Clojure into SSA - we won’t need that any more
Another thing to consider with async/await for core.async is the task vs microtask behaviour. core.async uses goog.nextTick which enqueues tasks, promises use microtasks. It wasn't clear to me whether async/await uses tasks or microtasks from some quick googling. More info here: https://github.com/binaryage/cljs-devtools/issues/20#issuecomment-257399432 (apologies for butchering the terminology and language here).
@danielcompton async/await is probably too high level to consider for this anyway - I don’t think we want to consider anything more than function*
& yield