Can't we use the Metric class from the CloudWatch module instead of all these separate props here?

@skinny85
I thought it too. But if using Metric class, we will not be able to use substitution templates.
So I think it is better that we provide fromMetric() method.

Interesting... what's the problem that prevents using Metric with substitution templates?

@skinny85
I had envisioned using Metric class as following.

const metric = new cloudwatch.Metric({
  namespace: 'test-namespace',
  metricName: 'test-name',
  unit: cloudwatch.Unit.COUNT,
});
new CloudWatchPutMetricAction(metric, {
  metricValue: '${temperature}',
  metricTimestamp: '${timestamp}',
});

In above case, I predicted that users might think "I cannot use substitution templates in namespace, metricName and unit".

Hmmm🤔. As I was writing this, I realized that there was nothing preventing from using substitution templates in properties besides unit as following.

const metric = new cloudwatch.Metric({
  namespace: '${namespace}',
  metricName: '${topic(2)}',
});

I'm a little uncomfortable with it, in that substitution templates are written in Metric class props. How about?

And unit cannot be used with substitution templates because unit is enum in Metric.

How common it is to use a dynamic Unit, do you think?

We can work around it by having something like:

new CloudWatchPutMetricAction(metric, {
  dynamicUnit: `${sth}`,
});

It is a little bit awkward, I agree.

I think it's a pretty rare case that a unit is used dynamically.

For just one thing, How about this?
We keep current props, and we provide metric() method like metric-filter.ts.
Because, in many case, CloudWatchPutMetricAction will generate new custom metric for example temperature, weight and moisture. And alerms will be created with this metrics.
So I think users maybe will want metric after they make the topic rules.

OK, sounds good.

Use the Metric.grantPutMetricData() method instead.

cool!