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?

custom formatters you can just use cljs-devtools. a REPL no.

alright, thanks

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

(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);
}));

I 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 }.`;

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

and its amazing how responsive you are. truly