In Brave, I see a warning now regarding SharedArrayBuffer
and it looks like it originates from something like shadow$provide.module$node_modules$scheduler$cjs$scheduler_development
.
Is this a known issue that an update will address? Or not yet?
(it's just a deprecation warning from the browser)
@pmooser that is a library you are using, or rather that react is using. I have no control over that and shadow-cljs is not involved in that.
you can check the repo if there is an issue about it. there probably is.
Ok, sorry about that. I didn't realize!
is there a way to get custom formatters and/or a CLJS REPL in Chrome devtools when using shadow-cljs?
@thheller can you confirm this?
no. dirac does not work. or it didn't use to work, it has been a while since I looked.
okay thanks 🙂
custom formatters you can just use cljs-devtools. a REPL no.
Maybe not exactly what you want, but if you want to make your Chrome devtools more CLJS friendly you might check out Dirac: https://github.com/binaryage/dirac
I haven't personally used it (honestly, I've just been too lazy to set it up), but I've heard a lot of praise for it in the community
Does Dirac work with shadow-cljs?
alright, thanks
It should work with any Clojurescript code running in a browser. Shadow-cljs is just a build system.
i'm seeing some strange compiler output
(defn js-i18n [format-string-string & args]
(js* "ttag/t`~{}`" format-string-string)
(apply ttag/t (-> format-string-string chomp-format-string into-array) args))
i'm playing around with emitting a tagged format literal in js for our i18n. And strangely, this is emitting
(metabase.shared.util.i18n.js_i18n.cljs$core$IFn$_invoke$arity$variadic = (function (format_string_string,args){
ttag/t`format_string_string`;
return cljs.core.apply.cljs$core$IFn$_invoke$arity$3(shadow.js.shim.module$ttag.t,cljs.core.into_array.cljs$core$IFn$_invoke$arity$1(metabase.shared.util.i18n.chomp_format_string(format_string_string)),args);
}));
which is including the name of the var, not its contents: ttag/t'format_string_string'
(had to use apostrophes instead of backticks here).
however, evaluating (js* "1 + ~{}" x)
at a repl where x is (def x 3)
correctly yeilds 4. So it seems to resolve at runtime in a repl but under advanced compilation uses the local nameI don't understand. that is producing exactly the code it is supposed to?
this (js* "1 + ~{}" x)
ends up as 1 + x
in the code so of course that is valid?
unless I'm missing something?
oh i see. i was thinking it would end up as 1 + 3
instead of 1 + x
with that being a valid local
and now i realized i had thought myself into a silly place 🙂
yeah the string literals are difficult to emulate
i'm fighting against an i18n library that has a plugin to enumerate all strings for translation that looks for tagged template literals. and i'm working on how i can get some cljs code to play nice with that
macro is the only way I'm afraid
that would use the js*
special form? or does that strike you as the wrong approach?
it would need to use that since the compiler otherwise isn't currently able to emit those
awesome. thanks for your help and sorry for the wall of text for a really dumb question 🙂
I mean support could be added via magic but that is a rather advanced task 😛
yeah. and since they are callable as functions its not a big hindrance. just a bummer that their plugin to find them looks over the ast for tagged literals in particular
@dpsutton https://github.com/thheller/shadow-cljs/commit/e043d5be60877bd1d367080a9a41fc9d12364b91 😉
need to finish up some more testing with new CLJS version and then that'll be in the next release
that's close but if its possible to put a tag on front that would be nice
(js/ttag.t (js-template "foo"))
?
i don't think so. that would call
t(`foo`)
//distinct from
t`foo
`it is?
don't think so?
I've never actually used them anywhere so I might be totally wrong 😛
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates
myTag`That ${ person } is a ${ age }.`;
is equivalent to
myTag(["That ", " is a "], person, age)
oh right doh
yeah its confusing at first but then just totally makes sense mechanically. it's just chopped up
hmm wonder if that should be (js-template foo "bar")
or (js-tagged-template foo "bar")
as in a separate form or just handled by being smart and checking the first argument 😛
https://github.com/thheller/shadow-cljs/commit/109ea8858b5180522895b1d32c17e47d8cfff90e
dunno if this is actually useful but it has been bugging me that this wasn't supported for a while 😛
probably full of bugs still, pretty sure the escape logic is too naive but who knows 😉
yeah that looks closer. feels weird to emit without munging. i think you could define your own functions in cljs so it should probably be munged
what do you mean? it is munging?
(js-template (function-that-is-called-with-template-arg) "foo")
is
function_that_is_called_with_template_arg()`foo
`which is valid as far as I know?
tried it in the console and seemed to work 😉
it isn't taking the literal symbol and just dumps it there. it is actually analyzing that symbol
so (js-template js/ttag.t "foo")
would be
ttag.t`foo
`I mean for your stuff you likely still need a macro either way if you just want to emit that as a side effect so the parser can find it?
(js-template alias/foo "foo")
would be
whatever.alias.was.foo`foo
`actually that does all it needs to. if it emits the correct thing its golden
it needs to parse the compiled output to compile a list of strings needing translations
yeah but depends on what it is looking for I guess. dunno if it understands the aliasing shadow-cljs does for modules and stuff
yeah i was looking at that. i think that would be another problem to solve but it felt more approachable. was wondering what your shim was and how wrapped over the underlying lib it was
you appear to be using :npm-module
so if you have (:require ["ttag" :refer (t)])
and (js-template t "foo")
what would give you
shadow.js.shim.module$ttag = require("ttag");
shadow.js.shim.module$ttag.t`foo
`dunno how smart your parser is at detecing that 😉
the shim is just a placeholder variable basically for the require result
it won't be that after advanced
hmm what language level is this even?
yeah i don't think it picked that up. i had to (js* "ttag/t~{})
to get it to work
yeah i was hoping i could throw an export on it and have it stable
and under advanced compilation it was still super readable so dunno
what language level? es6, etc?
yeah which spec level
ah yeah :es6 seems to be ok
closure was rewriting it with :es5
oh annoying
thinking about it a macro may actually be enough with a bit of js*
, doesn't need to do all I'm doing now
I'll see about it tomorrow when I can actually think, way too late now 🙂
well thanks for being the sounding board
I pushed 2.12.0
(minor bump because of new cljs version) which also has the (js-template ...)
if you want to try that
i'm on 2.12.0: shadow-cljs - server version: 2.12.0 running at <http://localhost:9630>
, and (js-template ttag/t "hello")
is giving me an error about an undeclared var js-template
oh you need to require it. I made it available as a library
(special-symbol? js-template)
is returning false which surprises me
ahh
(:require [shadow.cljs.modern :refer (js-template)])
getting an error with (js-template ttag/t "hello")
and similarly with just a base test: (js-template "hello")
: cannot read property call of undefined
nevermind, must have been some funky repl state. re-evaled the ns with the require and it is now working
I expect there to be bugs with this. I didn't test is very much and the implementation is definitely kinda rushed in a late night sleepy state 🙂
once this has been tested a little more we can maybe make a patch for CLJS out of it
one thing to think about, is that tagged template literals, and template literals in general, make the most sense when they can have the interpolated values. i tried a simple (js-template "hello ${\"there\"}")
and it emitted t'hello \$"there"' which was almost workable. not sure how to handle this. off the cuff might be (js-template "hello " x)
might emit t'hello ${x}'
but i doubt that might be worth the trouble and sounds like a super uphill battle going into cljs
well the whole point was making this act like str
but emit a template string
(js-template "hello " x)
will emit exactly
`hello ${x}`
ah sorry i thought i tried that and it didn't do what i wanted
(js-template "hello ${\"there\"}")
is therefore pointless and will be escaped 😛
totally
(js-template "hello " (any-cljs "expr"))
is totally valid, if it was using ${}
then you'd run into all sorts of annoying quoting issues
a difficult part for this particular implementation is that the translation library expects "your {x} works perfectly"
and will expect the translated phrase to be "your {placeholder} works perfectly" and i can't recreate that in this guise
(js-template "your " x " works pefectly")
would emit the "works pefectly" as part of the substitution rather than the base phrase
again, certainly a quirk in this implementation but kinda the point of the templates i think
did you check what the code actually emits?
no i haven't. let me go check
it may just be the CLJS compiler emitting the usual extra ()
which I can't do anything about unfortunately
I mean that should emit
`your ${x} works perfectly`
but might be
`your ${(x)} works perfectly`
or whatever x
resolves to in this case. could also by some.other.ns.x
(let [x "soundcard"]
(js-template "your " x " works pefectly"))
var x_46339 = "soundcard";
(metabase.shared.util.i18n.js_template.cljs$core$IFn$_invoke$arity$3 ? metabase.shared.util.i18n.js_template.cljs$core$IFn$_invoke$arity$3("your ",x_46339," works pefectly") : metabase.shared.util.i18n.js_template.call(null,"your ",x_46339," works pefectly"));
that is definitely not the correct output. this is not using the special form at all
ah, i removed the import. apologies
and got confused because my repl still had it 🙂
var x_48110 = "soundcard";
`your ${x_48110} works pefectly`;
well i'll be damned
well excellent job in your late night haze
thats more like it 😉
and the plan would be to move that into cljs proper as a special form with those methods for analyzing and emitting?
re-added my sponsorship now that i'm finally using shadow at a work project
well it definitely needs more discussion and testing before this can be submitted to CLJS proper
still not sure if the special form is actually needed for this. a macro might do the trick just fine with js*
this just felt cleaner
and its amazing how responsive you are. truly