This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-12
Channels
- # admin-announcements (2)
- # aleph (2)
- # arachne (16)
- # beginners (33)
- # boot (20)
- # bristol-clojurians (6)
- # capetown (4)
- # cider (50)
- # clojure (74)
- # clojure-austin (4)
- # clojure-canada (1)
- # clojure-china (2)
- # clojure-czech (1)
- # clojure-greece (1)
- # clojure-poland (4)
- # clojure-quebec (5)
- # clojure-russia (5)
- # clojure-spec (34)
- # clojure-uk (45)
- # clojurescript (131)
- # cursive (4)
- # datascript (2)
- # datomic (9)
- # editors (2)
- # emacs (2)
- # hoplon (173)
- # jobs (5)
- # lein-figwheel (3)
- # leiningen (1)
- # off-topic (1)
- # om (44)
- # onyx (8)
- # proton (10)
- # re-frame (81)
- # reagent (23)
- # untangled (57)
- # vim (2)
- # yada (8)
@dnolen: i understand we discussed the issue with bindings
inside go
, but i'm perplexed that CLJS-1705 was closed.
the docs specifically say:
> Creates new bindings for the (already-existing) vars, with the supplied initial values, executes the exprs in an implicit do, then re-establishes the bindings that existed before.
@eyelidlessness: where synchrony is implicit
those tests are all synchronous.
and there's no documentation of the problems with asynchrony, nor any warning
data corruption is a non-issue?
shouldn't it be documented how to use it correctly?
the data is corrupted. after the binding is closed, the vars are left bound
is this behavior present in clojure? clojure doesn't even provide the apis for a repro of that
but there is no clojure.test/async
that is how the bug i posted was triggered
the code is 100% synchronous
is there any chance of documenting that?
can i offer a documentation patch?
i would like to be able to reliably find out why i'm "using it wrong" and i'm sure others would too
> Creates new bindings for the (already-existing) vars, with the supplied initial values, executes the exprs in an implicit do, then re-establishes the bindings that existed before. The new bindings are made in parallel (unlike let); all init-exprs are evaluated before the vars are bound to their new values.
thanks slack.
oh you're asking for my proposed patch?
now imagine in the binding block you start a async thing which runs after binding block exits
i'd have to sit down and think about it
i'm asking if documentation patches are accepted and whether one (if adequate) would be accepted for this
i understand the problem with async (even though literally nothing in my repro code is async!)
will you hypothetically accept a patch?
I'm not clearly understand why so negative to accept patches just for improve the user experience. Some advice like "this function is not intended to work with asynchronous code" or " take care that using binding
will cause unexpected behavior on use together with async code". Something that can help user avoid bad situations and spend hours of time searching a solution/problem...
It is not about understand binding, is just about a small advice that it should not be used in async code. This will improve a lot the user experience and changes nothing in implementation.
i have written the externs for " https://apis.google.com/js/client.js" as var gapi = { "auth": { "authorize" : function () {} }, "client" : { "load" : function () {}, "people": { "people" : { "connections" : { "list" : function () { return {"execute" : function () {} }} }, "get" : function () { return {"execute" : function () {}} } } } } } it is not working, can any one help
@niwinz: you realize there’s countless cases like this, at some point you draw an arbitrary line. Also anybody who has been doing ClojureScript long enough realizes how many patches we’ve taken and continue to take to improve user experience. But some things just do not make the cut.
Still I already suggested that enhancing the binding
docstring should probably happen in Clojure first if it’s going to happen at all. However this is all well trodden territory in Clojure and why stuff like bound-fn
exists so I don’t see much movement there. Tweaking docstrings just for ClojureScript without a really strong reason just isn’t going to happen.
And adding a warning about cljs.test/async
telling you not to write a sync test while at the same time using binding
with the wrong expectations just doesn’t make sense.
Is there any widely adopted way to handle Bootstrap modals in Reagent?
@novakboskov: might want to ask on the #C0620C0C8 channel, might get better traction
@davin Thanks
Any idea what's happening here? https://gist.github.com/scttnlsn/ffeb90723823f60c9651f80efb407eae
@bhauman: Do you know that from past experience? Or am I missing something in the stack trace?
so it is a bit of an experience, insider thing, you may have discovered a bug but the most likely thing is that it's circular dependency
@scttnlsn: also sounds like you’re using an older version of CLJS - we don’t use the old topo-sort fn anymore (pretty sure)
How to enable Gzip on http-kit for minified ClojureScript? http://stackoverflow.com/questions/38334893/how-to-enable-gzip-on-http-kit-for-minified-clojurescript
Added knobs to Figwheel config validation,
ie.`:warn-unknown-keys` or simply :ignore-unknown-keys
And a new :validate-interactive
(true, false, :fix, :start, :quit) to control the plugin validation loop behavior
If I simply put :module-type :amd
or :commonjs
for my libs, I got either ERROR: JSC_CONSTANT_REASSIGNED_VALUE_ERROR. constant module$node_modules$leaflet_pip$leaflet_pip_min assigned a value more than once.
and RROR: JSC_ES6_MODULE_LOAD_ERROR. Failed to load module "React" at node_modules/react-autosuggest/dist/standalone/autosuggest.min.js line 1 : 82
for another lib
cljsjs/react
is for ClojureScript use, not for some other JS dep that doesn’t access React
via the global scope
(which is why I asked my question, doesn’t seem related at all to your :module-type
question)
yes if you need to use something that needs to be built with React then no you can’t use cljsjs/react
what is the correct way to include react
? I think include it as foreign-libs
is the same thing as cljsjs/react
does (accessing through global scope)
many people do not bother with any 3rd party React stuff that requires building a custom foreign lib
you want to combine things which require custom builds of whatever react components you want + react
on top of that you will need to supply externs for all the libraries you are going to call into from your ClojureScript code
Any insight on the ERROR: JSC_CONSTANT_REASSIGNED_VALUE_ERROR
? it seems like a closure compiler
erro complains for constant reassignment
if you want to do that then no do not include the cljsjs/react
dependency, just make it part of your build
@blance: I also would not bother with :module-type
for this, just build a single foreign dep using whatever JS build tool you are using
huh it looks like Google Closure Compiler can compile to JavaScript https://github.com/google/closure-compiler/pull/1608
so fully featured bootstrapped thing is probably possible - would need some more investigation
Maybe I’ll dig around in there and see what it involves. Interesting if it implies that you could do whole-program optimization of some sort in bootstrap ClojureScript. (Probably with a decent amount of work.)
Dang. We’ll have to update the bootstrap FAQ that says Closure is not available outside of the JVM 🙂
closure.cljc
might be possible them - with GWT compiled Closure as a foreign lib require
just FYI for React cljs users: https://github.com/yannickcr/eslint-plugin-react/issues/678