This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-19
Channels
- # adventofcode (4)
- # beginners (80)
- # boot (4)
- # cbus (2)
- # cider (62)
- # clara (18)
- # cljs-dev (8)
- # cljsrn (10)
- # clojure (139)
- # clojure-brasil (3)
- # clojure-dev (27)
- # clojure-italy (1)
- # clojure-russia (3)
- # clojure-spec (4)
- # clojure-uk (47)
- # clojurescript (102)
- # core-async (10)
- # cursive (7)
- # datomic (71)
- # emacs (32)
- # fulcro (99)
- # funcool (1)
- # hoplon (3)
- # jobs (1)
- # jobs-discuss (6)
- # jobs_rus (2)
- # leiningen (3)
- # luminus (2)
- # lumo (14)
- # mount (7)
- # off-topic (19)
- # re-frame (25)
- # ring-swagger (4)
- # rum (3)
- # shadow-cljs (142)
- # specter (2)
- # sql (16)
- # timbre (1)
- # vim (3)
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”not sure how you are supposed to use native components with rum. maybe rum is calling it incorrectly?
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))))
this is like when you first learn lisp and you can’t see that you’ve wrapped something in extra parenthesis
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
@thheller thanks for rubber ducking that with me. there were so many levels of mistakes 🙂 but it appears to be working!
what's the least-ceremony way to get a remote nrepl or socket repl into a nodejs cljs env?
@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
@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
though i can get the decorators to work from clojure script by constructing react components by hand in clojurescript, so that’s positive
So to the React class from a react component you can just write: (:rum/class (meta the-rum-component))
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
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).
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
@lee.justin.m Yeah I just saw your comment on the rum repo 🙂
Is there a correspondence b/t and versions? I.e. 1.7.x
is guaranteed to work w/ 1.7.0
?
This is important for building test matrices on CI, where, for example, 1.9.946
does not work w/ 1.7.0
.
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..
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.
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.
It always amazes me how important syntax is to people when programming is all about semantics.
Not only that, they're not even preoccupied by the functionalities syntax may brings, but only by the looks of it
I think that with a bit of mentoring the jump to clojurescript should be quite fast, that's what programmers do, learn languages
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..
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)
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.
I never successfully managed that feat... a framework is at the base of your code... they exist in clojurescript too (re-frame, om)
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.
i find that in most cases business logic is only a smallish fraction of a project. gui and communication are the big ones
has anyone ever seen this when compiling? > Caused by: java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to java.util.concurrent.Future
cannot be cast to java.util.concurrent.Future
has always meant someone was using deref in my experience
any use of deref when compiling is… weird
even if the code normally behaves properly at runtime, calling deref while compiling is a big smell
it could be a badly written macro
we’ll never know. ¯\(ツ)/¯
@dpsutton If you still have the stack trace, it might be similar to the one in https://dev.clojure.org/jira/browse/CLJS-2171
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"]
@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. 🙂
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
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.)
@dpsutton Hopefully this fix for the issue clears things up https://github.com/clojure/clojurescript/commit/9ddd356d344aa1ebf9bd9443dd36a1911c92d32f
I never thought I would say this but I'm glad it's not deterministic so at least the build can sometimes succeed :)
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
@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
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
I guess that makes sense, instance? in clj because IAtom is an interface but satisfies? in cljs because it's a protocol
> Protocols are not reified as in Clojure, there are no runtime protocol objects https://clojurescript.org/about/differences
Also, where is it documented that we need cljs.core/IDeref
instead of cljs.core.IDeref
? This was a total surprise to me.
plus protocols are vars even in clojure, so (satisfies? foo/bar x)
would be valid in clojure
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_]
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?
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
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?
@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?
@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?