Clojurians Log v2

server/client sure. client/worker no, since that would require some kind of runtime knowledge?

and no reader features cannot be used for this at all

but the macro can check (:ns &env) . that is generally only available when compiling CLJS, so would be nil when expanding clojure code

@thheller Thanks!! How could a macro know whether it is in the worker or in the ui module? If I set a var, will this leak between ui and worker?

just forget about that line of thought. it is unreliable and bug prone at best

do no write macros that want to keep 3 "worlds" in one

if you provide more context of what you are trying to do I can maybe make suggestions

but the compiler itself has no notion of what a worker is during compilation

the :web-worker option literally just prepends a bit of code to the output file after compilation

@thheller I have fulcro mutations and database mutations on server and worker. Let us say the mutation is net.markusgraf.hhh.address.model/add-address. Since the database mutations are on the server AND the worker they need to go into a cljc file. But I can not have a cljc and a cljs file by the same name. So either these mutations live in the same file or I have to do some namespace translation hackery. At the moment I do the hackery: At the moment I have the files model.cljs and db_model.cljc and translate every incoming mutation by changing net.markusgraf.hhh.address.model/add-address to net.markusgraf.hhh.address.db-model/add-address. This bugs me every few months because it is an ugly hack.

I also do not want to separate them to much because tests access both together to simulate roundtrips.

so since its fulcro I'm assuming that the mutation is still called via its eql stuff, so the UI not actually referencing the mutation, but instead constructing the mutation "list"?

asked differently does the UI code (:require [net.markusgraf.hhh.address.model :as x]) or some kind of other indirect reference instead?

Yes.

problem is that if the UI code requires the mutation code it will end up as part of the UI code, i.e. get pulled out of any worker specific module

if it does not require the mutations. it will remain in the worker

or is the worker a separate build?

At the moment the worker is only a different module. I have been thinking whether it would be better to make it a different build.

I already have the defmutation macro modified to handle server push.

well, if the mutation only ever really "runs" in the worker it is best to just ensure it stays in the worker

I assume fulcro still using this eql mutation stuff

What do you mean by eql mutation stuff?

I did not change much fulcro, just replaced the remote and work without pathom.

The defmutation modifications just add stuff.

I mean a eql list is constructed in the UI code, vs. actually calling the function?

I basically try to work around the inability to have two files with the same namespace to feed to the worker and client.

`(some-alias/add-address ~some-args)

or something like that?

Ah. Yes. I call transact like this yes.

ok, so in theory the UI then does not need to "know" the mutation

Yes

(:require [net.markusgraf.hhh.address.model :as-alias x]) would still allow to write the exact same code

but would not pull the code into the actual UI module and leave it in the worker

assuming the worker somehow requires it normally of course 😛

but honestly, just thinking about all this just makes my head hurt already. it'll be so brittle that IMHO its not worth doing 😛

Yeahhhh. I guess I will habe to keep doing the hack with the namespacetranslation. It is ugly but it works. Thanks a lot!!!! And thank you for shadow-cljs!!!

I might put a macro in there to do it at compile time.

You just gave me another idea. The defmutation macro creates multimethod methods. I could translate the symbol there. Thank you again!!!

btw create a build report, so that you know where your code actually lives. https://shadow-cljs.github.io/docs/UsersGuide.html#build-report

in theory you can query which module a certain namespace is in during compilation. but I strongly advise not doing that since it creates all sorts of issues with caching

The multimethod for ui and db are in seperate namespaces already, the ui being fulcro.mutations/mutate. I can just have the macros unify the symbols they create, like getting rid of an intermediate ui- or db-. Then the it does not matter anymore that the mutations get defined in different namespaces.

I will definitely use the build-report.

It was the coupling of namespace to file on one hand and the coupling of namespace to mutation on the other that I tried to work around.