hi, I'm using re-natal and re-frame to write an android app

but i get some weird error. https://github.com/Day8/re-frame/issues/228#issuecomment-245084553

db is supposed to be a map in event handler but it's a promise in my case

what's the problem

?

@lxsameer did the comment on github make sense to you? Did you check through your code?

yeah my code is pretty basic. I just added the Linking event listener

I suggest maybe 1) #re-frame and 2) Maybe post the rest of your code for extra eyes

@am-a_metail hmm the code i posted to github is exactly what i have beside the default re-natal's template

@am-a_metail also can you please explain the github comment in a simpler language ? I'm not a native English person

I think the comment is saying that some other code is causing this error because it is not (assoc db :key val) but returning val instead

aha thanks

hello

why isn't the result (cljs.core/println 1 2 3 4) ?

I think I am being bitten by laziness. Why would

(.nodesBetween pmed.doc.content 0 900 (fn [node path parent] (print node)))

(.nodesBetween pmed.doc.content 0 900 (fn [node path parent] node))

@mac what is .nodesBetween? what happens if you place node after (print node)? possibly .nodesBetween doesn’t return anything, only iterates.

Does anyone have any experience using figwheel with WebGL? I'm perhaps looking for the interaction react gives to the DOM but against the WebGL state machine instead.

I'm with @keymone on this. .nodesBetween probably returns nil but (print node) is outputing node to REPL.

@keymone @agile_geek ...(print node) node)) produces the output and then nil. Was this what you meant?

Yes

@mac yes, seems like .nodesBetween just doesn’t return anything

@keymone @agile_geek Ok, is there a way to usefully interact with it from cljs? if I wanted the values in a vector?

@mac look for a function that does return objects. or use atom and swap! conj to collect nodes

@keymone @agile_geek Thanks, by look for you mean if the js library has a different function?

@mac: yes or use a let to scope an atom containing the vector and use swap! conj to accumulate the nodes into vector before returning the dereferenced atom at end of let.

as suggested by @keymone

@agile_geek @keymone Thanks a lot. Is there any reason why `js->clj`` would return a #object ? This is not related to my other question.

@mac something like htis (warning not tested in a REPL!):

(let [nodes (atom [])]
  (.nodesBetween pmed.doc.content 0 900 (fn [node path parent] (swap! nodes conj node)))
  @nodes)

@mac if the constructor/prototype isn’t exactly Object, we won’t touch it

@dnolen Ah so anything that inherits from something different than Object will not be converted?

nope

@dnolen i’m puzzled by this defmacro thing dimovich posted, do you know what is happening?

@keymone because macros take two “magic” initial arguments, env and form

well that explains it

thanks

thinking more about it, the above should work - but I’ve been given no information where this is being tried

Planck? Figwheel, etc

i tried here: http://clojurescript.net/

so that’s the problem

you cannot use the bootstrap stuff to know what the actual behavior is

there’s tons of edge cases still needing sorting out there

@keymone and that particular REPL is probably a year out of date

right.. will the recently released closure compiler for node help with cljs-bootstrap?

@keymone no

well only sort of - if you want to use advanced compilation with the generated JS from bootstrap

but you have a boatload of other problems to sort out beyond that

http://clojurescript.io, I believe this one is kept more up-to-date with ClojureScript changes

good to know, thanks

still the only definitive thing is using non-bootstrap ClojureScript for now

@keymone You also can’t define and use a macro in the same compilation stage, which means you can’t do this in a REPL

@mfikes is there a way to fake compilation stage in repl?

Yes

@keymone In self-hosted, you can play games with an internal implementation detail. It is described here http://blog.fikesfarm.com/posts/2015-09-07-messing-with-macros-at-the-repl.html

For your case, FWIW (in Planck):

cljs.user=> (ns foo.core$macros)
nil
foo.core$macros=> (defmacro m [& args]
             #_=> `(println ~@args))
true
foo.core$macros=> (foo.core/m 1 2 3 4)
1 2 3 4
nil
foo.core$macros=> (m 1 2 3 4)
(cljs.core/println 3 4)

But, to really do this stuff properly, the m macro needs to go into a namespace in a file and you need to require-macros to load it into your REPL.

