Are you sure c isn’t reloading? Throw in some printlns to rule out that this isn’t a dataflow issue.

Meaning, c/render doesn’t take any arguments here and there is no internal hooks so it has no reason to know to rerender (even if the code has changed and reloaded)

Same thing with b/render

So adding printlns confirms that the files are reloaded correctly on save (ie. modifying c.cljs will cause c and b to be reloaded

and it also confirms that the render functions are not fired

But, when requiring c from a then the render function is fired… Which is what I am having trouble understanding

ie. I could understand it one way or the other, but why does re-requiring c from a cause it to work?

been there, partner haha

The order of requires is probably important there too.

(ns a
  (:require b c))

(ns a 
  (:require c b))

I'm guessing that c/render needs to be redefined first, then b/render, then a/render for hot reload path to function correctly

due to potential for eager binding in scope capture

do you by any chance use react 18 ? i remember seeing an issue on live reload with 3 namespaces

https://github.com/reagent-project/reagent/issues/579

I’m actually using react 16 I believe

as far as I can tell this is all working as intented

see the recompile logic & gotchas described here https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html

Agreed, I think this is more of a reactive coding / framework nuance issue and shadow is working as expected

Yeah I think it has to do with react memoization inside uix v1

The dummy prop is a cute trick though, hadn’t thought of that.

I've been called worse 😉

since it doesn't support source maps at all there really isn't anything to do

it looks like react native supports source maps yeah? https://reactnative.dev/docs/next/sourcemaps

yes, for the sources it processes itself

but not input source maps

input source maps are an issue with Metro that I’ve been looking at for a couple weeks now yeah

the eval js maps are only emitted so source maps at least work when using the run in chrome thing

oh, so these “embedded” source maps produced by shadow dev builds never have to be processed as input source maps if they’re evaluated at runtime right?

not sure thats even still a thing though. been a couple of years since I looked at react native stuff

they aren't meant to be processed by metro no

i guess the important question here is if shadow can be configured to create a dev build without the embedded source maps

you can use :target :npm-module for that

that loads just fine in react-native IIRC, may require some boilerplate though

but that target does no eval and has regular source maps

hmm okay, i'm surprised no one else has asked for this. I’m pretty sure the embedded source maps are responsible for nonsensical stack traces inside Expo: https://docs.expo.dev/get-started/errors/#redbox-errors-and-stack-traces

but IIRC it had the issue that metro will try to process everything. and it used to take a lllooooooooooong time to process cljs.core

I spent a lot of time trying to get source maps to work

and it just wasn't possible back then

I doubt much has changed but haven't checked in a long time

if you get it to work with :target :npm-module I'll happily change :target :react-native

metro issue #104 has been open for five years, yeah I saw your post on it there all those years ago, I took a stab at it, still trying

but there is no option to turn of the eval mode for :react-native. it is there for good reasons

im new to react-native which is part of the problem here, but what are the reasons for the eval? was it specifically for testing react-native somehow in chrome?

speed is biggest reason

if you expose sources to metro it'll process all of them

and takes like 30sec or so for cljs.core alone, so things just get annoyingly slow

oooh, that explains why I have not seen a speed issue

(it used to anyways, not sure its still an issue)

i saw the re-natal-husk solution in the cljsrn wiki talking about the slowness with that

but also this was the only way to get source maps to work reliably in the chrome devtools runtime thingy

yes, just run with :target :npm-module and you'll see if its still slow

i suppose most people are just developing on chrome, then for prod they’re manually mapping error locations in the sentry logs to cljs sources using their own manual tooling

no clue what people do. I have never done any actual react-native dev myself

i got a stack trace trying to load an npm-module build into Expo Go

might be a path issue

i'll go down this rabbit hole another time, but thanks for the context here.

@thheller I’m trying again to get :target :npm-module working on react native to test if it’s still slow. I see that it doesn’t generate an <output-dir>/index.js like target react-native would.

Is there a way I can recreate that index.js file required by react-native, I feel that including my main project’s js file will be missing other things that seem to be included by shadow-cljs to make the build work

why does it have to generate the index.js? I mean just create it yourself?

just something like require("./cljs/your.ns.js").init(); or so

that was my question actually why your react-native target creates one, and what would I be missing if I tried to do it myself

thumbing through it, I saw a lot of shadow-react-native namespaces being included

the :target :react-native tries to HIDE all the CLJS output from metro

but still try to make all JS requires visible

thats why it creates a bunch of boilerplate code

:npm-module is just plain commonjs, it doesn't try to hide anything and therefore doesn't need all this boilerplate

but that also means that metro will process all of it, which used to be very slow

the only point of the index.js is to have some code that renders something. that code can be all CLJS, but it needs to be a called from a index.js file

so just that one line loading the cljs code and calling the init fn is equivalent to what :init-fn in :target :react-native does

got it, thank you

I created the index.js file with require('./dev.js').init_BANG_(), since our config has :init-fn dev/init!, but I got back an error when trying to load it:

iOS Bundling complete 130ms
 ERROR  Error: Requiring unknown module "undefined".

whats the full error? where is the undefined coming from?

as I just explained. it is obviously not equivalent in mechanics, since it doesn't do any of the hiding

but if you strip out the hiding part, then just the init call remains

if you want to setup a repo I can take a look

otherwise I can't really guess enough what you are doing

the 130ms is already suspicious enough. there is no way it processed all the code in that time

also I strongly recommend keeping the generated code separate

so :output-dir "cljs" so that all the files go to <project>/cljs/..., then <project>/index.js does require('./cljs/dev.js').init_BANG_()

that way you can at any time kill the cljs dir without worrying about any of your other files

I am driving to a doctors appt, i will answer when i get back. There's a lot to debug and figure out but i got no info on where the error was coming from. The build time of 130ms was because it was a rebuild, it took longer the first time. Sorry and thank you