untangled

NEW CHANNEL: #fulcro
tony.kay 2016-08-12T00:17:47.000417Z

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.kay 2016-08-12T00:19:11.000418Z

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.kay 2016-08-12T00:20:28.000419Z

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

2016-08-12T15:52:37.000420Z

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

2016-08-12T15:54:12.000421Z

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

grzm 2016-08-12T19:38:59.000422Z

@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))

grzm 2016-08-12T19:39:34.000423Z

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.

grzm 2016-08-12T20:07:08.000424Z

wrong channel. Sorry folks.

2016-08-12T20:10:37.000425Z

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

2016-08-12T20:10:53.000426Z

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

grzm 2016-08-12T20:13:01.000427Z

@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.

grzm 2016-08-12T20:13:50.000428Z

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

grzm 2016-08-12T20:14:40.000429Z

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

grzm 2016-08-12T20:15:17.000430Z

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

2016-08-12T20:29:00.000432Z

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

grzm 2016-08-12T20:29:32.000433Z

@jasonjckn: you're welcome 🙂

2016-08-12T21:18:05.000434Z

@grzm:

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

grzm 2016-08-12T21:18:49.000435Z

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

grzm 2016-08-12T21:19:34.000438Z

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

grzm 2016-08-12T21:20:09.000439Z

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

grzm 2016-08-12T21:20:21.000440Z

as that's the latest stable version

grzm 2016-08-12T21:21:07.000441Z

Yeah, it's private in 0.2.11

grzm 2016-08-12T21:22:29.000446Z

And it's not in 0.3.0-alpha3

2016-08-12T21:24:47.000447Z

perfect, thanks

2016-08-12T21:24:54.000448Z

I was using 0.2

grzm 2016-08-12T21:25:41.000449Z

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.