Fork me on GitHub
#clojurescript
<
2016-12-15
>
adamfrey00:12:02

@terje I am using that library. Do you have an sample of some code using it?

terje00:12:16

@adamfrey Not yet, but it’s on my roadmap.rimshot

terje00:12:25

I am using google-maps with #reagent in production though, but had to write my own integration.

danielstockton07:12:50

Does anyone work with websockets and a non-clojure backend? What library/ies, if any, do you use?

danielstockton07:12:49

sente appears to be for a clojure/clojurescript pairing, chord looks like it might be useful.

crankyadmin13:12:19

Slightly off topic… 401 is the correct response to send when failing a login over a API, right?

manutter5113:12:44

Yes, 401 "Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided."

hbprince13:12:03

garden -> css file ?

hbprince13:12:22

please check the question, seems like none answered

manutter5113:12:24

@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.

hbprince13:12:57

@manutter51 try to answer if you can ..

manutter5113:12:36

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

hbprince13:12:59

seems like its server side rendering :thinking_face: , will check 🙂 thanks the question is about precompiling garden/hiccup files to html & css

Aron14:12:16

^--- 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...

val_waeselynck14:12:46

@ashnur when does this happen ?

Aron14:12:24

right now 🙂

val_waeselynck14:12:26

if this is in the REPL, I usually see this when my strings or dates are badly formatted

Aron14:12:34

i am using figwheel

val_waeselynck14:12:45

@ashnur I meant in what circumstances

Aron14:12:46

there are no strings or dates in the file

val_waeselynck14:12:11

maybe unbalanced parens?

Aron14:12:16

@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

val_waeselynck14:12:36

"I was loading a CLJ file" would have helped 🙂

Aron14:12:20

but i am not doing that, or at least not explicitly

Aron14:12:55

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

Aron14:12:10

i wish my editor would help me with this

val_waeselynck14:12:21

obviously we still have progress to do w/ error reporting

val_waeselynck14:12:30

what editor are you using, out of curiosity ?

Aron14:12:52

spacemacs

val_waeselynck14:12:11

ok, not my area of expertise unfortunately

Aron14:12:12

but it says cider not connected and i have not had the courage to try to solve it

martinklepsch14:12:24

@ashnur check for unbalanced parenthesis

Aron15:12:41

i am looking for those clojurescript idioms people mentioned yesterday 🙂

Aron15:12:48

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

tobiash19:12:51

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?

dnolen19:12:47

@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

tobiash19:12:23

@dnolen I saw you mentioning the new externs inference, is that useable already?

dnolen19:12:38

@tobiash no, you need master and people need to try it out first

dnolen19:12:59

I suspect it will take at least a couple of months before anybody will have any real confidence in it

dnolen19:12:09

but that will only happen if people try it

tobiash19:12:04

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

tobiash19:12:42

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

dnolen19:12:48

@tobiash understandable point of view, but note for a lot of users it’s really not a significant barrier

dnolen19:12:37

and integrating with seamlessly with the wider JS system is always going to be a non-goal

dnolen19:12:11

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.

tobiash19:12:03

yes, I understand, and even when I can use JS libraries, dealing with the interop code often leads to repetitve boilerplate code

jrheard19:12:31

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

jrheard19:12:07

but maybe the js libraries i’ve been using are particularly well-behaved

dnolen19:12:45

@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

tobiash20:12:32

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

dnolen20:12:08

@tobiash it might be helpful to see what type of “boilerplate” you find yourself writing - it may or may not be avoidable

dnolen20:12:15

but no one can tell you if there’s no code to look at

dnolen20:12:50

also the whatever issues you may have with your firebase calls

skrat20:12:40

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.

dnolen20:12:29

@skrat it’s something to think about, that’s all

skrat20:12:18

@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?

dnolen20:12:21

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

dnolen20:12:01

@skrat no idea, the first thing is to figure out what’s involved and what the benefits/tradeoffs are

skrat20:12:05

@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

skrat20:12:42

and figure out the tradeoffs, the benefits, and the steps required to get there?

dnolen20:12:47

@skrat you’re welcome to make ClojureScript wiki page

skrat20:12:07

@dnolen 👌 sounds good to me

dnolen20:12:27

I wouldn’t bother with steps since we’re not going to consider anything until after tradeoff / benefits

dnolen20:12:07

I will say that having talked to people that transpile ES6 generators to ES3, the debugging story isn’t exactly great

dnolen20:12:22

the immediate benefit which really doesn’t have anything to do with debugging

dnolen20:12:40

is that the core.async CLJS code becomes signficantly simpler to maintain

skrat20:12:57

I don't think anyone needs to target ES3 at this point, ES5, optionally ES6 via build options would do

skrat20:12:08

but that's very opinionated so let's not go in there

dnolen20:12:12

we don’t generate ES5

dnolen20:12:20

we just generate ES3

dnolen20:12:30

and yes that discussion is not relevant anyway

skrat20:12:02

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

skrat20:12:28

output size is another one that matters to many

dnolen20:12:58

@skrat sure, but those things need evidence

skrat20:12:00

@dnolen could you elaborate a little bit on the CLJS code maintainability?

dnolen20:12:22

that’s what the wiki should focus on - evidence of suggested benefit

dnolen20:12:35

otherwise no one is going to look at it seriously

skrat20:12:24

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

skrat21:12:19

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

skrat21:12:01

> CLJS code becomes signficantly simpler to maintain do you mean maintainability of cljs.core.async itself?

dnolen21:12:52

@skrat code size matters, but I suspect dead code elimination trumps any smaller optimization

dnolen21:12:58

so I wouldn’t be surprised if code size is just a wash

skrat21:12:44

not in my experience, those state machines are huge and dead code elimination does nothing on them

dnolen21:12:49

we have our own little compiler that rewrites Clojure into SSA - we won’t need that any more

dnolen21:12:07

@skrat but if you don’t use a state machine in some lib who cares

dnolen21:12:15

anyways this is just talk we don’t need more talk

dnolen21:12:17

just metrics

danielcompton21:12:43

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).

dnolen21:12:25

@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