Ahh, so that was it then. Yeah, I definitely created that atom in the start method.
Thanks very much. Tim Washington Interruptsoftware.com <http://interruptsoftware.com> On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra <the.stuart.sie...@gmail.com>wrote: > At what point did you **create** the Atom in :a? Any mutable references > which need to be shared among all usages of a component must be created in > the **constructor**, not the `start` or `stop` methods. > > -S > > > > On Wednesday, April 30, 2014 5:13:15 PM UTC-4, frye wrote: >> >> Hi all, >> >> I'm having a weird state problem with >> Component<https://github.com/stuartsierra/component>. >> Let's say I have a system component, like in fig.1. Starting / stopping and >> loading state is fine. >> However, let's say I have 2 other components (:updater , :reader) that >> use component :a. This is the problem that occurs. >> >> 1. When *:updater*, modifies an atom in *:a*, that change appears in >> path [*:core :a*], not path [*:updater :a*] or [*:a*]. >> 2. Because of the abouve, when *:reader* goes to it's local path [ >> *:reader :a*] to read that change, it doesn't see those >> modifications. >> 3. Using this scheme, *:a* is duplicated 4 times, in the system map. >> However, the modifications only appear in path [*:core :a*]. Thus >> :reader is unable to access it (it's local [*:a*] is unchanged). >> >> >> (def system-components [:a :updater :reader]) >> >> (defrecord Core [env] component/Lifecycle >> (start [this] ...) >> (stop [this] ...)) >> >> (defn component-core [env] >> >> (component/system-map >> :a (component/using >> (ca/component-a env) >> {}) >> :updater (component/using >> (cs/component-updater env) >> {:a :a}) >> :reader(component/using >> (cs/component-reader env) >> {:a :a}) >> :core (component/using >> (map->Foobar {:env env}) >> {:a :a >> >> :updater :updater >> >> :reader :reader }))) >> >> *fig.1 * >> >> >> I was hoping to use Component to manage all internal application state. >> But maybe it's not designed for this use case (state changes between >> components). I imagine that immutability is preventing all those duplicates >> from seeing the modifications. However, in this case I do need an update to >> :a in one component, to be accessed by another component. >> >> Any suggestions on patterns here? I'm also looking at >> component/update-system<https://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj#L116>. >> But again, I don't have access to the core *system* var, from within my >> components. >> >> >> Any insights appreciated >> >> Tim Washington >> Interruptsoftware.com <http://interruptsoftware.com> >> >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
