Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-06-29

Channels

#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