Fork me on GitHub

I thought the parser was a pure function, but apparently not. And yes I removed everything else to the point the function actually doesnt do anything with the delta except for running the parser and throwing away the result. Still in the form my changes get reset (I typ something in a text field and on save it gets undo but the change is there on reload). If I remove running the query with the parser everything works as expected. The parser has some plugins from the rad libary, I assume that something I don't understand happens there.

Jakub Holý (HolyJak)09:04:03

#pathom might help. How does the response sent from server differ in the two cases?

Jakub Holý (HolyJak)10:04:27

Perhaps you could fotek the RAD demo and make a minimal reproduction case?


How could the Pathom parser ever be a pure function? It runs mutations!


So, I’m not sure exactly what you’re trying to do, but if you change things in the db and want to see them, you MUST update the database atoms that track the current database value. This is for ACID consistency across queries (you never want a resolver to get a NEW value for a database, since that could make for a parse result that is inconsisten!) Thus, IF you modify something AND return something, you MUST update the database atom(s) that the generated resolvers use. These atoms are created on ENTRY into the request middleware, but you must call a function to updated them on env if you’ve changed someething and are returning something that could be further resolved.


Actually, if you use save-form with the Datomic plugin it does this for you…but if you hand-write a mutation you need to manually do it


Is that in the book??? 😊


it’s in the pathom-plugin docstring for sure:

(defn pathom-plugin
  "A pathom 2 plugin that adds the necessary Datomic connections and databases to the pathom env for
  a given request. Requires a database-mapper, which is a
  `(fn [pathom-env] {schema-name connection})` for a given request.

  See `wrap-env` for Pathom 3.

  The `connection->db` argument is the proper Datomic API `d/db` function (client or on-prem).

  The resulting pathom-env available to all resolvers will then have:

  - `do/connections`: The result of database-mapper
  - `do/databases`: A map from schema name to atoms holding a database. The atom is present so that
  a mutation that modifies the database can choose to update the snapshot of the db being used for the remaining

  This plugin should run before (be listed after) most other plugins in the plugin chain since
  it adds connection details to the parsing env.


There really should be a helper function for Datomic plugin that looks like this:

(defn refresh-current-dbs!
  "Updates the database atoms in the given pathom env. This should be called after any mutation, since a mutation
   can have a mutation join for returning data."
  (doseq [k (keys (get env do/connections))
          :let [conn    (get-in env [do/connections k])
                db-atom (get-in env [do/databases k])]]
    (reset! db-atom (d/db conn))))


Release in v 1.1.0 of plugin fulcro-rad-datomic


What I'm trying to do is to modify the save-form delta. That modification needs information from my database, that I access with a pathom query using the parser. So I don't have any other custom mutation, everything goes over the save-form delta which I try to modify on the server. Does that make sense?


Running the query (even without changing the delta) changes the response to the client and resets the changes in the browser form. After a reload these changes are visible again


Save middleware is what you use to modify the Delta. Always.


yea thats what im doing. and within the rewrite-delta call I query data with the parser


I'm trying to get myself off the ground with fulcro by following the Getting Started part of the developer guide. I've copied all the files and I'm running the build command for the first time (

npx shadow-cljs server
I get the following error:
shadow-cljs - config: /home/mark/projects/codex/shadow-cljs.edn
shadow-cljs - starting via "clojure"
Downloading: org/clojure/clojurescript/1.11.4/clojurescript-1.11.4.pom from central
Downloading: org/clojure/clojurescript/1.11.4/clojurescript-1.11.4.jar from central
[2022-04-03 09:39:35.302 - WARNING] :shadow.cljs.devtools.server/nrepl-ex
Note: The following stack trace applies to the reader or compiler, your code was not executed.
CompilerException Syntax error compiling at (cider/piggieback.clj:1:1). #:clojure.error{:phase :compile-syntax-check, :line 1, :column 1, :source "cider/piggieback.clj"}
	clojure.lang.Compiler.load (
	clojure.lang.RT.loadResourceScript (
	clojure.lang.RT.loadResourceScript (
	clojure.lang.RT.load (
	clojure.lang.RT.load (
	clojure.core/load/fn--6856 (core.clj:6115)
	clojure.core/load (core.clj:6114)
	clojure.core/load (core.clj:6098)
	clojure.core/load-one (core.clj:5897)
	clojure.core/load-one (core.clj:5892)
	clojure.core/load-lib/fn--6796 (core.clj:5937)
	clojure.core/load-lib (core.clj:5936)
Caused by:
FileNotFoundException Could not locate nrepl/middleware/print__init.class, nrepl/middleware/print.clj or nrepl/middleware/print.cljc on classpath.
	clojure.lang.RT.load (
	clojure.lang.RT.load (
	clojure.core/load/fn--6856 (core.clj:6115)
	clojure.core/load (core.clj:6114)
	clojure.core/load (core.clj:6098)
	clojure.core/load-one (core.clj:5897)
	clojure.core/load-one (core.clj:5892)
	clojure.core/load-lib/fn--6796 (core.clj:5937)
	clojure.core/load-lib (core.clj:5936)
	clojure.core/load-lib (core.clj:5917)
	clojure.core/apply (core.clj:669)
	clojure.core/load-libs (core.clj:5974)
shadow-cljs - HTTP server available at 
shadow-cljs - server version: 2.17.8 running at 
Does anyone know where this might come from?


that is a dependency version conflict. likely using an outdated nrepl dependency.


Thanks @thheller. This is sort of confusing to me, I thought I'd updated all the dependencies to the latest versions in the deps.edn file:

{:paths   ["src/main" "resources"]
 :deps    {org.clojure/clojure    {:mvn/version "1.10.3"}
           com.fulcrologic/fulcro {:mvn/version "3.5.15"}}

 :aliases {:dev {:extra-paths ["src/dev"]
                 :extra-deps  {org.clojure/clojurescript   {:mvn/version "1.11.4"}
                               thheller/shadow-cljs        {:mvn/version "2.17.8"}
                               cider/cider-nrepl           {:mvn/version "0.28.3"}}}}}
So deps versions should be fine...?


Or maybe I'm missing something about how the deps work. 😞


looks fine in theory. make sure you are actually getting all the dependencies you think you are getting though


clj -A:dev -Stree or however that works


clj -A:dev doesn't throw the error. It's only when I use the shadow command that I get the error.


clj -A:dev doesn't start the nrepl server, so it doesn't do anything other than launching an empty REPL


in that you can do (require '[shadow.cljs.devtools.server :as srv])


then (srv/start!)


Yeah, OK. That makes sense. I get the same error on (srv/start!) 👍


Not sure if I'm reading the -Stree output right. Mostly looks OK, but there are multiple version of clojurescript. What does the X vs . mean?


X nrepl/nrepl 0.9.0 :use-top means it didn't use that version and instead used the other


so its using the ancient nrepl/nrepl 0.5.3 instead for some reason


there are also a whole bunch of other dependencies not listed in your deps.edn, no clue where they are coming from


Ah, fab. Awesome. I had no idea that I had a ~/.clojure/deps.edn on this machine. Deleting that made it work. 🥳

👍 1

That was pretty confusing. Thanks so much @thheller!


now you know why you should never have that file 😉


Yeah, that really does confuse things. It would be much better to have a way to have per-project user overrrides (that don't need to live in version control). Maybe there is a way to do that which I don't know about.


Having a global deps.edn file does seem like a pretty dangerous idea.

Jakub Holý (HolyJak)09:04:23

Well deps is fine as long as you don't put any drops there, only inside aliases