The :sc/create-fn is passed configuration of the component, but not its dependencies, that comes later. This can often be a map->Record function in a namespace. Or, it can be a custom application that validates the configuration (I use spec) and then calls map->Record. Component will later assign dependencies and invoke the start method, which is another reasonable place to do validation. . Of course, your rec9rd may not implement Lifecycle, you may not even need a record type. I prefer to avoid records and protocols for my components, wherever possible. I'm fine with the component being a simple map, and doing some destructuring to get at config and dependencies from simple functions passed the component.
On Sat, May 23, 2020 at 5:47 AM Matching Socks <phill.w...@gmail.com> wrote: > Sierra's Component README illustrates factory functions that take a > complete static configuration at once, followed up by injections. But, > really, it's none of Component's concern how you work a Lifecycle thing > into shape for Component to assoc the injections and start it. > > In Schematic, sc/create-fn takes a single map as a parameter, but I didn't > see the README stating what's in the map. It seems to me that Schematic > would be free to include all static configuration (i.e., everything except > other Lifecycle things), or to provide an empty map and assoc the static > elements piecemeal along with other Lifecycle things, or anything in > between. > > The question came to mind because I sometimes wonder where it was intended > that Components validate their configuration. Of course, it hinges on how > the wiring-up is done. If you code it yourself, you can use the factory > function (and refrain from assoc), so the factory function can check > parameters, which is nice because the resulting Exception does not tie up > your Emacs with 100 gigabytes of Component fallout. On the other hand, if > you must code for the general case, you validate stuff only in the start > method. > > What do you recommend? > >> -- > 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/9522140a-a329-41b8-92ed-5a1eececc6c3%40googlegroups.com > <https://groups.google.com/d/msgid/clojure/9522140a-a329-41b8-92ed-5a1eececc6c3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Howard M. Lewis Ship Senior Mobile Developer at Walmart Labs (971) 678-5210 http://lewisship.net <http://howardlewisship.com> @hlship -- 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/CACd-vsPNckMbYfA7nWkxT3DO41ztB-DsRQP-OZTZ2fxoAq1-nw%40mail.gmail.com.
