Fork me on GitHub
#shadow-cljs
<
2021-11-07
>
geraldodev00:11:57

I'm having internal compiler error with react-data-grid . It happens with last shadow-cljs and the previous one. unexpected variable layoutCssVars Node(NAME layoutCssVars): node_modules/react-data-grid/lib/bundle.js:550:4 layoutCssVars, Parent(STRING_KEY layoutCssVars): node_modules/react-data-grid/lib/bundle.js:550:4 layoutCssVars

thheller07:11:35

@ghaskins how do you have multiple set-cookie headers in a :dev-http server? not against adding that change just curious how you even get there?

thheller07:11:40

@geraldodev looks like either invalid code or a bug in the closure compiler. can't really say and unfortunately also can't do anything about it

thheller07:11:06

if you search the closure compiler repo for "Unexpected variable" you'll find a bunch of reports. doesn't seem to be a new issue

geraldodev10:11:52

@thheller I took https://github.com/shadow-cljs/quickstart-browser added react and react-data-grid, changed the version of shadow in package.json to "shadow-cljs": "2.11.23" to pin the exact version, added (:require ["react-data-grid" :default DataGrid]) on the main file and it compiled. I did (js/console.log DataGrid) and it showed the js class on console. I've changed the version to "^2.16.0" and got the internal error message

thheller14:11:34

that unfortunately doesn't help much. I guess you can continue using that older version but downgrading the closure compiler otherwise unfortunately isn't an option

geraldodev16:11:15

@thheller I've told too early that I've tested on the last one and the previous one, although my 2.15.3 test was messed up by the global shadow-cljs that I had. Version 2.15.3 works, version 2.16.0 does not. I see that 2.15.3 version uses closure-compiler-unshaded v20210505 and 2.16.0 version uses v20211006 compiler

geraldodev16:11:19

Btw, it's impressive that this project is typescript and babel dependent and I don't have to deal witha any of this, all taken care by shadow-cljs.

ghaskins12:11:13

@thheller to be clear, the set-cookies are coming from the backend that the dev-http server is proxying. In that case, the backend may sometimes want to set more than one cookie, e.g. in some oauth flows where both OP and RP state is being maintained in cookies

ghaskins12:11:57

The mistake I made in the original code was assuming there would only ever be one set-cookie header, but this breaks down in examples such as above

ghaskins12:11:15

The reason for the above is that the cookies may have different configurations…for instance, one might be related to token-refresh and is scoped down to just Path=/oauth, whereas the other is related to the application session state and is more broadly used, e.g. Path=/