Fork me on GitHub
#shadow-cljs
<
2021-06-29
>
Adam Kalisz03:06:10

With the new ClojureScript 1.10.866 and shadow-cljs 2.14.5 combined with reagent-utils 0.3.4 I have a problem, where my release builds don't set cookies with correct options such as Expires, Secure or SameSite. Any ideas @thheller how to debug this further? https://github.com/reagent-project/reagent-utils/issues/19

Adam Kalisz04:06:29

It looks like we will get there. reagent-utils depends on API changes present in the latest GCL in respect to setting SameSite on cookies and I had a mixup of dependencies - basically my release builds were using a different (older) GCL than the testing it seems.

Adam Kalisz05:06:34

Ok, so the GCL that shadow-cljs depends on is too old and the newer one from May 2021 doesn't seem to work.

thheller06:06:33

I'd probably just use the GCL code directly without the reagent-utils

thheller06:06:51

looks like something in the GCL code changed. it is now a separate namespace apparently

thheller06:06:42

goog.net.cookies is what reagent-utils uses but it is now goog.net.Cookies I guess?

thheller06:06:39

but as far as I know SameSite must be set by the server?

Adam Kalisz13:06:54

It makes usually more sense to set it in a server response but I don't think it is a requirement.

thheller06:06:51

it really doesn't matter if you set it on the client? or does it? not sure

Adam Kalisz12:06:44

Yes, perhaps this is the easiest way out. One less dependency also

rgm20:06:35

I’m trying to make a little Reagent app that sits in a Wordpress site. The site has already loaded react in its <head> so I don’t want shadow to prepend it to my release JS. If possible, it’d be great if shadow just assumes it’s there. Can anyone point me to the instructions for doing this? I’m having some trouble finding them. (Also, I’m using Reagent 1.1.0 which I believe removed the react dependency).

sova-soars-the-sora04:06:48

i suspect that is not gonna work unfortunately... but i could be wrong

sova-soars-the-sora04:06:27

the V8 closure compiler ought to do very furious dead-code elimination, so a release build ought to be fairly minimal. will the compilation step in shadow-cljs work without knowing what [the heck] react is? 自信ない (not confident about that)

sova-soars-the-sora04:06:54

i'm a newb tho so 😅

rgm14:07:15

Yeah, but the google closure compiler isn’t going to do dead-code elimination on a foreign lib, unless something’s changed recently. My recollection is that shadow just adds the minified react JS as a prefix to the whole bundle, because what else can it do with code that’s not closure-compatible. I did figure it out though: if I leave React out of the package.json, and provide stub cljs namespaces to link the cljs symbols to the names React hangs off of the global js/React, it seems all’s well and I get a shadow bundle leaning on the React that Wordpress has already provided on js/window. See https://gist.github.com/rgm/9ebc632a19074dea1a69955336fd3c8c

rgm20:07:55

oh, well that’s a lot simpler. Thanks!

rgm14:07:15

Yeah, but the google closure compiler isn’t going to do dead-code elimination on a foreign lib, unless something’s changed recently. My recollection is that shadow just adds the minified react JS as a prefix to the whole bundle, because what else can it do with code that’s not closure-compatible. I did figure it out though: if I leave React out of the package.json, and provide stub cljs namespaces to link the cljs symbols to the names React hangs off of the global js/React, it seems all’s well and I get a shadow bundle leaning on the React that Wordpress has already provided on js/window. See https://gist.github.com/rgm/9ebc632a19074dea1a69955336fd3c8c