This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-13
Channels
- # beginners (71)
- # boot (61)
- # clara (49)
- # cljs-dev (9)
- # cljsjs (2)
- # cljsrn (5)
- # clojure (55)
- # clojure-android (1)
- # clojure-italy (4)
- # clojure-spec (39)
- # clojure-uk (56)
- # clojurescript (69)
- # cursive (5)
- # data-science (1)
- # defnpodcast (6)
- # devcards (1)
- # duct (12)
- # figwheel (3)
- # fulcro (18)
- # leiningen (35)
- # lumo (19)
- # midje (1)
- # off-topic (22)
- # om (3)
- # onyx (23)
- # portkey (3)
- # re-frame (20)
- # reagent (23)
- # ring-swagger (6)
- # shadow-cljs (119)
- # specter (7)
- # unrepl (25)
@rickmoynihan I was thinking that profiles would contain partial configurations that would be optionally merged into the top-level config.
So you might have a configuration like:
{:profile/foo {:app/foo 1}
:app/bar 2}
And if the profile key was activated, you’d get:
{:profile/foo {:app/foo 1}
:app/foo 1
:app/bar 2}
This would mean we could get rid of :duct.core/include
, and replace it instead with a reader tag. So instead of:
{:duct.core/include "foo"}
We might write:
{:profile/foo #duct/include "foo"}
A reader tag would be more flexible, because it can be used to inject configuration inside a key:
{:app/secrets {:encrypt-key #duct/include "app/encrypt-key"}}
Makes sense, so you can basically #duct/include
at any depth.
It also pushes side-effectful behaviour out of the prep
stage. The configuration and its includes are read at once, and that’s the end of the configuration I/O.
It means we can get rid of a key that’s specially treated (`:duct.core/include`)
And it means that configuration keys can be more easily grouped together.
It lends itself to some interesting functionality when combined with inheritance. For instance, we might imagine a profile key that is included by default, like :duct.profile/default
. We could then use a composite key like:
{[:duct.profile/default :app/migrations] #duct/include "app/migrations"}
So this is a profile that’s always included by default.
We could redo modules in a similar way; instead of modules updating the whole configuration, they return a profile that’s merged in. I’m not sure if this would be too restrictive or not.
not sure…