Open credmond-git opened 7 months ago
We need to figure out what makes sense to be a lifecycle hook and what makes sense to be its existing service. Like a path mapper, we can say it is a lifecycle hook where we mutate the path while getting a node, or we can say it is a path mapper.
Possible life cycles: Decoder Path Mapper Post Processor MetricsRecorders ConfigValidator
Renamed Post Processor to ConfigNodeProcessor and created a ResultProcessor. Both in the Processor package. https://github.com/gestalt-config/gestalt/pull/186 Renamed MetricsRecorder to ObservationRecord. ConfigValidator is now a result processor that allows custom validators.
Currently we have several disparate lifecycle hooks, such as metrics, validation, post processor, path mapper. However, we can rework them all into the concept of a lifecycle hook. Where the post processor is a hook during compiling the config tree. Where metrics are a hook before and after getting a config. Hooks when there are errors as well as Finally validation is a hook after a config has been received but before it is returned.
We can also add in additional hooks for transforming the keys and values as we build the config tree. This could be used to normalize the data instead of the SentenceLexer. Logically there is no change in functionality, but by doing this we expose a more comprehensive system that people can use have greater control over their configuration library. Instead of using the validation system to modify a result, it would be more intuitive to leverage the postConfigLifecycle method.