Was going over the guides for Om Next, and there's a section of code that I can't seem to work out.

(defn get-people [state key]
  (let [st @state]
    (into [] (map #(get-in st %)) (get st key))))

hi! is it any correct way to pass cljs data between two windows? now i can do it, i can print it, it looks good, i can deref atom, but i can't get value from map by keyword

@andre interesting question. is it possible that keywords from different JS contexts will have different values?

what happens with string keys?

i didn't try string keys

had the same thoughts about keywords context

also i'm using reagent for rendering this passed data, and reagent doesn't rerender it, something wrong with this data

passing this data as edn? i don't think this is a good idea

@andre there’s no support for cross context JS - it just not worth the trouble

@dnolen ok, thank you, сan you advise something to "serialize" data between contexts? data->edn (json?)->data ?

Transit is probably best option here

thank you, i'll look

@andre depending on how much data, yes EDN could work - Transit will be a bit faster.

I think lein-externs provide a very simple approach for generating externs file, why not cljs-build or cljs-compiler use it by default?

@doglooksgood: because we don’t integrate anything around Leiningen

it could be that lein-externs works reasonably well but it doesn’t have enough users to appear to be properly vetted for integratino into any other tooling

I mean this plugin just use some regex to find which name should be preserve. It's quite simple.

which isn’t going to work when a JS library programmatically generates names

got it.

which isn’t exactly uncommon given the lack of more static forms of metaprogramming in JavaScript

I've found your talk for next 5 years for ClojureScript. You mentioned about externs

Hope one day we don't need to generate externs manually. 🙂

yes eventually

did anyone have issues updating from clojurescript 1.8.40 to 1.8.51 or later? Its the point where the closure-compiler is upgraded to v20160315 (if thats related I’m not sure). My dev app works, and advanced compilation builds without error, but in advanced comp my app does not even mount. Not sure where to start debugging 😕

i am also on om 1.0.0-alpha44

nobody reported anything like that that I can recall

@kenbier is there any reason to not just bump to 1.9.229?

there might be some Om changes that are the problem

@dnolen i see, ok. i tried bumping to 1.9.229 as well but i saw the same issue. every version before 1.8.51 seems to work.

@kenbier then need way more information

so far we have none 🙂

“not working” is not information

haha yeah i agree.

is there anything that would be helpful to know?

currently using clojurescript 1.8.40, clojure 1.8, om alpha44, and i had to exclude guava from datomic “0.9.5344” because it was colliding with the google-closure version

im in the middle of trying to update our core dependencies. we were on om 1.0.0-alpha36 and clojurescript 1.7.228. I was able to upgrade om to alpha 44 and clojurescript to 1.8.40. if i upgrade to 1.8.51, and exclude guava from datomic, i get a build with no errors. but when i load my app, the “app” div is just an empty div. no console errors, build errors or network errors. the outputted js is there as well.

i realize thats not enough information but thats where i am right now in debugging. before i went deeper i wanted to check if moving to a new google-closure version broke some peoples build, which it does not sound like it did. so ill do some more research

thanks for the help

@kenbier yeah that’s just not enough information

@kenbier a couple of tips, make a advanced build with prettying printing and pseudo-names enabled

set some breakpoints

:pretty-print true :pseudo-names true

@dnolen ill try that now. thanks!

has anyone found / written any good resources on using spec with figwheel? my thinking was placing the cljs.spec.test/instrument calls in the :figwheel-on-js-load function but it does not seem to instrument fns, my guess is somehow they are getting overwritten after instrumentation by something in figwheel

I also have not been able to Google anyone having similar issues

If I have core.cljs and core.clj, is it possible to use the macros in core.clj in core.cljs? Just trying to directly call my macros, without adding anything to my :require, results in WARNING: Can't take value of macro

It seems like the above is possible according to this https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure#macros > ClojureScript namespaces can require macros from the selfsame namespace, so long as they are kept in different compilation stages. So, for example a foo.cljs or foo.cljc file can make use of a foo.cljc or foo.clj file for its macros.

Duh, you have to add :require-macros for your namespace.

@owen instrument needs to be called after your fdefs

@dnolen it is

Im able to get instrumenting working

my goal is to have it in the /dev classpath

so I dont have to manually eval the instrument calls, and it will be elided in the uberjar cljsbuilds

@ownwaterloo note instrument isn’t a runtime thing

it’s not the traditional notion of “after” here

I mean after the compiler has seen all your fdef files

oops @owen ^

if I had the :figwheel-on-js-load call a fn (do (fdef things.....) (stest/instrument 'fdef-ed-fn))

would you not expect that to work?

depends, I don’t know how that figwheel thing works

I assume you have some experience with what it does

🙂

I never use that, so no

oh my bad, it will do hot code reloading

so om or reagent will get revalued after file changes

but remember

fdef instrument are static

if Fighweel isn’t recompiling that expression everytime, it isn’t going to work

sorry yeah the :figwheel-on-js-load is a setting in project.clj which will call a function when it detects file changes

so that function should be getting called on every change

you’re missing what I’m saying

but my guess is its happening in the wrong order

sorry

calling a function isn’t going to help you

recompiling the function every time is going to help you

ah

but I doubt it works that way

it’s probably far simpler to just have a dev namespace

which requires everything you need that has s/instrument

:recompile-dependents true would allow you to edit other files and trigger this dev namespace to recompile

pretty sure this compiler option is disabled by Figwheel

hmm ok that all makes sense

especially the necessity of compiling the spec fns

thanks!

np

Is there a reason https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/specs.clj is not included in cljs yet? Seems as simple as adding the namespace, no?

its in there?

Where?

cljs.spec

No, specs.clj

Not spec 🙂

ah

@kenny not in because it doesn't work for CLJS

man my reading comprehension today

some of those specs are OK, some aren't

specifically ns form stuff isn’t going to work

Right. You can’t partially add the file - only the working specs?

yep, we’ll add them eventually - porting clojure.spec is high priority

Awesome!

How do you call var in cljs? I get a java.lang.AssertionError: Assert failed: (ana/ast? sym) when trying to call var.

Even stranger.. I am able to call var in the REPL. Are you not able to have dynamic calls to var?

@kenny vars in ClojureScript are static

you shouldn’t expect them to work like in Clojure

AFAIK their implementation is minimal enough for cljs.test to work

@anmonteiro You aren’t able to dynamically retrieve metadata from a symbol then? 😞

for a symbol that refers to a var?

Yes

maybe with some macro black magic, I’m not sure

I attach metadata to a function and I want to retrieve that at runtime

Yuck

which would be calling cljs.analyzer.api/resolve in the Clojure side of things

It wouldn’t be able to resolve cljs vars though, right?

it would, that’s what I’m telling you

Ah

That might work then

you pass it the &env and the var symbol

but note that most your expectations regarding vars in ClojureScript won’t hold

they’re not going to work like in Clojure

I was only hoping to get metadata off of them

Why do I need &env?

&env is the ClojureScript compilation environment

it’s where the analyzer will find your var

Ah, cool

then you need to think about how you’re going to return the metadata you find on the Clojure side to the ClojureScript runtime

probably worth more trouble than changing your implementation to something more solid

I will reconsider my implementation

How do you call the macro with &env?

&env is an implicit argument to the macro

it’s “there"

REPL throws exception with wrong args passed to macro

http://blog.jayfields.com/2011/02/clojure-and.html

Oh I see