Fork me on GitHub

I think its because it doesnt permit operations unless it goes through the virtual dom


And potentially resets them as they happen. Like it does with css stylings


Many thanks though. From what I can tell the second way might be more idiomatic


IMO, cljs should support macro directly(define in cljs & refer like normally var). use :require-macros very painful,

Roman Liutikov09:09:54

@isaac it does, but then you have to ship the whole compiler into the browser

Roman Liutikov09:09:41

also you don’t have to :require-macros bc cljs compiler infers it automatically


which compiler supported? @roman01la


lumo repl treat macro as function.


@isaac this is a gotcha in ClojureScript. The same will happen in a regular JVM CLJS REPL


but TLDR: macros need to be defined in a separate “compilation stage”


Lumo and Planck could theoretically do what you’re requesting above (support macros directly). However that would be fragmenting the ecosystem, which would in turn mean that certain libraries would only work in a self-hosted environment, for example


If you really want to intermix macros and functions in one file, without direct support from the compiler, you can use


(This won't help you at the REPL though)


I don't know if I am not seeing something, or what, but I have strange issue:


By some reason, validation suddenly changes meaning in this code.


(inside reagent render anonymous function)


But why does validation suddenly contain value of value?


OK, I think I got it.


With multiple arities, I've been calling components with () instead of [].


@coinedtalk yes, I used it once before, pretty handy


Do you prefer channels or promises for one offs like HTTP requests?


@mail228 I think most prefer something basic like promises because channels usually require a bit more ceremony and only really add value when doing complex async things


yeah. I started out using channels a lot and now I’m 💯 promises


huh! you must have (impossibly) seen my presentation at ClojuTRE (to be delivered on Friday) @martinklepsch

😄 4

that's exactly the argument I'm going to make


(or part of it)


especially since a lot of front-end projects use something like reagent or re-frame to coordinate state changes, that consumes a lot of the utility that core.async channels offers

👍 4

I actually wonder why a state management lib hasn’t been borne out of channels. performance maybe?


or just that core.async is more complicated than most people want to deal with


yes I think that's it - it solves a problem that frontend projects don't have, transforming streams of values with buffering (which I haven't needed in a browser) and configurable parallelism (which doesn't exist in JS)


David Nolen has talked about core.async being too much plumbing in day-to-day apps. I think Tim Baldridge has made comments about it's over use too.


Good to hear, glad I just picked promesa and used that for handling some API calls 👍


Was afraid I was missing out on some channel mojo but it seems overkill when there is no stream


core.async for state management just isn’t a good idea, people explored that including myself - just leads to messes IMO

👍 8

also sounds like people are misinterpreting with Tim & I meant - we saw lots of code bases that just use core.async everywhere with too small of a value add


I would use core.async even for trivial async stuff


but I wouldn’t plaster it all over a code base without thinking about whether it’s actually simplifying anything

👍 8

most times,I write a simple macro just required by cljs,not for clj。that very good if cljs support macro directly


@isaac Advanced compiled and deployed CLJS artifacts don't ship with their compiler built in, so you have no eval in non-self-host mode, which means there's nothing to compile the macros at runtime.


Macros are “gone” by the time compilation is done. (In fact by the time analysis is done.) The real problem, as I see it, is that macros are functions called by the compiler. Since the non-self-host compiler is written in Clojure and runs in the JVM, they’d need to be compiled by and callable as Clojure. That would be simple enough to arrange, but then those macros cannot call any functions during expansion (unless they are also compiled as Clojure). In the end, you can see that there are two compilation stages that need to be teased out of a namespace’s code. The current solution is to have the namespace split across a Clojure and ClojureScript file. Another approach that makes it look like you can mix things (but really they are kept separate) is Macrovich’s way of demarking sections of the namespace’s code text as belonging to the macro stage and the runtime stage as separate things.


I suppose you could have a separate cljs-macro


Understanding that it uses different semantics to produce forms


@john Yeah. If curious, here is one way defmacro could work in ClojureScript, but illustrating that more would need to be done to make it really work with fns.


I’m trying to figure out an implementation of “async channel” using async iterators in JS and found something peculiar. Any JS hackers present?

nooga21:09:09 So here 4, 5 and end never happen. I’m running node 10.10.0 and the process just terminates without any fireworks after printing 3 and going through lines 38 through 44. I’m puzzled.


I updated it to show how you'd have to define functions differently.


Actually, there is no reason that ^ needs to be a compiler patch. This can be done as a library:


@mfikes it seems others lisp(eg. elisp, common lisp) expand macros at runtime, maybe we can make an approach in cljs


@isaac Well, FWIW, I made the chivorcam lib above work with self-hosted ClojureScript.

👍 16