Does anyone have any idea what might be stopping a reagent component hot code reloading on save in shadow-cljs? The parent component re-renders on save fine; but changing code in the non-reloading component only works on a page refresh :thinking_face:

I have a single ^:dev/after-load set on the exported fn that binds my app component to the DOM with r/render

ahh I have some warnings I might want to clean up to do with unique prop keys

hmmm one thing that’s strange is the * Components view in chrome dev tools, shows the parent component is registered twice into the hierarchy; as a sibling next to itself… but only one of them has child components

none of the others are like this

@rickmoynihan hard to say without seeing some code

maybe try setting :devtools {:reload-strategy :full} in your build config (only works if you have the latest shadow-cljs version)

interesting that seems to work! :thumbsup:

what does it do exactly?

hold on checking manual 👀

its not in the manual. added it recently because a lot of people seem to rely on it

https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html

> It also is essential that all your data is kept in a central place since hot-reloading gets a lot more complex if data is spread all over the place. Even to the point of not being useful at all anymore. Does this mean it’s problematic having more than one r/atom?

I currently have a few defonce ’d r/atom s

I don't use reagent. If that workflow works for you then keep doing it.

Is there a recommended way to cache dependencies? Currently I’m thinking of caching the ~/.m2/repository directory, and creating a hash from .shadow-cljs/classpath.edn to invalidate. (This is for a CI environment BTW).

can't really use classpath.edn since it won't exist between CI runs?

just shadow-cljs.edn should be fine

Oh, true

Oh yeah haha, thank thheller!

I’m getting a :shadow.build.npm/js-invalid-requires on this code:

return _interopRequireWildcard(require("".concat(
        /* webpackChunkName: "icon.[request]" */
        // It's important that we don't use a template string here, it
        // stops webpack from building a dynamic require context.
        // eslint-disable-next-line prefer-template
        './assets/' + typeToPathMap[iconType] + '.js')))

my guess is it’s the dynamic path creation. does anyone have intuition if I should try to solve this on the shadow or library side?

https://github.com/thheller/shadow-cljs/issues/486

NM

I was going to ask if client IP whitelisting could be updated to use ring.middleware.proxy-headers.wrap-forwarded-remote-addr (i.e. X-Forwarded-For) but for some baffling reason, it sets :remote-addr to the /last/ address in X-Forwarded-For which is a proxy and usually user-controllable, respecting what was user-sent (the /first/ address is the original client IP) :man-facepalming:

shadow-cljs doedn't use that middleware so I'm not sure what you are referring to

I was going to propose its use, is all 🙂

I solved my forwarding issue by port forwarding /to/ the network address of my local machine rather than loopback, which fixes :remote-ip to always appear to be 192.168.xx.xx rather than 127.0.0.1 🙂

unfortunately still facing the issue in https://github.com/thheller/shadow-cljs/issues/662 (to which I replied, hopefully providing enough info now)

I wonder, when I run npx shadow-cljs watch :main and then connect to the NRepl started by shadow, I have to execute (shadow/repl :main) in the repl to actually get into the cljs repl. Is there some way to automate this so that shadow/repl would start automatically instead of me typing it every time?

unfortunately no since the client has to setup its sessions

With that last change the setup now works perfectly @thheller -- thanks so much for responding and working through this!

is getting The required namespace "cljs.user" is not available. when saving files via a connected repl a known issue?