Hi there, I am using shadow-cljs with keechma. Hot-reload on the keechma project works with figwheel but does not work with shadow-cljs.

A sample project can be found here: https://github.com/mjmeintjes/shadow-cljs-keechma-node?files=1

How a keechma project is structured is usually this: core.cljs -> app/definition -> ui/ui -> component

In figwheel when the component is modified the dependency graph is resolved correctly, and app/definition is reloaded. In shadow-cljs, the reloading propogates from component and stops at ui/ui

The browser console output for shadow-cljs for the code above is as follows:

shadow-cljs: call example.client.core/stop 
shadow-cljs: load JS example/client/ui/main.cljs 
shadow-cljs: load JS example/client/ui.cljs
shadow-cljs: load JS example/client/core.cljs

The changes did not propagate to although it clearly has a dependency on ui/ui:

(def definition
  {:components    ui
   :controllers   controllers
   :subscriptions subscriptions
   :router :history
   :routes [":category/:page"]})

@priornix this is https://github.com/thheller/shadow-cljs/issues/349

you are keeping references to namespace defs in a map in another namespace

honestly this should be avoided as this is global state

Yes, that's true.

It does make the code simpler though.

so you currently have 2 options

(defn definition [] ...) and change all references to (definition)

this will recreate the map whenever it is used. ensuring that it has all the latest references

I tried to do that earlier that, but it didn't work.

or tag the namespace with (ns ^:dev/always the.ns-with-definition)

but honestly thats horrible

Yes haha

I'd rather go with the first approach, but I didn't manage to get it to work, I'll try to replace ui as well.

geez .. there is sooooooo much global state in this ...

https://github.com/mjmeintjes/shadow-cljs-keechma-node/blob/master/src/example/client/core.cljs#L17-L19

every file is full of it

https://github.com/mjmeintjes/shadow-cljs-keechma-node/blob/master/src/example/client/subscriptions.cljs#L15-L16

Yes, that's how keechma is structured. It's only for the component and the app-definition though. States are kept in it's own space. Feel free to ping @mihaelkonjevic

Having said that, I prefer keechma to re-frame it's a higher order abstraction than re-frame and deals nicely with app states

hmm yeah I'll add an option to force reload all dependents

Actually if you look at re-frame it's full of global states as well

https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/events.cljs

its generally not necessary and slower

https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/db.cljs

yeah I know but those update references in a global map on each reload and generally don't keep state from another namespace

(def x {:a another/b})

thi sis the only problem

calling functions etc from other namespace is not a problem

or rather not even that is the problem

the issue is when there is one-hop

So currently figwheel does a global reload

(def x {:a ns2/thing}) (ns ns2) (def thing {:a ns3/thing})

Got it

figwheel isn't really involved in this

the default in CLJS is to :recompile-dependents

and all of them will be reloaded

For now we can put the keechma definitions all within a file. Just a matter of convention

but this recompiles a lot more namespaces that don't actually need to be recompiled

Right

Hence why shadow is much faster

so it can be a lot slower in bigger apps

so what is really needed is a :reload-dependents option

since the code didn't change we only need to reload it to trigger the global state updates

without actually recompiling it

Yes, I was looking for such an option. To manually specify certain namespaces to be reloaded always

The other way is to let the developer specify the namespaces that has to be reloaded. so {:reload-namspace :all} versus {:reload-namespace [foobar.core]}

the other option is to not use those chained references from one namespace to another

(ns a {:a another/a}) is totally fine

since that ns will depend on another both will be reloaded

Right

the problem is when the second depends on the third because the first won't depend on the third

you can just require the third in the first to make it reload

then everything should work as expected

Makes the code fragile though, having to remember which ones to require

Fragile only in dev-mode of course

Anyway, thanks @thheller for the help and the great tool.

this has come up often enough now that I'll probably add it soon 😉

On dependencies in workers that depend on window: I've gone from multiple builds to splitting into multiple modules, that made them build together, but it's the :devtools :preloads fulcro.inspect.preload that have the thing that depends on window.-localStorage

ah!

right those always get added to the default module

hmm

okay, it's not really a big issue for me

happy they build together now 🙂

I can probably add support for :preloads in :modules themselves

makes more sense actually

so each module can have its own preloads instead

Yeah that makes sense to me.

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

