Clojurians Log v2

Just learned another cause of refresh not working - not installing react devtools :)

@lilactown this is really helpful. is this output from shadow? itd make my week to know how to do this...

(totally aside, very excited about the prospect of using helix. really exciting work.)

found it! i had not encountered this feature of shadow—changes everything 😂

🙏 thank you!!! (and thomas)

I'm making another 'REBL inspector' thing with Smalltalk-ey floating windows: https://github.com/jc776/bubble

Very cool!!!

I tried something similar myself but didn’t get nearly that far 😅

sure thing! glad you found the info you needed

@spacemods I see you created a way of handling reloading components with hooks. Did the fast-refresh / react-refresh integration not work for you?

How do we deal with peer dependencies on ‘react’ with the deps.cljs in 0.11?

:thinking_face: can you explain what you mean?

this is the second time someone has brought up issues with deps.cljs

I suppose it’s not a big deal. A lot of libraries declare a peer dependency on react directly

Is the recommended way of using helix to omit react from package.json?

no

Oh okay

AFAICT deps.cljs allows me to do a few things: • improve the “quick start” experience because I don’t even need to talk about installing via npm, if you don’t care what React version you use • ensure that all npm libs are installed, e.g. react-refresh, before enabling feature flags by default in the future • improve dev experience when used with the new :bundle target

I see an error (not sure if shadow or helix) when I upgrade:

IllegalArgumentException: No matching field found: exist for class <http://java.io|java.io>.File
        clojure.lang.Reflector.getInstanceField (Reflector.java:397)
        clojure.lang.Reflector.invokeNoArgInstanceMember (Reflector.java:440)
        shadow.cljs.devtools.server.npm-deps/install-deps (npm_deps.clj:160)
        shadow.cljs.devtools.server.npm-deps/install-deps (npm_deps.clj:131)
        shadow.cljs.devtools.server.npm-deps/main (npm_deps.clj:242)
        shadow.cljs.devtools.server.npm-deps/main (npm_deps.clj:228)
        shadow.cljs.devtools.cli-actual/main (cli_actual.clj:141)
        shadow.cljs.devtools.cli-actual/main (cli_actual.clj:132)
        clojure.core/apply (core.clj:669)
        clojure.core/apply (core.clj:660)
        shadow.cljs.devtools.cli-actual/-main (cli_actual.clj:219)
        shadow.cljs.devtools.cli-actual/-main (cli_actual.clj:217)
        clojure.lang.Var.applyTo (Var.java:705)
        clojure.core/apply (core.clj:665)
        clojure.core/apply (core.clj:660)
        shadow.cljs.devtools.cli/-main (cli.clj:75)
        shadow.cljs.devtools.cli/-main (cli.clj:67)
        clojure.lang.Var.applyTo (Var.java:705)
        clojure.core/apply (core.clj:665)
        clojure.main/main-opt (main.clj:514)
        clojure.main/main-opt (main.clj:510)
        clojure.main/main (main.clj:664)
        clojure.main/main (main.clj:616)
        clojure.lang.Var.applyTo (Var.java:705)
        clojure.main.main (main.java:40)

I can try to carve out a minimal repro if this is new/unknown

hm

I haven’t seen that

do you have a package.json file?

yes

yeah, it might be a bug in shadow?

I would try and repro it

i’m going to bump our project at work just to be sure

Looks like it broke from shadow 2.9.8 to 2.9.9

So deps.cljs get written to my package.json, nice!

woo!

but yes, feel free to override react however you like

That makes way more sense than my mental model earlier

and I guess you don’t mind losing local state much since you’re storing most of it in a global atom?

I'm not noticing any local state being lost - the selected tab in 'TabView' is local; seems to be preserved in small changes to the window, tab view, the 'register-inspector' and all. It does reset on breaking changes to nesting or order without 'key', and deliberately when hooks change - does react-refresh do something more clever than 'reset' for changes to hooks?

hmm yeah, I guess as long as you keep the function reference the same it won’t re-mount the component :thinking_face:

react-hooks technically supports the ability to differentiate between different “kinds” of hooks changes - e.g. if you change the body of an effect, it won’t re-mount. but if you change the order of hooks or change the initial state, it will re-mount

but it might be just as easy to support that in what you’re doing which is just keeping the reference stable

I like it!

very clever

cool, thanks!