@darwin: is it possible to makes oops.core/ ocall oget oset! gcall to become no-ops (so it can compile in cljc files); or does this make no sense, because oops.core should never be used in a cljc file?

@qqq seems like a case for reader conditionals?

@qqq I think, nothing is stopping you to wrap oops.core api with your own macros (unless you want to do this for a library code you don’t have control over)

lu=>> lumo
Lumo 1.5.0
ClojureScript 1.9.542
Node.js v7.10.0
 Docs: (doc function-name-here)
       (find-doc "part-of-name-here")
 Source: (source function-name-here)
 Exit: Control+D or :cljs/quit or exit

cljs.user=>
cljs.user=> (defmacro my-if [p t f]
       #_=>   `(if ~p ~t ~f))
#'cljs.user/my-if
cljs.user=> (my-if true 3 2)
(if 2 nil nil)
cljs.user=>

boot.user=> (defmacro my-if [p t f]
       #_=>   `(if ~p ~t ~f))
#'boot.user/my-if
boot.user=>

boot.user=> (my-if true 3 2)
3

@jiyinyiyong macros don’t work the same way in ClojureScript as they work in Clojure. They need to be declared in a different compilation step

http://blog.fikesfarm.com/posts/2015-09-07-messing-with-macros-at-the-repl.html

Is that mean another file?

I saw that post but never really understand it

not “another file” if you’re at the REPL

but another namespace

thanks, I got it working now, in file. but still see problem in repl:

cljs.user=> (require-macros '[a.b :refer [my-if]])
No such macros namespace: a.b, could not locate a/b.clj or a/b.cljc
	 (new)
	 Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:1937:200)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2484:92)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (NO_SOURCE_FILE <embedded>:2483:92)
	 (NO_SOURCE_FILE <embedded>:5239:92)
	 Object.lumo.repl.load_other (NO_SOURCE_FILE <embedded>:6123:380)
	 lumo.repl.load (NO_SOURCE_FILE <embedded>:6127:106)
	 Function.cljs.js.require.cljs$core$IFn$_invoke$arity$5 (NO_SOURCE_FILE <embedded>:5229:528)
	 Object.cljs.js.load_macros (NO_SOURCE_FILE <embedded>:5270:223)
	 (NO_SOURCE_FILE <embedded>:5287:405)

how does EPL interact with cljs ? if I take a repo that is under EPL, copy it over into my codebase, and modify the code -- do now I suddenly have to release all my .cljs file because I served the compiled .js output?

I thought I already create namespace with (ns a.b).

@jiyinyiyong so if it’s loaded you don’t need to require it

just call your macro with a.b/...

require will try to load files, and that namespace clearly doesn’t exist in a file

cljs.user=> (ns a.b)
nil
a.b=> (defmacro my-if [p t f] `(if ~p ~t ~f))
#'a.b/my-if
a.b=> (ns cljs.user)
nil
cljs.user=> (a.b/my-if true 2 3)
(if 3 nil nil)
cljs.user=> (require-macros '[a.b :refer [my-if]])
No such macros namespace: a.b, could not locate a/b.clj or a/b.cljc
	 (new)
	 Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:1937:200)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (NO_SOURCE_FILE <embedded>:2484:92)
	 Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (NO_SOURCE_FILE <embedded>:2483:92)
	 (NO_SOURCE_FILE <embedded>:5239:92)
	 Object.lumo.repl.load_other (NO_SOURCE_FILE <embedded>:6123:380)
	 lumo.repl.load (NO_SOURCE_FILE <embedded>:6127:106)
	 Function.cljs.js.require.cljs$core$IFn$_invoke$arity$5 (NO_SOURCE_FILE <embedded>:5229:528)
	 Object.cljs.js.load_macros (NO_SOURCE_FILE <embedded>:5270:223)
	 (NO_SOURCE_FILE <embedded>:5287:405)

what's the right way to use macros in a repl?

@jiyinyiyong sorry did you read what I pasted? http://blog.fikesfarm.com/posts/2015-09-07-messing-with-macros-at-the-repl.html

the bit you’re missing is (ns a.b$macros)

glanced and missed that part

get it working now, thanks

in dealing with cljs callback hell, is it better to (1) push everything into cljs core async, or (2) just ues whatever is easiest, and mix callback-hell with core async ?

@thheller @pesterhazy @john This is what I came up with so far. Not quite sure where to next. https://www.contentreich.de/webpack-meets-the-jvm

@deas interesting .. but I’m still not convinced running webpack in the JVM is useful. why not just call node? Unless you want to port npm and everything else as well?

I was going to make the same comment as @thheller

shelling out to node should be more straightforward, no?

@pesterhazy @thheller Depends on the amount and type of interop. Not sure shelling out makes sense for frequent incremental recompilation, hot reloading and things along those lines.

Other than that, I think pulling it in as a dep is pretty convenient.

shelling out is almost instant with node

I’d rather just yarn add --dev webpack since I’m going to install all other packages that way

https://gist.github.com/thheller/9ea396698520cf7448b3f7bcff4b7df6

I have written entire webpack configs in CLJS though

but converting to JS objs makes that a bit annoying

probably easier to directly call webpack

@deas, using webpack separately is pretty straightfoward, see https://github.com/pesterhazy/double-bundle

shadow-cljs can also emit in webpack compatible style

so you only use webpack to bundle things together

but if you are CLJS first that doesn’t make sense

only useful if you have lots of JS and just want to introduce some CLJS without giving up your entire toolchain

I mean you usually don't have to recompile the js bundle anyway during development unless you change the config

right?

in the typical "double bundle" scenario

yes, double bundle is good. only issue I have with that is that code splitting gets annoying

@theller I am not saying you are on the wrong track. I think the process boundary comes with restrictions which just don't need to be there.

Family calling, got to go for now...

might be better to just all out replace webpack, it isn’t that great to begin with

what's better? rollup? browserify? rolling your own?

closure compiler …

🙂

just need to wait until it supports “more” of that JS mess 😉

agree, that'd be great

but honestly in the meantime, webpack works well

well enough … the code it produces is shit compared to the closure compiler

https://clojurescript.org/guides/javascript-modules the babel transforms section seems promising

first run everything through babel then closure

doesn’t have to be nashorn, could just shell out to node

maybe someday .. for now webpack just works

I think webpack is about more than cljs and js. I think things like hot reloading and css, scss also matter a lot.

agreed

but I don’t want to sacrifice production quality for a little nicer development experience

but webpack does well enough for most things .. just spoiled by closure

is Clojure reader and ClojureScript reader compatible?

I was thinking about a tool (linter) to find all namespaced keywords in the source and check if there was somewhere called (s/def) for everyone of them. This way we check if some keyword was misspelled or has no spec for it.

for linting you might want to look into joker

it already does a good job with cljs source files and is pretty fast

@darnok https://github.com/clojure/tools.reader is used by CLJS to read all CLJS code, can also read all Clojure.

I've got a clojurescript project that exposes globals on the window, and a separate clojurescript project that pulls those globals off the window and calls them

I'm using this as a way to facilitate communication between A and B

(b is just an "addon" that we want to be optional)

Project A exposes a function I'll call "foo" that expects a clojure map

We're logging out the clojure map

* worth noting that Project A calls the functions directly, it doesn't call it via the exposed global

Project B can't call it directly, so it has to use the exposed global

When we log out values provided to foo from project A, they're formatted correctly via devtools - but when we log out values provided to foo from project B, this is the result:

https://puu.sh/wi8q0/fe11754156.png

(the first log message is from A, the 2nd is from B)

i thought this might be because we aren't doing clj->js in B when we call global.foo, and aren't doing js->clj in A when the function executes

but that doesn't seem to be the culprit

@samueldev that isn’t a good idea to do in the first place since both A and B will contain their own separate implementation of cljs.core adding a good 20KB+ (gzip’d) to each. same for every other namespace they “share”

a better approach would use :modules

also since closure may optimize each build differently they final variable/property names will be different

in general it is not safe to share instances from one build with another

gotcha

that makes sense

or serialize it to EDN/Transit and read it on the other side

that would be safe but much slower than passing the actual instance

our requirements are to be able to load A, and optionally B, via separate script tags

sounds like :modules, they allow you to code split into many smaller chunks that you can load on-demand

the other reason that we exposed these via globals @thheller is that B is basically an "addon" of A - where A has a strict definition of what an addon can be

this is because we are going to allow our customer(s) to build their own addons

which may or may not be in clojurescript

so they need to be able to hook into the "ecosystem" of A via an addon they've written in plain-js

or TS, etc etc

then you’d need to make a formal API and ensure that it doesn’t get renamed/removed by closure (via :externs)

but making the CLJS collections part of that API wouldn’t be safe

right

unless you also extern those

CLJS really isn’t all that well suited for things like that due to the closure compiler

haha yup

which wants to optimize your whole program at once not part of it

@thheller so is it basically that the separate instances of clojurescript

which, youre right, exist needlessly

are producing clojure-maps-in-the-form-of-js-objs that are incompatible with one another?

yep, exactly

okay thanks for aiding in our understanding

closure renames all properties so it may rename something important to cA in one but aX in another

mhm

the good news for us is that this "addon" system is a requirement we're meeting for our JS customers... so they won't be using clojurescript to write addon modules

so this isn't necessarily a hurdle our customers will face (unless they choose to build modules in cljs, I guess 😉 ) - just one that we're facing internally now

for everything you build you can use :modules

but if you build a JS API anyways a CLJS plugin could just use that? Just don’t pass CLJS objects between API boundaries

yup that's what we're switching to now

everything clj->js when talking from B<->A or A<->B

and each side js->clj respectively on the way in

none of our data structures will cause problems, its all very simple maps with strings, numbers, arrays

but remember that each CLJS plugin will come with a big size overhead due to including cljs.core

yup, we're ok with that in this scenario. basically this is an SDK

and an SDK addon

the outputted size of the UI project that consumes our SDK is monolithic

and no one has complained yet about size haha (gzip is good and our customers are all desktop PCs with good connections, etc)

plus the addons our customers are going to build are going to be plain js

@samueldev here is the devtools code responsible for determining whether a given value should be rendered using clojurescript formatter: https://github.com/binaryage/cljs-devtools/blob/d3af0f855d94d0a2b906b1840b5c7534cedbb768/src/lib/devtools/formatters/helpers.cljs#L51

.cljs$lang$type is likely missing on your project B values

didn’t you compile them in :whitespace or :advanced mode?

yep, this makes perfect sense now that I see the code @darwin

:advanced yeah

yep, there are two issues in your case: 1) https://github.com/binaryage/cljs-devtools/blob/master/docs/faq.md#why-custom-formatters-do-not-work-for-advanced-builds 2) even if #1 got fixed, as @thheller already pointed out, using devtools compiled as part of a different build is unlikely to work (due to different renaming of cljs$lang$type for example

you would have to have two devtools, one built with project A, another one with project B, and be careful which to use where

one thing that may actually work are the closure variable/property maps

closure can output maps that keep references from old name -> new name

it can also import those and will use the same name on the next compile

I use that to get better caching results when rebuilding with :modules

could also use it to ensure that one build uses the same name as another I guess

but I’d stick with the safer JS option