Another issue I now face is that if I want to do a

(defn ^:dev/after-load recalc []
  (prim/transact!
   (:reconciler @app)
   `[(gsv.api.mutations/update-some-data {})]))

:after-load should maybe be available from the config though. Looking into that.

what do you mean?

The namespace that starts the worker doesn't get re-evalled when just the worker changes.

I want to redo the calculation that uses the worker.

then you must create an after-load fn in the main app that notifies the worker to recalc (eg. send a message to it)

shadow-cljs can't do that for you

live-reloading currently also doesn't work for workers

so I recommend killing them in a hook and restarting them

it has been a while since I used the worker stuff myself. I think there are still a few rough edges that could be tweaked

Yeah for now I've just been loading many workers and reloading the namespace that starts them, not caring about cleaning them up.

So I see the shadow-cljs logo when the worker compilation happened. But I can't seem to find a hook into it from the config. These don't seem to work. https://shadow-cljs.github.io/docs/UsersGuide.html#build-hooks

what do you mean by worker compilation happened? I though you used :modules?

Yes, I mean when I change the worker cljs the build recompiles it.

yes as I said .. no live-reload happens IN the worker itself

I don't mind that. But the file that loads the worker needs to reload it.

yes you do that via :dev/after-load

So now I have to change the worker, and the file that requires it. No biggie, but would be nice if changing the worker triggered the reload on namespace that requires the worker.

(defn ^:dev/after-load restart-workers [] (.terminate the-worker) (start-the-worker))

in the namespace that manages the worker

not the code of the worker itself

that after-load won't be called if I just change the worker.

yes it will?

Hmm, let me re-check.

remember NOT in the worker file itself

Yes, changing the worker file, saving, triggers a recompilation. But neither the :after-load from :devtools nor the annotated function from the namespace that requires the worker gets called.

Unless I change the file that requires the worker.

after-load is completely independent of actual compilation

open the browser console and post the log please

oh wait haha I think it might just "optimize" the restart cycle away completely

since non of the main-build code changed there is nothing to reload

thus it is skipped completely

Yes, that could be it. The

shadow-cljs: call gsv.client/start
browser.cljs:25 shadow-cljs: call gsv.client/recalc
util.cljs:187 Installing CLJS DevTools 0.9.10 and enabling features :formatters :hints :async

hehe yep the reload gets optimized out

the browser main doesn't have the worker code loaded (obviously) so it decides that it doesn't need to reload any code

and skips calling the lifecycle fns as well

That makes sense, I am quite happy that it loads "just what changed" usually 🙂

Anyway it's not a big deal to just change both files so don't worry about solving it quickly or so.

hmm I could always trigger the lifecycle but I doubt that you usually want that

you could annotate some namespace with :dev/always so that some file of the main thread always gets reloaded

but that seems rather dirty

Hmm that could work, when developing I usually reload that namespace anyway.

yeah but dependents also get reloaded. its a bit messy

you could add an empty preload I guess

(ns ^:dev/always some.reload-helper)

:preloads [some.reload-helper]

so nobody depends on that ns but it always gets reloaded to trigger the lifecycle fns

super ugly hack but should work

I need to review some of the webworker stuff to figure out how to deal with this properly

Yep! That works and will do fine for now I think. :thumbsup:

Thank you.

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

Has anybody gotten the latest posh working with shadow-cljs?

-- Syntax error -------------------
  (... ... ... (... [posh.plugin-base :as base :include-macros] ... ... ...))
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
has extra input

------ ERROR -------------------------------------------------------------------
 File: jar:file:/tank/ranmason/.m2/repository/posh/posh/0.5.6/posh-0.5.6.jar!/posh/reagent.cljs:1:1
--------------------------------------------------------------------------------
   1 | (ns posh.reagent
-------^------------------------------------------------------------------------
Invalid namespace declaration
-- Spec failed --------------------
  (... ... ... (:require ... ... ... ...))
                ^^^^^^^^
should be one of: :import, :import-macros, :refer-clojure, :require-macros, :use, :use-macros

this is an invalid ns form

https://github.com/mpdairy/posh/blob/master/src/posh/reagent.cljs#L3-L4

shadow-cljs validates more strictly than the default so the default just sort of works accidentally

should be :include-macros true or better yet a :require-macros in the posh.plugin-base itself

That was it.