I have been doing some electron work in plain JS recently — one side is the “server” side which is Node with some extra electron APIs you require. The other side is the client side with also some extra APIs. I think it could be treated as just two separate targets…

Would anyone else also find it useful to be able to specify a vector of functions for :before-load and :after-load in devtools options?

I end up making on-reload! functions which only exist to trigger cleanup/reset behaviour from namespaces which have no other relationship to each other

@orestis wasn't the browser/renderer side also able to use require?

@thheller I think so, yes — but I haven’t dug that deep yet.

IIRC you are able to require the electron APIs from both sides, but the browser side gets access to the “remote” part of that.

So some kind of built-in RPC I think.

I’m not sure how that works, but for shadow to do its thing you should just be able to expose a require function, no?

@mhuebert I could certainly add that but it sounds like you have some global state that needs refreshing? global state is tricky when it comes to reloading.

I might toy around with shadow and electron today as a break.

@orestis either way you can definitely build something with shadow. if require is possible you might get away with one build instead of two though.

@thheller the 3 things I currently do on reload are (1) clear a global error state which is set when a react component throws, (2) re-render react component tree from root, and (3) I have a logging lib which uses logging groups, and open groups need to be closed on refresh

I’ll have to check and see what the assumptions are — because one side is definitely no-browser, whereas the other side yes-browser.

@mhuebert you could do this in :before-load maybe?

@thheller I think if i would clear the error state before load, that would trigger a re-render before the new (possibly-fixed) views have been loaded

the logging stuff could be though

and just calling the other on-reload! fns directly from your one on-reload! doesn't work?

that does, it was just mildly awkward because i didn’t have any existing namespace which could require all of the namespaces which had functions to be called

so i had to create a separate thing in a utility library which all of these namespaces could then require, and register on-load functions

eg

(defonce on-reload* (atom {}))

(defn on-reload
  "Register a callback to fire when page reloads (during development)"
  [key f]
  (swap! on-reload* assoc key f))

(defn reload!
  "Fire registered reload callbacks"
  []
  (doseq [f (vals @on-reload*)]
    (f)))

the trouble with a vector of multiple :after-load fns is that it can't control async

right

i wasn’t thinking about that for my case

this will be fine for now

I was thinking about this zero-conf stuff a bit. we could certainly have some other ways to configure these hooks

eg. (ns my.awesome.stuff {:shadow/after-load some-fn-in-this-ns} ...)

ns meta doesn't hurt since it doesn't end up in optimized code

as a library author, if someone uses re-view it would be nice to say “and add re-view.render-loop/render to your :after-load option”

oh

yeah that would be cool

better than having to give instructions

could also just put it on the fn itself

(defn ^:shadow/after-load on-reload! [] ...)

compiler could even be smart and just ignore those fns when compiling release builds

i guess the downside is that for a library that is less good, as you don’t want to impose specific tooling on users. not that metadata imposes it, but you don’t want (defn ^:shadow/after-load , ^:figwheel/after-load ...) (*I can’t remember what metadata figwheel all uses, i remember something like ^:figwheel-always)

sure we could do something generic that other tools could support as well

I think this is only an issue with global state though which you shouldn't have in the first place 😛

haha. in a dream world

hehe yeah

I always unmount in :before-load just to avoid things interfering with reload

seems there're two styles for configuration for clojure now lein style and tools.deps style: paths vs source-paths, deps vs dependencies, repos vs repositories. will it be a good idea to support both or insisting on the lein style or just like user use tools.deps with shadow-cljs?

@doglooksgood don't know about allowing two different styles in shadow-cljs.edn itself but maybe