I did something similar for a database connection component, that could connect to multiple databases at runtime and had to maintain internal state. I didn’t need to make the individual connections components, but this was because the DB driver handles state internally.
In my case I used an atom hidden behind a protocol to keep track of already instantiated connections. Hope this helps. Thanks, Orestis 16 Σεπ 2019, 10:36 μμ, ο χρήστης «Don Jackson <d...@clark-communications.com>» έγραψε: > Hello, > > I'm writing an app/system that subscribes to a number of feeds, the number > and configuration of the feeds is a configurable run-time thing. > Seems like I should have a Feed component, which is passed its config when > instantiated. > But having a named slot in the system for each feed would be painful and > kinda defeats the point of having a variable number of feeds that get > configured. > > How best to deal with this in Component? > > One thought I had was to create a Feeds (note plural, trailing s) component. > The Feeds component would be instantiated with a collection of feed configs, > and would have a single slot to hold the collection of instantiated feeds. > This Feeds component would instantiate a Feed component for each feed, and > could start/stop them in its own start/stop methods. > > I appreciate/understand that my individual Feed components would not be > participating in the System dependency injection, but AFAICT they don't need > to. > > The above seems like it would work fine, but also seems like it is not > idiomatic Component. > > I would welcome any thoughts/advice as to how best to structure this with > Component. > > Thanks > > Don > > > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/0caae21e-b7c0-422f-a157-15c535c84022%40googlegroups.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. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/94223F7B-C095-45C0-B1F0-F35DEDC419B4%40orestis.gr.
