Fork me on GitHub
#shadow-cljs
<
2018-04-08
>
geraldodev01:04:28

I' ve made a src/shim directory to put cljsjs shim. its annoying it was next to src/cljs

steveb8n01:04:45

I’m having trouble getting a basic om-next app loading in devcards using shadow.

steveb8n01:04:12

I’ve tracked it down to the om/reconciler object not satisfying IReconciler

steveb8n01:04:10

has anyone seen problems like this with om-next or core/satisfies? in shadow compiled code?

steveb8n01:04:03

I also tried (satisfies? IFn identity) and that’s false as well

steveb8n01:04:45

(satisfies? IDeref (atom {})) is true so satisfies? appears to generally work I guess

steveb8n01:04:56

but this fails and blocks om-next from starting

steveb8n01:04:22

`(satisfies? om.next.protocols/IReconciler (om/reconciler {:state (atom {}) :parser (om/parser {:read (fn [& args] nil)})}))`

steveb8n01:04:05

@stathissideris I’m just getting started with shadow but reloading and error msgs are looking great with shadow vs figwheel. devcards as well

alex-dixon04:04:41

Anyone know how I might be able to solve reloading js files? https://github.com/thheller/shadow-cljs/issues/240

thheller08:04:47

@alex-dixon my bad. the recent compile performance optimization I did for JS broke the reloading part

thheller08:04:55

will fix it after breakfast

fj.abanses13:04:11

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)

alex-dixon15:04:26

@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

thheller16:04:47

@fj.abanses core.async is not self-host compatible and cannot be compiled by :bootstrap

thheller16:04:11

@alex-dixon the reload issue is easy to fix but I went down this rabbit hole trying to make commonjs/es6 compatible again

thheller16:04:19

didn't get anywhere again

thheller16:04:30

will release the reload fix later

thheller16:04:37

grabbing some food first

alex-dixon16:04:11

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?

thheller16:04:45

well might as well push it now. 2.2.26 should at least reload properly.

thheller16:04:00

can talk later .. gotta go

stathissideris16:04:37

@steveb8n thanks!

fj.abanses17:04:24

@thheller of course!! thanks. i just remembered... i am gonna use mfikes andare instead

rgm19:04:39

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).

rgm19:04:17

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.

rgm19:04:34

oh, nvm. Was executing the wrong file.

rgm19:04:34

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

rgm19:04:52

looks like the :compiler-options governs if they're both present

thheller19:04:06

@rgm inside :compiler-options is the correct place yes but as a convenience its allowed in the build also

rgm19:04:52

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.

rgm19:04:12

man, so many knobs to twiddle 😬

thheller19:04:30

I would suggest just using 2 different entry namespaces

thheller19:04:40

your.project.browser and your.project.electron

thheller19:04:57

so you can do all the setup needed in those and re-use parts that make sense

rgm19:04:38

hm, ok... seems reasonable. It's 99% duped at this point but when it inevitably diverges that'll make sense

rgm19:04:03

right now the entire rationale is providing offline use of an (effectively) read-only app.

rgm19:04:18

