Fork me on GitHub
#clojurescript
<
2018-01-19
>
justinlee00:01:41

I’m trying to get react-dnd working with rum. It uses the decorator style, which in es5, looks like DragDropContext(HTML5Backend)(YourApp) in javascript or

(let [decorator ((oget js/ReactDnD "DragDropContext") js/ReactDnDHTML5Backend)
        decorated-component (decorator (router-component))]
    decorated-component))
in cljs. The problem is that I can’t seem to get create element to accept this thing as a component. If I pass decorated-component to createElement as a symbol, the error is “cannot convert symbol to string” (makes sense). If I call it as a function, I get the _classCallCheck. If I instantiate it first like this (new decorated-component) react complains that it expected “a string (for build-in components) or a class/function (for composite components) but got: object”

thheller00:01:01

not sure how you are supposed to use native components with rum. maybe rum is calling it incorrectly?

justinlee00:01:14

actually I can remove rum from the equation:

(defn init! []
  (let [hello-component     (fn [] (js/React.createElement "div" nil "Hello World"))
        decorator           ((oget js/ReactDnD "DragDropContext") js/ReactDnDHTML5Backend)
        decorated-component (decorator hello-component)]
    (print "got here")
    (print (js/React.createElement (decorated-component) nil nil))))

justinlee00:01:37

^ same issue no matter how I pass decorated-component

justinlee00:01:12

this is like when you first learn lisp and you can’t see that you’ve wrapped something in extra parenthesis

thheller00:01:31

(js/React.createElement decorated-component nil nil) maybe?

justinlee00:01:45

Cannot convert a Symbol value to a string, which is a pretty confusing error message now that I think about it. createElement does take a string in that position but I’m not sure what could be trying to do a type coersion

justinlee00:01:09

oh god its because i’m trying to print out the result of createElement

justinlee00:01:11

@thheller thanks for rubber ducking that with me. there were so many levels of mistakes 🙂 but it appears to be working!

kenrestivo05:01:40

what's the least-ceremony way to get a remote nrepl or socket repl into a nodejs cljs env?

rauh06:01:39

@lee.justin.m The error may not have anything to do with it not working. You just can't print a symbol by default. See: https://github.com/binaryage/cljs-devtools/issues/25

justinlee06:01:37

@rauh the problem with the error is that it is similar enough to other errors that I didn’t realize what was going on. I still can’t manage to wrap a rum component with a higher-order decorator for reasons that are beyond me. its super frustrating because if i can’t figure this out i guess i have to rip it out and go back to reagent but that’s life

justinlee06:01:08

though i can get the decorators to work from clojure script by constructing react components by hand in clojurescript, so that’s positive

rauh07:01:15

So to the React class from a react component you can just write: (:rum/class (meta the-rum-component))

rauh07:01:05

Though, if the DND thingy accepts a functional component then just write a (single arity) function and pass that along which then just calls your rum component

rauh07:01:25

