Fork me on GitHub
#shadow-cljs
<
2022-08-02
>
blackawa12:08:36

@thheller Thank you for reply. > the issue was gone too to be honest I read https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/server/fs_watch.clj & https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/util/FileWatcher.java, and I thought so too. My environment is below: • Java: openjdk 17.0.3 2022-04-19 LTS • shadow-cljs: 2.19.6 • Node.js: v16.16.0 • VSCode: 1.69.2 • Docker: 20.10.17, build 100c701 • Docker Desktop for Windows: 4.10.1 • Windows: 10(19044, 1826) You can use https://github.com/blackawa/isomorphic-clojure-webapp to reproduce an issue. I tried on 2 Windows machine, and trying on my Mac machine tonight.

thheller13:08:32

well its a known issue that file watchers have trouble working in containers. not really specific to shadow-cljs at all. I don't know how devcontainers work exactly so I don't have any guesses

Michaël Salihi14:08:07

Does :target :browser support js/require?

thheller14:08:07

does your browser support require(...)? 😛 no, it doesn't.

Michaël Salihi15:08:35

Well OK, I thought maybe there was some machinery at the bundle level because I saw on some React/Reagent projects (def sym (js/require...) but I'm sure now that is the case for :target :react-native for eg. https://github.com/thheller/reagent-react-native/blob/master/src/main/test/app.cljs#L11 Thanks for the confirmation. 😉

thheller15:08:44

yes, this is react-native specific

Michaël Salihi15:08:07

And in this snippet (coming from React Inertia.js doc https://inertiajs.com/client-side-setup), it's managed by the bundler I guess.

createInertiaApp({
  resolve: name => require(`./Pages/${name}`),
  setup({ el, App, props }) {
    render(<App {...props} />, el)
  },
})

thheller15:08:12

yes, handled by webpack

thheller15:08:27

in that case js/require would be supported, assuming the shadow-cljs is run through the webpack build as well

Michaël Salihi15:08:26

interesting...yes with using Shadow-CLJS :js-provider :externaloption for example. I'm thinking about using your Next-cljs hook trick https://github.com/thheller/next-cljs/blob/master/shadow-cljs.edn#L13 to generate pages to require it automatically like the above Inertia example.

thheller15:08:22

no :external would not work for this. the CLJS output doesn't go through webpack in that case

Michaël Salihi15:08:27

> no :external would not work for this Ha ok. so what the solution? Continue to use :target :browserand pass the generated JS bundled file through Webpack directly?

thheller16:08:27

sorry I don't know inertia so I don't know what any of this is supposed to do

Michaël Salihi18:08:15

In few words, Inertia backend adapter add a data-page attribute containing a stringify JSON obj. Eg:

<div id="app" data-page="{component: \"homepage\", props:{}">

Michaël Salihi18:08:53

On the front end, Inertia reads this pageobject to get props and the current component name (here homepage).

createInertiaApp({
  resolve: name => require(`./Pages/${name}`),
  setup({ el, App, props }) {
    render(<App {...props} />, el)
  },
})

Michaël Salihi18:08:25

So the require line automatically import ./Pages/homepage.js component.

Michaël Salihi18:08:49

in CLJS, I think we can't rely on file-based routing or easily use the require like in JS so for now I manually "link" the component name with cljs symbols like here: https://github.com/prestancedesign/pingcrm-clojure/blob/main/src/cljs/pingcrm/app.cljs#L18-L34

Michaël Salihi18:08:52

Ideally, what I want to accomplish is to be able to make this dynamic. Perhaps an automatic import of namespaces via a macro would also be a solution. I will continue to search. Thanks for your time and help.

thheller19:08:48

the struggle with integration in some other JS build systems is that they almost always rely on filesystem structure

thheller19:08:08

since they don't have a proper namespacing system that is the somewhat obvious thing to do of course

thheller19:08:21

but it doesn't really fit with how CLJS sees the world

thheller19:08:30

so there are rough edges when it comes to this kind of stuff

thheller19:08:42

:npm-module sort of is the most granular

thheller19:08:53

and if you generate some additional glue code with a hook that should work best

thheller19:08:24

I mean that why I structured my stuff the way I did

thheller19:08:41

just sometimes means that some stuff needs to maybe stay in actual JS files

thheller19:08:53

(generated or not)

Michaël Salihi19:08:17

Thanks for your insights, it's always very helpful!

thheller16:08:59

:browser output is not meant to go through another build tool

thheller16:08:06

you should use :npm-module or :esm for that

Michaël Salihi17:08:21

Thank you very much for these precisions. I'm going to test different solution to see what's the best one.