This is the first big step towards unified configuration with support
for multi-level defaults and composable configuration values. There are
a couple of things in dry-configurable that made it a bit more difficult
but it's good-enough for now.
The idea is that it should be possible to define runtime defaults for
each component type and then each component can specify its custom
configs too.
Then in case of nested components, certain settings should be composable
too based on arbitrary logic. One example of this that we already have
is the namespace setting - in case of a relation that defines its own
commands, the default value of the commands' namespace is a composition
of every namespace setting from all the component's in the tree:
relation's command default namespace: the id ie "users"
...and so if a users relation defines a "create" command, then its
namespace will be "commands.users" and the command key will be
"commands.users.create".
This is the first big step towards unified configuration with support for multi-level defaults and composable configuration values. There are a couple of things in dry-configurable that made it a bit more difficult but it's good-enough for now.
The idea is that it should be possible to define runtime defaults for each component type and then each component can specify its custom configs too.
Then in case of nested components, certain settings should be composable too based on arbitrary logic. One example of this that we already have is the namespace setting - in case of a relation that defines its own commands, the default value of the commands' namespace is a composition of every namespace setting from all the component's in the tree:
...and so if a users relation defines a "create" command, then its namespace will be "commands.users" and the command key will be "commands.users.create".