https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial#building-a-simple-auto-completion-widget

a detailed explanation of how Om Next remotes work - demonstrates where core.async is actually useful

and shows how components can be incredibly declarative, no control logic gunk

Is there something that someone can point me to that gives me a concise explanation of the difference between om and om.next? (in my case..: I'm fairly fluent in react, and I've basic usage of om, but I'm completely out of date on the current developments)

There is an #C06DT2YSY channel just fyi. Om next is more of a framework than Om now. It incorporates ideas from Netflix’s Falcor and Facebook’s Relay libraries and tries to provide a complete solution for managing syncing data between the client and the server.

Ah, I didn't realise it had its own channel. I think you've given me enough of a base to not-so-blindly start looking into it myself, thanks

have you seen some of David’s talks?

Not since the first releases

If there's an Om next talk that you'd recommend then link me and I'll watch it

Otherwise, I can alway google

His recent talk from the conj is probably a great place to start to get an idea of where he’s coming from. The docs are sparse and things are moving fast right now.

https://www.youtube.com/watch?v=MDZpSIngwm4

Awesome, thank you very much 😄

np!

I’m excited about a macro I’ve experimented with tonight, and want to share how it is helping me to understand FP. It’s very similar to letfn, but focuses on syntactic sugar rather than mutual recursion, relying upon function literals #():

(let# [life (+ 4 %)
       universe (* % 10)
       everything (-> % inc inc)]
  (-> 0 life universe everything))

It’s just a wrapper of a macro, but I’ve found that let puts me in an imperative mindset, and let# puts me in a functional mindset. As I refactored three or four functions with the macro, I found patters in my usage of let. Then I found patterns within those patterns. Eventually, my functions became small and discrete, resembling those lego-block pieces I’ve always thought FP would lead me to, but could never quite get to!

(let [life #(+ 4 %)
       universe #(* % 10)
       everything #(-> % inc inc)]
  (-> 0 life universe everything))

@wildermuthn: if you write it like this you are not restricted to using functions 😛

Ah! But that’s what I found so helpful. I was forced to write functions, and it was easier to do so too.

@wildermuthn: there's also letfn:

(letfn [(life [x] (* 4 x))
        (universe [x] (* 10 x))] 
  (-> 5 life universe)) ;; 200

@borkdude, thanks! I did start out using letfn, but found the extra parens and required params to too much overhead. I tried @thheller’s model next, but I found the code too messy and the typing of # onerous. A little bit of syntactic sugar helps me to focus on the purity of composing functions. But that’s me!

@wildermuthn: take note that the first rule of macro club is: don't write macros

@borkdude, have to disagree with the conventional wisdom there. If that was true, we’d wouldn’t have let, if-let, when-let, letfn, etc. I’m on board with reader macros being toxic to the ecosystem, but I think it’s good to experiment. For me, that’s one of the best parts about lisp. I think conventional thinking is better left to conventional languages.

letfn isn’t a macro, special form

@wildermuthn: sure, as a mind-expanding exercise, it's cool 😉

and @borkdude advice holds

I usually don't even use letfn, because I have to look up the syntax. let usually does the job just fine

I come from a common lisp background, so I might be biased!

you see macro overuse in nearly every lisp

Common Lisp, Clojure & Scheme are not exceptions to the rule

@wildermuthn: I think in Clojure there is a shift from macros towards data. For example, some routing libraries use macros to define routes, but as time went on people understood that expression those routes using just data was a better idea.

so: functions + data > macros

One of the problems with macros is that they don't compose (can't take the value of a macro)

@dnolen, @borkdude, no disagreement here, on either overuse or with using data when possible. But I’m happy to use small simple macros that make my life easier. I get into trouble when I make big complex macros that only seem to do so.

right the tradeoff is just whether it’s important that other people can read the code

this may or may not matter depending on what you are doing

but it’s the reason I don’t bother with little sugar-y macros anymore

only boilerplate removal or “serious” macros

I can see going down a rabbit-hole with sugar-y macros.

and by boilerplate I mean “serious automated code generation"

In my experience, macros mostly come from libraries (clojure.core, core.async -> go, etc), but as a consumer of those libraries I don't have many occasions when I really need to roll my own.

is there some cljs.core helper to convert a seq into an JS array? clj->js is not a good fit, because I don’t want a deep conversion

@darwin: write a macro?

Kidding.

😉

need to do that dynamically, writing some other macros which depend on .apply 😉

@darwin: what about (apply array [{:foo "bar"} {:bar "baz"}])?

@borkdude: won’t work, array is a macro

AFAIK

I just tested it here and it worked. http://clojurescript.net/

@borkdude: you are right, interesting, I will try it, thanks

I looked in the cljs.core sources and I saw "core/defmacro array …”, am I missing some other version which is a function? or why this works?

@darwin: I see that there is also an into-array function

@borkdude: that’s the one I was looking for

thanks

@darwin: and also to-array

@borkdude: now it makes more sense I got puzzled because intellij started showing me clojure sources, not clojurescripts’s while I was writing macros, that’s why I wasn’t able to find anything familiar

I knew there was something

I love the docstring of to-array: "Naive impl of to-array as a start."

@darwin: what is a nice feature from the cljs repl, try (apropos "array")

@darwin macros live in a different namespace

most people are confused and don’t realize ClojureScript has a unique macro system that is very different from Clojure's

macros and vars live in different namespaces

this means you can have a macro array and a function array

this is impossible in Clojure

this is how we do inlining for many operations, arithmetic, array construction etc.

@dnolen: thanks for explanation, so when I have both macro and function with the same name, how compiler knows which one to use? it tries macro first? in case of apply macro cannot be used, so it uses function instead?

macros only work if they are the first element of the form

(apply array …)

clearly won’t match

aha, so apply works with macros, they just cannot be passed as parameters, makes sense, now. I thought macros and apply does not work at all

so, (source array) could have returned the source for the array macro as well

@darwin: in the case of apply, I think the first argument always has to be a function

ok, have to go, will think about it more

no apply doesn’t work with macros

(apply array …) invokes the array function at runtime.

the array function and array macro shall never meet.

hi all! just pushed out my node/npm clojurescript package https://www.npmjs.com/package/clojurescript

i am really excited to use clojurescript in node-only environments, like Electron or embedded platforms, and this is a first step in that direction

open to feedback, bug reports, and pull requests! have at it!

@nasser: Nice!! Trying it out

@nasser: cool!

replumb candidate 😄

@nasser, this is really exciting for getting ClojureScript apps distributed via npm!

https://asciinema.org/a/30489