@keymone Better reading on the compilation stage stuff is at http://clojurescript.org/about/differences#_macros and http://clojurescript.org/about/differences#_namespaces

@mfikes i’ll go through that as well, sounds fun 😃

@mfikes I was reading your article about eval in Planck, just curious to what the limitations are if any, compared to clj? Very nice I must way!

@hlolli The only corner case I’ve ever seen is described in https://github.com/mfikes/planck/issues/288

ok very nice. I have some clj projects I want to implement in cljs, since I do some metaprogramming, I would need eval. So these are good news.

@mfikes that post on macros in the repl is extremely cool and so helpful, thank you

@nickt Glad it helped 🙂

@hlolli I haven’t thought about it in detail, but I suppose a ClojureScript lib could be created that essentially provides an eval for anyone who wants it (even JVM ClojureScript users), where that lib internally employs self-hosted ClojureScript to implement it.

where can I read more about repl's ? I'm using CIDER and boot and would like to read more about providing a repl from a running app, so I can inspect and try things while the application is running

that would be possible, I can imagine the jvm being able to compile self-hosted clojurescript, with jvm even becoming redundant. With self-hosted cljs I see noting stopping cljs becoming a full fledge lisp. But I don't see any problem using planck/eval for now.

@dimovich this is pretty comprehensive: https://lambdaisland.com/guides/clojure-repls

@martinklepsch thanks!

@hlolli I’ve said it once and I’ll say it again. Self-hosted ClojureScript is always going to be a really awesome nice to have. It’s never ever ever going to be the main thing.

So anybody waiting for that, is going to be waiting a really long time 🙂

@dnolen I've heard you say that before some time ago, but lately I've been getting excited about the possibility of bootstraped core.async and possibly om.next. In the end we can always bootstrap JVM.js 😄 (joke).

heh

bootstrapped is very powerful and I expect it to go many, many cool places

and making sure it always work will always be a priority as evident by the commit history

but eliminating the JVM from ClojureScript - never going to happen

hey @darwin if you're around/not busy, this is what I've been working on the past week or so (the reason I kept bugging you with macro questions): https://github.com/nick-thompson/iss. It's pretty similar to https://github.com/noprompt/garden but has at least one pretty significant difference

thanks again for your help. I'd be curious to hear what you think

@nickt: I don’t have strong opinion about inline styles in general, I would have to study your readme and look at alternatives/current state of the art in more depth. I've used gaden a year ago, not for inline styles, but for composability when building my global app stylesheets: “css as data” is very powerful concept when coupled with rich set of data manipulation fns in clojure

looking at https://github.com/nick-thompson/iss/blob/master/src/iss/macros.clj, I would propose to explore the eval usage in the inline fn, you would get general constant folding and allow clojure.core fns from it for free, additionaly you could make selected namespace like iss.constants visible to eval as well

anyways, nice first step, I see, you’ve made nice progress

@darwin definitely. Garden looks awesome and I intend to borrow some of the expressivity, but it doesn't offer the same kind of statically-analyzable output that enables stripping out style declarations from your js and building actual external stylesheets

so far I haven't found an alternative that does... most of them dynamically insert <style> tags at runtime

or use actual inline styles

Also – that sounds awesome with eval, I'll totally give that some time. Still new to macros in general 😛

