-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using Mountup to track ns recompilation #5
Comments
unfortunately I have not used pathom hence I do not have an understanding of what a resolver in this context is ) is it a multimethod? a macro? a function? is it also a state? does it make sense to have a single state that has a map of these resolvers? what is a pathom state and where is it kept?
mount does track that and restarts everything in a namespace that was recompiled. if all your resolvers need to be started and stopped along with pathom state would it not make sense to have start and stop functions of pathom state to do that? again, this is just with no understanding what the resolver or phatom state/is. |
Hi @tolitius, Sorry I wrote that in a bit of a rush and it's my fault for being super unclear. I did not mean to imply that you should know anything about Let me try again. I have two namespaces: (ns myapp.resolvers
(:require [mount.core :refer [defstate]]))
(defstate resolvers
:start [request-resolver]) pathom (ns myapp.pathom
(:require [mount.core :refer [defstate]]
[com.wsscode.pathom.core :as p]
[myapp.resolvers :as r])) ;; <-- Importing the namespace
(defn build-parser []
(p/parser {:resolvers r/resolvers ...}))
(defstate parser
:start (build-parser)) As you can see From your answer it appears that I need to tell |
how are (defn build-parser []
(let [resolvers ;; build resolvers here]
(p/parser {:resolvers resolvers ...})))
(defstate parser
:start (build-parser)) would work without keeping a separate "resolvers" state.
But usually, from seeing this uncertainties I tend to search for a slight "redesign", not to avoid the problem, but simply to not have it in the first place. |
Before I started this, I was just putting Hence my wanting to have the An alternative redesign would be nice, but I'm not sure how to proceed due to the aforementioned compiling that occurs, but placing them in the same namespace might get a bit unwieldy =)... |
it does not have to occur if you don't want
is the parser only needed to compile this resolvers for performace? i.e. can you include / build the parser in the (defn build-resolvers [...]
;; build resolvers
;; build parser
{:parser parser
:resolvers resolvers})
(defstate resolvers :start (builld-resolvers)
:stop :stopped) |
I'm being unclear =)... I'm aware that you can noop or stop mount defstate reload, it's a great feature =)... The parser function is designed to compile the resolver state whenever it's defined, so altering the resolver definitions doesn't update their behaviour, only redefining the parser does that. I can and do include the resolver state in the parser definition, however my problem is that when the namespace containing a resolver is reloaded, my parser After doing some further digging it seems this has been asked before, similar to that example I want to set it up so that whenever I reload a namespace containing a resolver, my parser function is restarted. I'd prefer to do this without having to add another dependency if at all possible =)... Is there some way to tell mount to watch certain namespaces so that if they are reloaded, a particular It appears mount does construct some kind of dependency tree? (require '[mount.tools.graph :as graph])
(graph/states-with-deps) Hence my asking if I should define all the different resolver functions as defstates, as that would trigger some kind of reload? An alternative potentially really messy solution where I do this by hand might be: (ns myapp.resolvers
(:require [mount.core :refer [defstate]]))
(defn build-resolvers [resolvers]
(mount/stop '#myapp.pathom/parser)
(mount/start '#myapp.pathom/parser)
resolvers)
(defstate resolvers
:start (build-resolvers [request-resolver])) pathom (ns myapp.pathom
(:require [mount.core :refer [defstate]]
[com.wsscode.pathom.core :as p]
[myapp.resolvers :as r]))
(defn build-parser []
(p/parser {:resolvers r/resolvers ...}))
(defstate parser
:start (build-parser)) Now if I reload the I'd prefer if I didn't have to define lots of defstates, but I'm just asking if this is the only way to do this? And thank you for all your help =)... |
two more questions ) (defstate resolvers :start [request-resolver])
For example in case you create resolvers inside a let block when building a parser: (ns parser)
(defn build-parser []
(let [resolvers ;; build resolvers here]
(p/parser {:resolvers resolvers ...})))
(defstate parser
:start (build-parser)) other namespaces may then require parser and get to resolvers: (ns other-namespace
(:require [parser :as p]))
(defn i-take-parser [{:keys [resolvers]}]
(let [{:keys [request]} resolvers]
;; ...))
(defn i-am-ok-close-over-parser-state []
(let [{:keys [request]} (-> p :resolvers :request)]
;; ...)) |
Hi @tolitius, sorry I haven't responded up until now, been a bit busy 😊... To answer your questions:
I mean I could rewrite it all into a function call if that would make it better? Is that what you mean? As it stands it was just a A resolver itself is created by a macro provided by the library called (ns user)
;; Potentially many of these
(defresolver i-resolve-all-users [params]
;;...)
(defresolver i-resolve-active-users [params]
;;...)
(def resolvers [i-resolve-all-users i-resolve-active-users])
Let me rewrite my thing into your example, so hopefully it will be clearer =)... (ns parser
(:require [session]
[user]
[other-business-objects]))
(defn build-parser []
(let [resolvers [session/resolvers user/resolvers other-business-objects/resolvers]] ;; <-- It's this bit that's complicated
(p/parser {:resolvers resolvers ...})))
(defstate parser
:start (build-parser)) (ns session)
(defresolver i-resolve-all-sessions [params]
;;...)
(def resolvers [i-resolve-all-sessions]) ;; <-- should this be a `defstate`? (ns user)
(defresolver i-resolve-all-users [params]
;;...)
(def resolvers [i-resolve-all-users]) ;; <-- should this be a `defstate`? Now hopefully you see the issue? When I reload Perhaps the best that can be done is the (defn build-resolvers [resolvers]
(mount/stop '#parser/parser)
(mount/start '#parser/parser)
resolvers) (ns user
(:require [utils :refer [build-resolvers]]))
(defn i-resolve-users [params]
;;...)
(defstate resolvers
:start (build-resolvers [i-resolve-users])) |
Hey, thanks for mount =)...
I'm trying to work out if you can/should use mountup to track dependent ns recompilations to trigger a restart?
For example, I'm currently using it with pathom, which defines
resolvers
.The problem I have is that I want my
pathom
state to be restarted when I reload any of my resolver namespaces.Is the way that I'd achieve this with mountup?
One possible way I was thinking of doing it would be to define my all of my resolver vars in the form of a
defstate
and then usemountup
to watch them and reloadmount
?Is there a better way? Or perhaps this is inadvisable?
The text was updated successfully, but these errors were encountered: