(defmacro <>
  ([el content] (<> &form &env el content nil))
  ([el content style] `(~el {:inner-text ~content, :style ~style})))

does shadow-cljs support multiple arity defmacro?

cljs.user=> (ns foo.core$macros)
nil
foo.core$macros=>
foo.core$macros=> (defmacro <>
             #_=>   ([el content] (<> &form &env el content nil))
             #_=>   ([el content style] `(~el {:inner-text ~content, :style ~style})))
true
foo.core$macros=> (foo.core/<> 'a "a" nil)
nil
foo.core$macros=> (foo.core/<> 'a "a")
nil
foo.core$macros=> '(foo.core/<> 'a "a")
(foo.core/<> (quote a) "a")
foo.core$macros=> '(foo.core/<> 'a "a" nil)
(foo.core/<> (quote a) "a" nil)
foo.core$macros=> (macroexpand-1'(foo.core/<> 'a "a" nil))
WARNING: Use of undeclared Var foo.core$macros/macroexpand-1' at line 1
TypeError: Cannot read property 'call' of undefined
foo.core$macros=> (macroexpand-1 '(foo.core/<> 'a "a" nil))
((quote a) {:inner-text "a", :style nil})
foo.core$macros=> (macroexpand-1 '(foo.core/<> 'a "a"))
((quote a) {:inner-text "a", :style nil})

it looks good in Lumo, but throw compilation errors in shadow-cljs

based on https://stackoverflow.com/a/25569059/883571

just guessing https://github.com/clojure/core.specs.alpha/commit/93f655c297f7a4e9d8fa7cd549ec08660130d925#commitcomment-24248628

@jiyinyiyong shadow-cljs is not self-hosted therefore macros need to be written in Clojure

core.specs.alpha does not have anything to do with it

you simply cannot do defmacro in CLJS (only CLJ)

use shadow-cljs clj-repl and do the macro stuff there

core.specs.alpha is for Clojure therefore it does not have :require-macros

by the looks of it you are trying to use CLJS code from CLJ, that won’t work without some reader conditionals

cljc files

yes, in .cljc files

.cljc files can be loaded by CLJS and CLJ but when loading CLJ you can’t use CLJS code so you have to use reader conditionals

I feel confused, none of my files uses .clj as extension name

it's mostly .cljc, with a main.cljs file

so .cljc files are basically .clj and .cljs in one file

if you :require-macros something that will be loaded by CLJ

if that it turn does :require something that will also be loaded by CLJ

and so on

so if the file that was required then tries to :require-macros it fails because CLJ is the one loading it and not CLJS

two separate worlds

...which means in every .cljc file, I can't use :require-macros too?

I think you misunderstand

the answer is it depends

it matters who is loading the .cljc file. the CLJS compiler where :require-macros is fine OR Clojure where it is not fine

my file is compiling with shadow-cljs and running in a browser, I can't see where is the .clj part

if you :require-macros something that is loaded by clojure. everything macro related is clojure.

Sounds like something I didn't even noticed before. The same code was ok, but I saw compilation errors today.

not playing with cljs for weeks... also I haven't updated my dependencies yet

doesn’t have anything to do with dependencies

macros can be a bit confusing by themselves, they are extra confusing in CLJS

I mean, the behaviors of the compiler just changed with the same copy of code. no new commits, not deps updates

I doubt that

maybe you added a :require somewhere?

I don't think so

if you have demo repo somewhere I can take a look

https://github.com/Respo/respo/commits/master

still this repo, you may check the code on Aug

which command produces the error?

yarn watch,

it starts shadow-cljs watch

then I edit code, say in space.cljc, change value from 1 to 2

ah hmm

shadow-cljs attempts to load the file as a macro, not sure why it would

I don't trust my code anymore since I introduced Macros...

I would stay away from .cljc files personally, they just make things a lot more complicated

the macro reloading code in shadow-cljs is probably buggy with .cljc files

maybe I should compile all my code to .cljs since I never really use Clojure(JVM)

keep the macros in .clj files and everything else in .cljs

only use .cljc when absolutely necessary

thats what I do

how to require .clj from .cljs by the way?

you can’t … other than :require-macros. thats the point

I remembered you write a Gist before, or just a script? Do you still have it?

https://gist.github.com/thheller/405951452cf872eb16ba2d4e1fb5a117

https://github.com/thheller/shadow-cljs-examples/tree/master/macros

bascially whenever you need a macro you create a .cljs files and a .clj file of the same name

the .cljs file then :require-macros the .clj files itself

everything else just uses :require never :require-macros

IMHO it is not a good idea to have a respo.macros namespace, puts too much emphasis on the macro part.

I agree. But I don't have enough experience to decide which solution is best for my case. I still have to deal with the edge cases,

well that you are writing your own editor that has to deal with all the edge cases certainly adds a bit of complexity on top 😉

otherwise it is not that complicated

kind of...

I have a polyfill/ folder for bare ClojureScript code anyway.

my current headache is, in the file I write Macros, I need to require code from my ClojureScript code written in .cljs.

yeah, don’t do that. well keep it to an absolute minimum.

previously it's in .cljs, so it's okay. now it's .cljs.

btw do you know other JS build tools than rollup and webpack?

I know there are others but can never remember their names

tried, by barely use them. Webpack is the best.

webpack is horrible if you want to write plugins for it

I used requirejs and browserify before. but switched to Webpack.

also does way too much suff I don’t need

can requirejs bundle code together?

but we need most of the features in Webpack, when we where trying to create single page apps.

I need something for shadow-cljs as a fallback when closure does not work

yeah, requirejs has a command line called r.js, which bundles code. But it's using AMD format, which not as useful as CommonJS, so it's barely used now.

webpack is driving me crazy

building my own is not an option

maybe browserify works, checking it now

heard that browserify is cleaner than Webpack.

why is Webpack so crazy to you?

because I’m trying to do something it is not intended to do

well it sort of can do it if I combine DllPlugin and DllReferencePlugin but that whole setup is just crazy

I never looked into Plugins.. 😨

well if I ignore code splitting everything is easy

do you think asking the maintainers can help?

maybe, don’t know who to talk to or even how to describe what it is I’m trying to do

maybe https://twitter.com/wSokra

it's his fault that Webpack gets so complicated. but people need those features anyway

yeah he’s probably busy with other stuff

I can just wait till Closure supports everything … which will happen eventually (hopefully)

https://medium.com/webpack/the-new-plugin-system-week-22-23-c24e3b22e95

I remembered he is working in Webpack full-time

yeah lots of stuff happening with webpack, getting more complicated with every change

ClojureScript is so complicated.

hehe not to me 🙂

do you know about BuckleScript?

know yes, used it no

the author is a Chinese, so he is active in Chinese tech communities too

BuckleScript has runtime libraries like ClojureScript, but not Macros.

I just feel that he is so happy the performance of compiler beat all other compilers of altjs languages.

and it doesn't run into traps like ClojureScript does, in using with Webpack

well it doesn’t have the Closure Compiler

I personally care very little about the speed of the compiler when my compiled output is a lot smaller and optimized

hmm browserify might work for what I want. seems easier than webpack at least 🙂

I think people don't always care about the bundle size that much, for example some of my apps in my previous work, they are used internally. So the size the not important. My manager just want the websites get online really quickly.

well if you don’t care about the size then using webpack with shadow-cljs should just work fine?

while some of the sites do care about that. They just choose Vue.js and not even React.

yeah, if I can split ClojureScript libraries into another bundle, then it's acceptable in some scenarios.

anyway, the current problem of using ClojureScript in China is just too few people are using it. we would think about size after people start using it.

too few people are using it globally 😉

looks like browserify may actually work 🙂

attempted to write the webpack plugin at least 4 times in the last month and always gave up

should have looked at alternatives earlier 🙂

but I didn't hear you complain about it on Twitter 😅

no point in complaining if the problem is that I don’t understand it 😉

I imagined there might be some chance that Webpack maintainers will help ClojureScript, although it's rare.

well by the looks of it all I need is browserify -r react -r react-dom and then something combined with -x=react

being a user of both tools, I just hope to see ClojureScript works in Webpack, just like TypeScript and BuckleScript. 🙂

probably won’t happen

😅

well works in webpack already but just not via a loader

you are right

the loader part is problematic because clojurescript uses namespaces to organize code

the others just use files

which looks similar but isn’t

not even through compilation?

I expect a whole lot more people using the Closure Compiler soon which should make things easier to use in CLJS as well

