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

@paul931224 Did you see this? https://github.com/Day8/re-frame-10x

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

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

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

this blog post has a nice explanation: http://blog.fikesfarm.com/posts/2015-09-07-messing-with-macros-at-the-repl.html

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 https://github.com/cgrand/macrovich

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

hi!

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

https://gist.github.com/otwieracz/18eee3d28d4d34d102af32689946eb6a

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

(inside reagent render anonymous function)

I have repeated arguments like: https://github.com/reagent-project/reagent/blob/master/doc/CreatingReagentComponents.md

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

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

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

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

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. https://gist.github.com/mfikes/9cbb37c19d422a6e34188279ed9d9274

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

https://gist.github.com/nooga/1a64b3d13f429bccc4ce414ef3f33a94 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.

@mfikes interesting

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: https://github.com/mfikes/chivorcam

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