Re: Managing State Changes, using Component

I can see this being the case. Nominally, my component looks like this. Before I log a bug however, let's see first, if anyone is seeing this behaviour. (ns a (:require [com.stuartsierra.component :as component] [taoensso.timbre :as timbre])) (defrecord A [env] component/Lif

Re: Managing State Changes, using Component

If you only created the atom once, the value of the atom would be the same no matter where you dereferenced it. If you're seeing two different atoms, then the code that created the atom must have been executed more than once. Without seeing your code it's impossible to know for sure how that occur

Re: Managing State Changes, using Component

Sorry, just reading this now. I've pivoted on that project, and that code is no longer around. We were going to store analytics data in that atom, but instead are going to do JVM and other kinds of profiling. But if you look at my first message, component *:a* would have had the atom. The *:updat

Re: Managing State Changes, using Component

Actually, now that I think about it, that's not right. It shouldn't matter where or when you create the Atom. Instead, what I suspect you have is two or more instances of the component containing the Atom, thus two different Atoms. You can tell if the Atoms are the same object by printing them

Re: Managing State Changes, using Component

Ahh, so that was it then. Yeah, I definitely created that atom in the start method. Thanks very much. Tim Washington Interruptsoftware.com On Mon, May 5, 2014 at 3:27 PM, Stuart Sierra wrote: > At what point did you **create** the Atom in :a? Any mutable referen

Re: Managing State Changes, using Component

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

Re: Managing State Changes, using Component

Responses inlined ... On Mon, May 5, 2014 at 12:35 AM, Atamert Ölçgen wrote: > > Hello Timothy, > > > On Sat, May 3, 2014 at 8:49 PM, Timothy Washington wrote: > >> >> Also, have you tried confirming that only one :a is instantiated? >>> >> >> That one *:a* is not the same instance throughout

Re: Managing State Changes, using Component

Hello Timothy, On Sat, May 3, 2014 at 8:49 PM, Timothy Washington wrote: > > Also, have you tried confirming that only one :a is instantiated? >> > > That one *:a* is not the same instance throughout all the dependant > components. Seems that it's the [*:core :a*] bit that's passed to all the >

Re: Managing State Changes, using Component

Hey, thanks for responding. My responses are inlined. On Thu, May 1, 2014 at 1:34 AM, Atamert Ölçgen wrote: > I am not an expert on Component. But AFAIK it is not for managing mutable > state but for assembling and configuring components, that might or might > not be mutable themselves, in an i

Re: Managing State Changes, using Component

I am not an expert on Component. But AFAIK it is not for managing mutable state but for assembling and configuring components, that might or might not be mutable themselves, in an immutable fashion. However from what I can understand, your component-a has an atom, like: (->component-a (atom s

Managing State Changes, using Component

Hi all, I'm having a weird state problem with 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 th