Filip Sarens (1) [Avatar] Offline
In chapter 4.5.1, listing 4.3 - 4.5
Without starting an academic discussion...
Wouldn't it be better/more encapsulated to pass a Metric object iso the 4 inputs described?
IMHO The metric component would like to have control over how/what the title should be.
The metric object provided should have a subject (MEM, CPU ...), used and available attributes. The Metric template can then decide to use the subject and/or description without breaking the contract/coupling.

Additionally his allows for more flexible configuration later on as we could pass in for example separate thresholds for mem and cpu without the need to change both the metric and dashboard templates and definitions.
jeremy.wilken (191) [Avatar] Offline
That is certainly an option, and something I would suggest if you got too many inputs. This design works well for the time being, because the known use cases are similar. If you are adding new inputs, you don't break the contract you just extend it so that is another option. Adding options to an object passed via the single input still requires adding that new property, so its not practically very different other than where the option exists.

The biggest problem with passing one object with configuration means that you're defining that all in your controller or data model. This might not be an issue in some cases, but imagine you're getting data back from an API that doesn't have all of the labels. You'd have to write logic to extend the data model to have those additional properties, which isn't a big deal but is a design decision. If you can have the API send back the data you need, that is ideal, but often that isn't possible. I have found it better to limit the modification of your data objects as much as possible, but your millage may vary.