The interop is bad in Rum and it's a common problem. Any passed props probably also won't be available (haven't tested this).

justinlee07:01:06

sigh 🙂 I had actually gone with rum because it looked like it was less magic and more likely to interop well. react-dnd takes an ES6 class just fine in javascript, but you are right, that wrapping it in a function makes it work

rauh07:01:52

@lee.justin.m Yeah I just saw your comment on the rum repo 🙂

xiongtx07:01:42

Is there a correspondence b/t clj and cljs versions? I.e. cljs 1.7.x is guaranteed to work w/ clj 1.7.0? This is important for building test matrices on CI, where, for example, cljs 1.9.946 does not work w/ clj 1.7.0.

rauh07:01:38

@xiongtx There is not, no.

gklijs07:01:28

For my daily job I’m still stuck with java, but now there’s an opportunity to introduce clojurescript for the front-end as they want to restyle and make it api-based. But I’m afraid the lack of many clojurescript developers will put clojurescript of the table. Is it fair to say once set-up correctly it will not be that hard for a javascript developer to develop in clojurescript? Especially the syntax might put them off..

Jakub Holý (HolyJak)06:01:41

correct. @U8RQ36T7V has experienced this, the whole team went from js to cljs successfully Though they had 1 expert. Also, in my experience, hiring ppl interested in or knowing cljs is easy enough.

chrinaldini08:01:09

Yes, we had a big project that converted to CLJ and CLJS... It took a month before we surpassed the speed of developing in regular JS libraries, but after that the whole team was happy with the conversion.

carkh08:01:17

It always amazes me how important syntax is to people when programming is all about semantics.

carkh08:01:27

Not only that, they're not even preoccupied by the functionalities syntax may brings, but only by the looks of it

carkh08:01:05

I think that with a bit of mentoring the jump to clojurescript should be quite fast, that's what programmers do, learn languages

gklijs08:01:23

Yes, I grow into liking lisp more and more, but that’s not the case for everyone.

gklijs08:01:57

True, but if the only guy in the company which knows enough to mentor them might leave anytime because he’s hired from another company, and especially without another front-ender in the team..

carkh08:01:02

that kind of risk is always there. The guy has done the framework of your front-end (i'm not talking angular, but the whoel architecture)

carkh08:01:35

I'd rather have it done in a readable language like clojure

carkh08:01:11

and again it's not about syntax, but about noise ratio

carkh08:01:31

other languages fit that bill too

gklijs08:01:04

Yes, another strong point is the stable core, so if you set it up right it should be pretty easy to adopt the next front-end framework without needing to rewrite your whole application.

carkh08:01:36

I never successfully managed that feat... a framework is at the base of your code... they exist in clojurescript too (re-frame, om)

carkh08:01:46

not an easy task to switch

carkh09:01:22

clojurescript the language is quite stable, but the ecosystem is moving a lot

carkh09:01:30

but when something works, it usually survives clojurescript version changes

carkh09:01:45

i think that's what they mean by "stable core"

gklijs09:01:27

Kind of, you could kind of force yourself to write as much as possible in a cljc namespace, only using pure functions. But indeed there is always a lot framework dependent code.

carkh09:01:19

i find that in most cases business logic is only a smallish fraction of a project. gui and communication are the big ones

dpsutton18:01:27

has anyone ever seen this when compiling? > Caused by: java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to java.util.concurrent.Future

noisesmith18:01:35

cannot be cast to java.util.concurrent.Future has always meant someone was using deref in my experience

noisesmith18:01:45

any use of deref when compiling is… weird

dpsutton18:01:04

yeah. and i believe this code is correct. rerunning the build step locally

dpsutton18:01:44

and the file that it complains about is a cljs file

noisesmith18:01:44

even if the code normally behaves properly at runtime, calling deref while compiling is a big smell

dpsutton18:01:03

this is clojurescript file. doesn't that isolate this to the compiler itself?

noisesmith18:01:19

it could be a badly written macro

dpsutton18:01:48

reran the jenkins job and it succeeded.

noisesmith18:01:47

we’ll never know. ¯\(ツ)

dpsutton18:01:07

oh well. thanks as always

mfikes18:01:19

@dpsutton If you still have the stack trace, it might be similar to the one in https://dev.clojure.org/jira/browse/CLJS-2171

dpsutton19:01:08

looks identical up to file names

dpsutton19:01:20

you are a wealth of information mfikes

ajs19:01:55

What would cause a lein cljsbuild auto to suddenly switch from building a dev version to building a prod version after watching for a change and rebuilding? in one line it says it’s building from ["src" "env/dev/cljs"] and in the next line it says ["src" "env/prod/cljs"]

mfikes19:01:09

@dpsutton Your failed build involves :parallel-build true right?

mfikes20:01:28

@dpsutton Patch attached to https://dev.clojure.org/jira/browse/CLJS-2171 if the issue keeps recurring for you. I suspect it is unlikely you can used a patched ClojureScript compiler in your Jenkins setup, but letting you know nevertheless. 🙂

dpsutton20:01:34

this was the first time we've seen it that i know of and I just recently added the first use of core spec alpha. if that lends some credence to your working theory

mfikes20:01:02

Yes, it does, because it centers around the need to include specs in the cache files that are emitted at analysis time. If spec is never used, I think this codepath ends up being effectively skipped. So, the use of specs could definitely provoke the compilation failure. (And you need to be using parallel for the theory to hold water.)

dpsutton22:01:44

Yeah saw y'all discussing it

dpsutton22:01:31

I never thought I would say this but I'm glad it's not deterministic so at least the build can sometimes succeed :)

avery22:01:34

I'm trying to write a function ideref? in ClojureScript similar to ifn?, but I'm running into the craziest implementation difference between Clojure and ClojureScript. Can anyone make sense of this: Clojure 1.9

user=> (instance? clojure.lang.IDeref (atom nil))    
true                                                 
user=> (satisfies? clojure.lang.IDeref (atom nil))   

NullPointerException   clojure.core/instance?--5126 (core.clj:144)
user=> (deref (atom :foo))                      
:foo 
ClojureScript 1.9.946
Delete this message sent from Ryan Neufeld
cljs.user=> (instance? cljs.core.IDeref (atom nil))                                            
false                                                
cljs.user=> (satisfies? cljs.core.IDeref (atom nil))                                           
false
cljs.user=> (deref (atom :foo))                           
:foo

bronsa22:01:25

try cljs.core/IDeref in cljs

avery22:01:50

cljs.user=> (instance? cljs.core/IDeref (atom nil))
false

bronsa22:01:39

re: the NPE in clojure, satisfies? works with protocols not interfaces

bronsa22:01:47

I don't know what's going on in cljs

avery22:01:56

@bronsa: yeah, the NPE makes sense. Cljs stuff gets even weirder...

cljs.user=> (instance? cljs.core.IAtom (cljs.core.Atom. nil))
false
cljs.user=> (instance? cljs.core/IAtom (atom nil))
false

avery22:01:10

Can't get a positive no matter what combination of those I try

bronsa22:01:31

yeah looks like instance? is broken here

bronsa22:01:02

btw I get

cljs.user=> (satisfies? cljs.core/IAtom (atom nil))
true

avery22:01:10

A co-worker pointed out you need to use satisfies? like so: cljs.user=> (satisfies? cljs.core/IAtom (atom nil)) because of this JIRA ticket

avery22:01:19

Hah, yep.

bronsa22:01:44

maybe that's just how instance? works in cljs

bronsa22:01:05

I guess that makes sense, instance? in clj because IAtom is an interface but satisfies? in cljs because it's a protocol

xiongtx22:01:55

> Protocols are not reified as in Clojure, there are no runtime protocol objects https://clojurescript.org/about/differences

xiongtx22:01:19

Also, where is it documented that we need cljs.core/IDeref instead of cljs.core.IDeref? This was a total surprise to me.

dnolen22:01:41

@xiongtx the later thing is a JVM-ism

dnolen22:01:07

very host-y

dnolen22:01:39

Clojure isn’t based on protocols, Java interfaces

bronsa22:01:31

plus protocols are vars even in clojure, so (satisfies? foo/bar x) would be valid in clojure

avery22:01:32

If that's true though, shouldn't it just not be in ClojureScript at all? If not, maybe the documentation should tell me not to use it (and what I should do instead)

cljs.user=> (doc instance?)                        
nil                                                                                       
cljs.user=> instance?                                
#object[cljs$core$instance_QMARK_]

dnolen22:01:55

@avey_q I don’t know what you mean

dnolen22:01:06

you’re talking about JVM stuff

dnolen22:01:20

the fact that interfaces work on instance? is just Java stuff

dnolen22:01:32

but also the answer is “no”

dnolen22:01:38

there’s nothing new that wasn’t true in 2011

avery22:01:43

Sure, that is true. I'm reflecting more on the quality of experience with regards to Clojure vs. ClojureScript. Perhaps it could be more self-evident or properly explained why instance? doesn't work in ClojureScript when I try to use it?

dnolen23:01:30

if you want to improve the docs, PRs to the site are welcome 🙂 we try our best but documenting things just the right way for different people is challenging

dnolen23:01:57

@bronsa well they are “vars” too in the ClojureScript sense, but that means static

bronsa23:01:35

yeah but I meant it wrt the resolution scheme

lum23:01:08

hi, where can I find the simplest example of reading form input fields from html, and write back to <p> element (or other) after some sort of calculation?

dnolen23:01:34

@avey_q looking at the docstring of instance?, we could clarify that it only tests concrete JS types and the prototype chain, and note that it won’t for protocols and point to satisfies?

dnolen23:01:48

that’s easy patch, and welcome too

avery23:01:11

@dnolen: I'll take a look and see if I can write that. TBH I know very little about the JS side of things. Perhaps you can help tweak the verbiage there if I get a patch up?

ajs23:01:29

What would cause a lein cljsbuild auto to suddenly switch from building a dev version to building a prod version after watching for a change and rebuilding? in one line it says it’s building from ["src" "env/dev/cljs"] and in the next line it says ["src" "env/prod/cljs"]

justinlee23:01:09

is it possible that it is watching both and something changed that only affects on or the other?