GCC just needs a bit more tuning

A lot of people are using React and Vue, which do not like Closure Compiler.

don’t the typescript people already use it?

not heard about TypeScript.

https://github.com/angular/tsickle

not found much voices https://twitter.com/search?q=typescript%20closure%20compiler&src=typd

Tsickle converts TypeScript code into a form acceptable to the Closure Compiler.

that means that its also directly useable by CLJS

while for webpack, there are much more https://twitter.com/search?q=typescript%20webpack&src=typd

yeah, well only because people talk about it more doesn’t mean that it is “better” 😉

more popular~

people in JavaScript world rely on documents heavily. I don't think Closure Compiler team is good at documents

yeah agreed. its mostly used by Google internally so I bet they have internal docs just nothing public

sigh

browserify uglifyify envify … they went a little overboard with the ify

like loaders

and coffeeify

well it does what I need so thats a good thing 🙂

does this file has to be empty?

no you can put any kind of CLJS code in there

but.... code in lib.clj can not access those variables

at compile time no, at runtime yes

any tricks to rescue?

what do you want to do?

my macros are wrapping create-element into div and span functions

so I want to access create-element from macro definitions

uhm but you don’t actually want to CALL the function right?

not, during the time macros are defined,

then its fine

(defmacro meta' [props & children] `(create-element :meta ~props [email protected]))

(defn gen-dom-macro [el]
  `(defmacro ~el [~'props ~'& ~'children]
    `(create-element ~(keyword '~el) ~~'props ~@~'children)))

luckily not called

so whats the issue?

(ns respo.alias (:require [respo.core :as core]) (:require-macros [respo.alias]))

(def create-element core/create-element)

(def create-comp core/create-comp)

now I put my code back in a file called alias.clj, but in alias.clj, I don't get the variables defined in alias.cljs.

the snippet above is alias.cljs

and alias.clj?

oh, there might be a trick

why do you need the alias at all?

in the macro just emit respo.core/create-element instead of create-element

all working now. thanks

requires some trickery but it seems browserify has solved the issue I was trying to solve for the last month using webpack

yay for simple tools 🙂

interesting

is it bundling?

sort of

I needed a way of packages JS together but still being able to require the packages by name

ie. want to bundle react and react-dom together (or separate) and then still use require to access them

together was simple in webpack as well

separate was nearly impossible

well it was hard not impossible

browserify -r react-dom -x react > react.dom.js and done

:thinking_face:

it will make more sense soon 😉

looking forword

but it sounds like Webpack users won't get the benefits

webpack users never needed it

well? :thinking_face:

well if you use webpack you already have something that can provide require("react")

it's by CommonJS, in Webpack

yes

but I wanted a more lightweight way of being able to use require("react") without using webpack

so browserify is the alternative...

well the primary goal is to use the Closure Compiler

but in cases where it doesn’t work (yet) the fallback will be browserify

anyway it sounds good now 😅

so you can still (:require ["react"]) but without webpack

just wish browserify was able to generate some kind of manifest 🙂

like :npm-deps?

I hate :npm-deps .. it is so misleading on what it actually does

I call it :js-provider for now

so if you set :js-provider :closure the (:require ["react"]) will attempt to import the npm react package via the closure compiler

in the old days, we have gulp-rev for browserify https://stackoverflow.com/a/33507199/883571

if you set :js-provider :require it will just emit a require("react") call, which just works for node.js or when using webpack

but then also for the browser by using the browserify fallback

basically :js-provider covers how native JS is “provided” by the system

so no need for cljsjs anymore

sounds like what Webpack does

yes but inverted

now its shadow-cljs, then that code is processed by webpack

then its just shadow-cljs, no additional step

are you adding browserify as a dependency in shadow-cljs?

yes

well maybe

that's 😄

but yes the goal is to only have shadow-cljs running and it managing everything

first plan was using webpack in the background but that was way harder than I wanted it to be

yeah, it's cool. and it makes things a lot easier to learn

cool cool, thanks for suggesting browserify. I got further in the last hour than in the last 4 months trying to understand webpack 😛

glad it helps

oh perfect it even has --list which does what I need 😉

cool

gotta go … but this is exciting … I should finally be able to finish this beast of a branch 🙂

looking forward to updates

also late in Shanghai, going to clean all my tabs before sleep