(it's a little calculator for building construction and weirdly, job sites often have terrible network coverage).

thheller19:04:32

@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.

thheller19:04:43

so import React from "react"

thheller19:04:11

unfortunately webpack is not as strict and also allows direct refer

thheller19:04:27

import React, { createElement } from "react" works in webpack but not in closure

thheller19:04:48

so I either make refers work or the default export

thheller19:04:09

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 ...

thheller19:04:12

super annoying

thheller19:04:10

worst part is that I can't find any official documentation how all this works in webpack

thheller19:04:20

problem is that people expect things to work just like webpack

thheller19:04:25

but closure doesn't ...

thheller19:04:47

unfortunately closure doesn't work like that at all

thheller19:04:30

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

thheller19:04:52

trying to find a reasonable solution for this has been pretty annoying

alex-dixon20:04:10

I thought module.exports.foo = foo <-> export foo <-> module.exports = {foo: foo}

alex-dixon20:04:16

const {foo} = require(“./foo”) <-> import {foo} from ‘./foo’

thheller20:04:48

closure will rewrite a file foo/bar.js with module.exports.foo to module$foo$bar.default.foo

thheller20:04:15

but import {foo} from ‘/foo/bar’ would would try to access module$foo$bar.foo

thheller20:04:38

the reasoning is that import/export in ES6 are live references which can be updated

thheller20:04:47

in commonjs they are not

alex-dixon20:04:48

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

thheller20:04:19

I mean if you var x = require("foo") with module.exports.foo = 1

thheller20:04:30

if the module does module.exports.foo = 2

thheller20:04:34

your x will still be 1

thheller20:04:54

in ES6 it will be 2 with export let foo = 1 and later updating that foo

thheller20:04:35

yes require is dynamic and import is static

thheller20:04:44

but thats something different

alex-dixon20:04:37

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

thheller20:04:03

closure works perfectly fine when all your code is ES6

thheller20:04:19

FWIW node still hasn't defined how they are going to do the ES6->CJS interop

alex-dixon20:04:36

> import React, { createElement } from "react" works in webpack but not in closure

thheller20:04:38

webpack just did something that sort of works but is hacky is hell

alex-dixon20:04:53

Well yeah but I mean…that’s considered standard where I come from at least

thheller20:04:53

and totally destroys any possibility of DCE ever working

thheller20:04:43

again .. ES6 only ... doesn't work with commonjs

thheller20:04:35

the tree shaking webpack pretends to do is childs play in comparison to what closure is doing

thheller20:04:54

BUT closure has to be more restrictive in what it can support because of this

thheller20:04:59

so its just tradeoffs

thheller20:04:30

again ... I could completely drop Closure for this and just use babel then it could work more of less like webpack

alex-dixon20:04:45

Was going to ask about that

thheller20:04:47

but my ambition was to use closure because of the benefits we get from that

thheller20:04:00

and for the most part it works reasonably well ..

thheller20:04:12

its just the commonjs (ie. npm) interop that is icky since their recent change

thheller20:04:35

I was going to open an issue about this to get their feedback

thheller20:04:50

they don't seem to concerned with importing arbitrary commonjs code

alex-dixon20:04:51

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?

thheller20:04:58

it all works perfectly fine when just using ES6

thheller20:04:21

closure will never be optional for clojurescript. at least not in any tool I'm writing.

thheller20:04:32

BUT it can be optional for the JS processing

thheller20:04:11

clojurescript just gains too much by using closure

thheller20:04:37

but the JS world survives fine without it so we can too probably for the JS bits

alex-dixon20:04:47

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?

thheller20:04:55

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.

thheller20:04:24

the local js stuff is where it gets tricky and ONLY because of my ambition of trying to make :advanced work for it

thheller20:04:49

so yeah blame me for that ... not closure

alex-dixon20:04:52

Exactly. Is it really worth the effot?

thheller20:04:10

closure is only concerned about ES6 interop with Closure JS

thheller20:04:22

they never said that npm integration is supposed to work

alex-dixon20:04:25

I’ve been witnessing magic this weekend just going through your examples and making that babel one. It’s ridiculous any of this works

thheller20:04:44

I'm just a little bit tired of people blaming the Closure Compiler for our issues when its not really their fault

thheller20:04:15

I'll probably rewrite the local JS interop stuff and just use babel for it like I currently do with ES6 on npm

thheller20:04:26

then everything should just work and be totally fine

thheller20:04:31

its a weird problem to solve since there is no clear "standard" an how any of this is supposed to work

thheller20:04:50

webpack did something, babel does something else. still need to check out what parcel does.

thheller20:04:03

I'm sure its different as well...

thheller20:04:02

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

alex-dixon20:04:04

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

thheller20:04:43

yeah. would be nice if webpack documented their plans better so others could follow

alex-dixon20:04:10

What are your thoughts on shadow-cljs and being able to do things that webpack does like require images, fonts and css?

thheller20:04:53

doing it via require is an absolutely disgusting solution. I will never do that.

thheller20:04:11

I however have plans for a macro based solution

thheller20:04:18

or maybe ns metadata

thheller20:04:02

(ns my.app {:css/include ["./foo.css"]} ...) or something along those lines

alex-dixon20:04:04

Ok. I was half-expecting you to say it’s beyond the scope of the project and that’s what webpack is for

thheller20:04:30

hell no. I totally want this.

thheller20:04:54

we just can do better than require("foo.css") ... thats just horrible

thheller20:04:30

I do have a solution for scss in my work project

thheller20:04:43

just didn't extract it properly for shadow-cljs yet

alex-dixon20:04:22

Would you want the babel example? Can make a PR

thheller20:04:16

I kinda want to get away from undocumented examples. want examples with proper explanations whats going on.

thheller20:04:29

writing those however is pretty time consuming and I didn't find the time yet

alex-dixon20:04:42

Any other examples you might like to have? Was thinking of adding reagent to the babel one to show interop with it

alex-dixon20:04:08

Was also thinking one with deps.edn

thheller20:04:18

if you don't mind writing a bit of readme to explain the involved parts 🙂

thheller21:04:15

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

thheller21:04:28

easier to clone/copy that way

alex-dixon21:04:41

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

thheller21:04:16

its a wonder any of those still work really. haven't updated many of them in a while

thheller21:04:54

I like issues. things discussed here get lost too easily. gh issues at least sort of stay online.