Fork me on GitHub
#untangled
<
2016-08-12
>
tony.kay00:08:47

I'd be interested in exploring it further. Doing multiple transacts at once is probably not encouraged (since they should compose into one)...but I fail to understand what the exact problem might be that causes the error

tony.kay00:08:11

The intention is to have mutations that need to load data do the process described (load-data-action)...that is why I wrote it: so you could compose loads with other mutations within the mutation. that said, you should be able to add the load-data mutation into your transact (transact! this '[(f) (untangled/load-data ...)]

tony.kay00:08:28

Still, I wonder if there is a bug when multiple transacts are called at once

ethangracer15:08:37

I kind of like putting untangled/load-data directly in the transact rather than writing a new transaction for each load

ethangracer15:08:12

should be easy enough to write a simple om app that runs multiple transactions in the same function call. i’ll ask on #C06DT2YSY

grzm19:08:59

@robert-stuttaford: Here's my fix:

(defn refresh-dirs
  "Remove `resource` path from refresh-dirs"
  ([] (refresh-dirs repl/refresh-dirs))
  ([dirs]
   (let [resources-path (-> "public" resource .getPath File. .getParent)
         exclusions #{resources-path}
         ds (or (seq dirs) (cp/classpath-directories))]
     (remove #(contains? exclusions (.getPath %)) ds))))

(defn reset
  "Destroys, initializes, and starts the current development system"
  []
  (stop)
  (apply repl/set-refresh-dirs (refresh-dirs))
  (repl/refresh :after 'user/go))

grzm19:08:34

Getting the path to the resource directory feels a bit hacky (what if I have multiple resource paths?) but that's a problem to solve another day.

grzm20:08:08

wrong channel. Sorry folks.

jasonjckn20:08:37

what's the refresh-dirs do? is that for hot loading server side code on file save

jasonjckn20:08:53

i took it out a long time ago and haven't noticed any issues

grzm20:08:01

@jasonjckn: I'm using the Reloaded workflow on the backend, and both the client and backend code is in the same project. By default, clojure.tools.namespace.repl/refresh includes the resource directory in the classpath. When Figwheel compiles files, it copies cljc files into the resource directory. When repl/refresh then loads these files as well, and they were stomping on my backend code.

grzm20:08:50

That refresh-dirs function I wrote returns the refresh-dirs sans resource

grzm20:08:40

That repl/set-refresh-dirs then sets the repl/refresh-dirs Var that repl/refresh looks at. And it solved my problem.

grzm20:08:17

Here was a test-case that I wrote up that displays the problem I was having: https://github.com/grzm/bad-om-transit

jasonjckn20:08:00

@grzm: thanks for the explanation, maybe I have hit this issue actually, so i'll try your fix out

grzm20:08:32

@jasonjckn: you're welcome 🙂

jasonjckn21:08:05

@grzm:

Caused by: java.lang.IllegalStateException: var: repl/refresh-dirs is not public, compiling:(user.clj:34:7)

grzm21:08:49

@jasonjckn: Interesting. How are you including tools.namespace.repl?

grzm21:08:34

I'm using [org.clojure/tools.namespace "0.3.0-alpha3"]

grzm21:08:09

which looks like I should be using [org.clojure/tools.namespace "0.2.11"]

grzm21:08:21

as that's the latest stable version

grzm21:08:07

Yeah, it's private in 0.2.11

grzm21:08:29

And it's not in 0.3.0-alpha3

jasonjckn21:08:47

perfect, thanks

jasonjckn21:08:54

I was using 0.2

grzm21:08:41

Referencing repl/refresh-dirs is just a nicety though. If you know that your refresh-dirs is empty and that its going to default to the classpath anyway, you can just bang on it directly.