This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-08
Channels
- # beginners (92)
- # boot (2)
- # cljsrn (6)
- # clojure (33)
- # clojure-austin (1)
- # clojure-dev (18)
- # clojure-spec (7)
- # clojure-uk (2)
- # clojurescript (35)
- # cursive (13)
- # data-science (3)
- # datomic (1)
- # defnpodcast (1)
- # figwheel (1)
- # fulcro (27)
- # instaparse (1)
- # java (2)
- # leiningen (8)
- # off-topic (5)
- # onyx (1)
- # portkey (2)
- # re-frame (9)
- # reagent (2)
- # ring-swagger (1)
- # shadow-cljs (136)
- # test-check (3)
- # tools-deps (29)
I' ve made a src/shim directory to put cljsjs shim. its annoying it was next to src/cljs
has anyone seen problems like this with om-next or core/satisfies? in shadow compiled code?
(satisfies? IDeref (atom {})) is true so satisfies? appears to generally work I guess
`(satisfies? om.next.protocols/IReconciler (om/reconciler {:state (atom {}) :parser (om/parser {:read (fn [& args] nil)})}))`
@stathissideris I’m just getting started with shadow but reloading and error msgs are looking great with shadow vs figwheel. devcards as well
Anyone know how I might be able to solve reloading js files? https://github.com/thheller/shadow-cljs/issues/240
@alex-dixon my bad. the recent compile performance optimization I did for JS broke the reloading part
Hii, I am on shadow-cljs: ^2.2.21
and when attempting to include core.async in a build with target :bootstrap
I get the following error... The required namespace "java.util.concurrent.locks.Lock" is not available, it was required by "cljs/core/async/impl/ioc_macros$macros.cljc"
.
edn deps has [org.clojure/core.async "0.4.474"]
has anyone come across this? Cheers!
(edit: code format)
@thheller Np at all. Anything I can do to help? Wanted to start on it but didn’t because I thought it might be too deep an issue for a first time contributor
@fj.abanses core.async
is not self-host compatible and cannot be compiled by :bootstrap
@alex-dixon the reload issue is easy to fix but I went down this rabbit hole trying to make commonjs/es6 compatible again
I’m not sure if this is an appropriate reaction but…what the heck is up with closure’s decision to not conform to the es6 modules spec and sort of invent their own version of it?
@steveb8n thanks!
is something like :closure-defines
available in shadow-cljs? The problem I'm working on is that I want one target for electron and one target for the browser. It's re-frame, so I'd like to be able to branch on that at compile time and use that to choose whether data gets loaded from filesystem (electron) or the web (browser).
I tried using :closure-defines
in a :compiler-options
map and just at the top-level of the build, and it didn't seem to take.
for the record it seems to work at both levels: at the top level of the build map, and down in a :compiler-options
map
@rgm inside :compiler-options
is the correct place yes but as a convenience its allowed in the build also
it occurred to me that I could also branch my event behaviour by altering the main start-up call in my index.html
... eg <script>my.project.system.go("electron")</script>
but it seems less screwable-aroundable-with in prod if I just lock it in at build time.
hm, ok... seems reasonable. It's 99% duped at this point but when it inevitably diverges that'll make sense
right now the entire rationale is providing offline use of an (effectively) read-only app.
(it's a little calculator for building construction and weirdly, job sites often have terrible network coverage).
@alex-dixon Closure is totally compliant with the ES6 spec. the problem is that the spec doesn't define how interop with commonjs should work and this is how we get into trouble. most of the code on npm is commonjs (eg. react) which don't have a "default" export. so their decision was that commonjs should ONLY have a default export and you access everything through that.
neither option is perfect and I still need to figure out how to deal with this ... on top of that there is clojurescript where things work differently once more since it does not have a way to address ES6 default exports ... or rather that it is conflicting with that :as
does ...
worst part is that I can't find any official documentation how all this works in webpack
https://github.com/webpack/webpack/tree/master/examples/harmony-interop this is closest thing to a "spec" i found for this stuff
I could drop closure entirely for this part but it would be neat if we could use closure for this to get the full DCE experience
I thought module.exports.foo = foo <-> export foo <-> module.exports = {foo: foo}
const {foo} = require(“./foo”) <-> import {foo} from ‘./foo’
closure will rewrite a file foo/bar.js
with module.exports.foo
to module$foo$bar.default.foo
Isn’t it the other way? require is dynamic, import is not. Unless you’re taking about import() which is a proposal that would be for dynamic import
very excellent description about the low level stuff https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/
Sounds like there’s some of that I don’t appreciate. To me just seems like closure is doing something a 3rd different way. Or 13th different way
> import React, { createElement } from "react"
works in webpack but not in closure
Well yeah but I mean…that’s considered standard where I come from at least
the tree shaking webpack pretends to do is childs play in comparison to what closure is doing
Right
again ... I could completely drop Closure for this and just use babel then it could work more of less like webpack
Was going to ask about that
Yeah. And I figured what the hell…if that’s my only complaint it’s not a valid one. But still, what if Closure was optional for Clojurescript at least?
closure will never be optional for clojurescript. at least not in any tool I'm writing.
What does it gain? Runtime perf? It seems like shipping with advanced optionmizations is next to impossible if you want to use things from the JS ecosystem and makes debugging impossible. And for what? 100 ms faster initial load on mobile?
I think npm integration is pretty much a solved problem in shadow-cljs. it just works and I don't have to worry about anything.
the local js stuff is where it gets tricky and ONLY because of my ambition of trying to make :advanced
work for it
Exactly. Is it really worth the effot?
No lol
I’ve been witnessing magic this weekend just going through your examples and making that babel one. It’s ridiculous any of this works
I'm just a little bit tired of people blaming the Closure Compiler for our issues when its not really their fault
I'll probably rewrite the local JS interop stuff and just use babel for it like I currently do with ES6 on npm
its a weird problem to solve since there is no clear "standard" an how any of this is supposed to work
webpack did something, babel does something else. still need to check out what parcel does.
I'm sure things will settle down in closure as well .. they just did a complete rewrite of all of thise in the march release and then again in the april release
Well. Thanks for hearing me out. For the record I think the problem is JS, not Closure. I’m realizing webpack-enabled JS has become standard JS to me and a lot of people
What are your thoughts on shadow-cljs and being able to do things that webpack does like require images, fonts and css?
Ok. I was half-expecting you to say it’s beyond the scope of the project and that’s what webpack is for
Would you want the babel example? Can make a PR
I kinda want to get away from undocumented examples. want examples with proper explanations whats going on.
Any other examples you might like to have? Was thinking of adding reagent to the babel one to show interop with it
Was also thinking one with deps.edn
kinda prefer standalone repos as well ... I started collecting links to guides/examples/templates in the main readme https://github.com/thheller/shadow-cljs/blob/master/README.md#examples
Sorry…just opened a bunch of issues with some things that have been on my mind. I liked the examples repo because I could just clone it and then run a bunch of different ones