This replaces class-level config values with a new settings API powered by dry-configurable. All components have explicit settings defined now and there's a backward-compatibility shim added to rom/compat which makes sure that old-way of configuring classes through class attributes still works.
Here's how the default Relation settings look like:
There's actually a very strict convention behind this grouping:
top-level settings are used by a component instance, ie in this case relation objects rely on things like auto_struct at runtime to know how mappers should be inferred
settings nested under component root key are used by configuration when establishing connections to gateways, figuring out which plugins should be enabled but first-and-foremost - IF a given component should become registered and what its :id should be. ie with component.id set to ":users" a relation will be available as rom.relations[:users] but also rom["relations.users"]
settings nested under a key that corresponds to a component type, schema in this example, are defaults that will be used when a given component defines its subcomponents. ie a relation can define its schema, so whatever you set here, will end up as defaults for that schema
On top of this, both class definitions and DSL usage is expected to work consistently when it comes to handling configuration settings and DSL options are now automatically translated to component configs.
For example, defining a component class vs defining a component via DSL ends up with the exact same config:
This replaces class-level config values with a new settings API powered by dry-configurable. All components have explicit settings defined now and there's a backward-compatibility shim added to
rom/compat
which makes sure that old-way of configuring classes through class attributes still works.Here's how the default
Relation
settings look like:There's actually a very strict convention behind this grouping:
auto_struct
at runtime to know how mappers should be inferredcomponent
root key are used by configuration when establishing connections to gateways, figuring out which plugins should be enabled but first-and-foremost - IF a given component should become registered and what its:id
should be. ie withcomponent.id
set to ":users" a relation will be available asrom.relations[:users]
but alsorom["relations.users"]
schema
in this example, are defaults that will be used when a given component defines its subcomponents. ie a relation can define its schema, so whatever you set here, will end up as defaults for that schemaOn top of this, both class definitions and DSL usage is expected to work consistently when it comes to handling configuration settings and DSL options are now automatically translated to component configs.
For example, defining a component class vs defining a component via DSL ends up with the exact same config: