Guys, hello! I got a little problem with cljs. I have a local/root dependency in my deps.edn. It works without any problems with shadow-clj, When I add the same dependency to deps.edn in figwheel project it crashes with the following stacktrace: https://paste.ofcode.org/3aTVdbtMzV3A6MC2vUdxcQ6 Does anyone have some ideas?

I want to write a test around flush-on-newline for SCI. First I want to make sure the behavior of the test works in CLJS itself:

(let [count-atm (atom 0)]
         (with-redefs [cljs.core/flush #(swap! count-atm inc)]
           (binding [*flush-on-newline* true]
             (prn) (prn)) #_(sci/eval-string (pr-str '(binding [*flush-on-newline* true]
                                       (prn) (prn)))))
         (prn @count-atm))

Simple repro:

cljs.user=> (with-redefs [flush nil] (prn))

nil

cljs.user=> (source flush)
(defn flush [] ;stub
  nil)

yeah flush is not a thing I thought

you have to see how it's done internally

this is a no-op?

https://github.com/clojure/clojurescript/blob/29363bbd1d34bb2aeb7b4d762ee4f4ba2f173ddf/src/main/cljs/cljs/core.cljs#L10383

yes - but maybe not intentionally

-flush is a thing

does *flush-on-newline* make sense in CLJS at all?

yes

you have to poke around - the big picture is already there

the protocol for writers, but it seems flush doesn't wrap -flush

because it's implementation specific

the only place I see it's being used in is newline where it appears to be a no-op.

look around for calls to -flush as I said

printing is more annoying than it appears because of oddities around JS logging

I don't see any -flush impls that look at *flush-on-newline*

wait sorry, that didn't make sense

it's the other way around

yes 🙂

the printing stuff looks at the flag to determine whether to invoke it

correct, but that invokes flush (no-op), not -flush?

I'll make a repro with my own Writer impl

oh, sorry I confused this with *print-newline*

@borkdude so maybe it's not supported because there's no such thing as I/O

no standard thing

right

like there's literally no place for this stuff to go

and output in JS is not buffer oriented

you're just going straight to console.log

I actually don't care that it's not supported, I just cared about compatibility of SCI <-> CLJS, so all good.

but it seems we can safely remove this: https://github.com/clojure/clojurescript/blob/29363bbd1d34bb2aeb7b4d762ee4f4ba2f173ddf/src/main/cljs/cljs/core.cljs#L10382

@borkdude hrm why would change anything?

not necessary - because maybe it will be done later

because doing less is usually faster?

if the code does nothing VMs are pretty good at figuring that out

not meaningful

Closure is also good at figuring it out too

I would be surprised if the map lookup would be compiled away

if anything is missing - it's fixing the docstrings about the state of things

but I won't die on this hill

the cost of a map look on something that's supposed to be I/O bound is not something to spend time on 🙂

the golden rule is to change nothing - unless we're adding something or fixing a bug

either way is fine with me. I think it could be a minor win, if the code was removed, that at least it wouldn't confuse people as much as it did me

I have a function with this line code: (js/Number.isFinite value) When I try to perform some unit tests on this function (using cljs.test) I get the error TypeError TypeError: 'undefined' is not a function (evaluating 'Number.isFinite(G__47385_47386)') Do native JS functions run on the testing environment?

@borkdude that's why I suggested fixing the docstring / adding a couple of comments about the state - I agree it's confusing when you start to look at it - and I didn't remember either

@rinam https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isFinite - it's been around for a while now - but always possible it's not available in the JS environment you are using

what environment?

@rinam does that mean your testing environment is the same as your program environment?

Are there people working with Web Components with ClojureScript or is it mostly used for React through Reagent?

ClojureScript existed long before React

ClojureScript is for delivering Clojure where the JVM is not available

it does not assume anything about where you are going except JS runtime is required

you can use Web Components from JS - so that means you can use Web Components w/ ClojureScript

I remember that hot reloading web components is a PITA

but important to conceptually decouple hot reloading UIs from ClojureScript

yes ClojureScript makes it easy to do - but it is not a requirement - many contexts still exist where that property might not be interesting

sure. I didn't take the question to be, "can we develop web components with ClojureScript?" but rather, "is this path well paved?" which I would say the web components + clojurescript DX is not well paved at all compared to using something like React. that's just a function of how much time, money, and people are trying to do that.

but is the DX any different from JS? If not - probably not a big deal

no idea, never done anything serious with WC

i.e. you still get a REPL etc.

just pointing out the baseline - if you can do it JS then you can do it in ClojureScript

and plenty of things exist now to make it frictionless (no externs, Webpack etc. works) - and the REPL still there

remembering now that web components really need class support

do Web Components actually break the old prototype patterns?

(if so we should capture that, if we didn't already)

IIRC it requires that special behavior w/ calling super() in the constructor that can't be shimmed via prototypes

https://github.com/WICG/webcomponents/issues/587#issuecomment-737139676 seems to claim different?

but I guess this is a problem - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields

ah yeah the Reflect.construct seems to be a way around that now

but only if people are using private fields above

which probably isn't true for extending native stuff

gotcha, it works for HTMLElement but not for all cases of user-land classes

right but even here there is no real problem - the thing about class is always the ever growing list of things it supposed to do

you can write JS WebComponents and use them and let JS tools sort it out