Fork me on GitHub
#shadow-cljs
<
2019-11-15
>
thheller00:11:04

anyways .. wrote it all again in case someone is interested in the vdom stuff. still very far away from something actually usable but some of you seemed interested https://github.com/thheller/shadow-experiments/blob/master/doc/arborist-components.md

šŸ”„ 8
Aklscc08:11:47

Hi, I'm so sorry to bother you. I have run a react-native project, and use a js file in it. The project looks like:

src
ā”œā”€ā”€ main
ā”œ       ā”œā”€ā”€ main.clj
ā””ā”€ā”€ js_libs
ā”œ       ā”œā”€ā”€ my.js
If I run it in product mode, works well. And I run it in development mode, then occurs an error:
Can't find variable: shadow$provide
eval
    [native code]
globalEval
    index.js:828:25
evalLoad
    index.js:2082:24
<unknown>
    index.js:2404:20
loadModuleImplementation
    require.js:331:6
<unknown>
    index.js:1
loadModuleImplementation
    require.js:331:6
guardedLoadModule
    require.js:197:45
global code
What's the shadow$provide? @thheller

thheller09:11:33

@180338742 the JS support currently has issues with commonjs code. try to use ESM import/export instead

Aklscc10:11:22

Thank you~

mping11:11:58

Hi all, is it possible to supply a handler-creating fn to :devtools opt?

mping11:11:27

currently the wiki states :http-handler shadow.http.push-state/handle

mping11:11:47

but I want to wire my own handler, who is created by invoking a fn (defn make-handler [cfg]...)

thheller11:11:39

in my experience 100% of the time where you need handlers that actually do stuff you should be writing your own server

thheller11:11:54

you are not going to run shadow-cljs in production either

thheller11:11:04

just create your own CLJ server and use that

thheller11:11:17

there is nothing the server needs to do for shadow-cljs to work

mping11:11:18

Thats great insight; I guess my handler just needs to render the appropriate html file then?

thheller11:11:33

whatever it would be doing in production too yes

thheller11:11:52

just like production the only thing it will need to do is serve static files

thheller11:11:13

(that could be a nginx or something sitting in front of it)

thheller11:11:35

I'm just assuming here that the handler you are talking about is an actual CLJ server-side "app"

mping11:11:39

thanks @thheller that clears it

orestis12:11:46

@thheller After upgrading shadow and React to the latest version, hot-reloading lazy-loaded components with hx works -- here's an example repo for anyone curious: https://github.com/orestis/shadow-hx-lazy-load

orestis13:11:03

Any clues about what brings in this "@" npm module? It only have date-fns imports.

thheller13:11:02

that it likely datefns

thheller13:11:29

the node_modules/date-fns/package.json is likely empty or doesn't exist at all

thheller13:11:45

or just wasn't read correctly

thheller13:11:09

@ is just because it concats (str package-name "@" version) or something

thheller13:11:18

guess there can be cases where that is empty

orestis14:11:21

Nothing seemingly wrong with node_modules/date-fns/package.json

orestis14:11:21

And there's another date-fns later down the build

thheller14:11:29

dunno might just be a bug not identifying the package correctly

thheller14:11:40

if you can reproduce this feel free to open an issue

orestis14:11:32

The "empty" row is the one of the first screenshot, the expanded date-fns is what I show now.

orestis14:11:54

Cool, I just wanted to see if you had any obvious insights. I'll try to repro.

orestis14:11:25

Interesting: node_modules/date-fns/parseISO/index.js vs node_modules/date-fns/_lib/setUTCDay/index.js -- there's a _lib prefix in the last one.

orestis14:11:58

Hah, it's actually different files. Not sure why the reporting looks off, but the actual content is not duplicated as I thought -- so it's only a reporting glitch.

orestis14:11:11

Hm, shouldn't checking for js/goog.DEBUG result in DCE in release builds?

thheller14:11:29

if you hint it with ^boolean

orestis14:11:58

Ah, I thought that this was fixed in the CLJS compiler? I saw some discussion and "closed" ticket in cljs-dev.

orestis14:11:24

The code I see generated looks like: $APP.l(!1)&&(JO.displayName="nosco.views.page-list/DeletePagesButton")

thheller14:11:27

maybe in master. not in 520

orestis14:11:35

Ah, ok. I'll wait for it to land then.

thheller14:11:43

just hint it

orestis14:11:47

It's in a library šŸ™‚

orestis15:11:03

I got a little bit obsessed with code size, having seen my build balloon to 2MB of JS, so now I'm testing out splitting code etc. Of course, most of it is huge JS libraries.

thheller15:11:56

hehe. yep JS will do that šŸ™‚

orestis15:11:50

Yeah, bringing in their own polyfills even. And then when I wanted to use https://projectfluent.org, they hard-drop IE11 compatibility by extending Map so no polyfill can fix that šŸ˜ž

orestis15:11:45

If a JS project exports both common.js and ESM versions, like

"main": "dist/react-beautiful-dnd.cjs.js",
  "module": "dist/react-beautiful-dnd.esm.js",
it seems shadow prefers the cjs one. Does it make any practical difference?

thheller15:11:00

you can try :js-options {:entry-keys ["module" "main"]} to pick module over main

thheller15:11:29

in my experience things break far more often since ESM->CJS interop is still somewhat undefined