@nickt that looks interesting! i'll have to take a closer look soon. it's awesome that you're bringing this to the table. i've actually been in the process of working on the next release of garden (but i've mostly been keeping that to myself).

@darwin i should have an alpha ready within the next couple weeks of the next version of garden. it dramatically extends the CSS as data concept even further opening the door for programatic transformations of the underlying CSS AST.

i know it's been getting a little stale but i've been working in clojure much more and i really want this next version to check several boxes that are now open issues as well as provide more extensibility.

@noprompt I’m glad to hear. Garden is great. Kudos! I would use it again, I just didn’t have CSS-heavy project on my hands lately.

the next version of garden includes a full blown CSS parser and unparser so raw CSS can be loaded and manipulated and used anywhere.

@noprompt thanks!

^ that sounds awesome

any chance you intend to make that happen at compile time?

so (css "h1,h2,h3 { font-weight: bold }") and (css [#{:h1 :h2, :h3} "font-weight: bold"]) are not only legal they're properly validated.

an ultimate library would do as much work as possible at compile-time and delegate rest to runtime, but this can be pretty hard to implement it this way, when things get more complex

@nickt i'll look at that. i really want to get some of the core problems garden faces now addressed before moving on to more advanced optimizations.

@darwin why would that be so hard?

I think that'd be pretty doable

doable yes, easy no

yeah, that's definitely not a weekend project. it's doable and easy to imagine but it's a lot of work.

i like those kinds of challenges though. 🙂

I imagine you could do something like "for each declaration: (at macro time) attempt to inline declaration, if succeeds, extract, else write original back"

have been working on a simple concept of (oget jsobj “key1” “key2”) to compile statically down to javascript jsobj[“key1”][“key2”] if possible, if not it would generate dynamic code

and give you diagnostics/warnings in debug build

@nickt that might be a worthwhile library that could leverage the new stuff that's going to land in garden. since the new version of garden uses an intermediate representation, an ast in the clojure.xml format, you could combine that with something like enlive to do what you're talking about.

basically you have to implement two code paths, one static in clojure and one dynamic in cljs: https://github.com/binaryage/cljs-oops/blob/f3768be97b2bdf387bf97e8fde15d2ef50a1aa8d/src/lib/oops/core.clj#L229-L233

so analyze the CSS AST and apply the styles to nodes which match in the HTML AST.

@darwin yeah. that technique can be tricky. sablano does the same kind of thing with it's compiler/interpreter namespaces.

I'm not sure it needs to be that complicated even

(re: analyze css ast and match it to html ast)

one thing i might be able to do, no promises, is have garden work against the CSSOM in the client. that actually has better performance (or it least it did a long time ago) than inline styles but i'd have to be sure that was still the case. i looked at that stuff a couple years ago and things are always improving.

that would be pretty interesting

the hard part about it is that stylesheet objects are mutable and so you necessarily end up wanting to look at react style diff/patch operations which, for the majority of use cases, is not all that compelling. but in cases where you aren't using react it could be beneficial. i dunno, it seems like everyone is moving in the react-style direction so it's kind of low on my list of hip cool ideas i'd like to code up. 😄

speaking of react, has anyone written a pure clojurescript react-style renderer?

that assumes that the mutability of stylesheet objects is a good idea

😉

or rather, that that mutability is something we should seek to preserve in solutions moving forward

@noprompt: Are you expecting breaking changes in the next version of garden for the existing features?

@shaun-mahood i'm going to do my best to avoid breaking changes or, at least, provide a minimal path forward.

the only thing i've really changed with respect to syntax is how selectors are parsed. right now the selector part of a rule is written s1...sn the new syntax is s | [s1...sn] | #{ s | [s1..sn] }. the reason for the change is that the original approach of by taking the first n non-collection elements of the rule to be the selector makes it difficult to represent things like descendent selectors (now represented as [s1 s2 ... sn] (`s1 s2 .. sn`) and complex selectors #{[s1 s2] [s3 s4]} (`s1 s2, s3 s4`) as data. the selectors library was added to address that problem (and can still be used in the new version) but it can result in less than readable code, at least in my opinion.

i've also addressed the problem of writing raw css in garden. as i mentioned before garden will happily correctly parse a selector like "foo > bar, baz quux" just as if you'd written #{"foo > bar" [:baz :quux]} and won't break nesting.

that also applies to declarations the forms "border-bottom: 1px solid black", {:border-bottom "1px solid black"} and {:border-bottom [["1px" "solid" "black"]]} will all produce the same parse tree under the hood.

i don't think these modifications will break a lot of code and should require a minimal amount of updates. since i've included a parser for raw CSS it should be possible to provide a transitional parser which could get around the ambiguity when parsing a rule like [:h1 :h2 "font-weight: bold",,,] (since the parser could figure out that the selector is h1, h2).

garden's current parser is extremely dumb and will think "font-weight: bold" is a selector because it's not paranoid and totally believes in the benevolence of the programmer. 🙂

@noprompt: Sound like good changes, worth it if something breaks (at least for me).