Since we support 'plural', should we have a test coverage for it as well?

adding.

A caller can specify messages directly on the Meter instance, correct? Should we have test coverage for the instance level?

yes correct a user can add on the Meter directly adding

Was max documented, but not an actual prop?

Are there other props documented but not represented as props here?

yes there are other props documented but not represented here I had pulled out the max so I could use that in the message since that was just being passed in the ...rest

max documentation states "The maximum value for the Meter." Does this imply that if I specify max={10}, then set value={20}, the 20 won't be respected? If not, should the definition of max be clarified?

correct we can clarify our documentation.

so if we have the following:

      <Meter type="bar" max={50} value={60} />

The whole meter will be filled.

This isn't quite the same but probably an improvement.
Previously if the max prop was in rest I think it would override this property. Now you will get memoizedMax if max is specified but falsey (e.g. 0, undefined, null). Maybe that's better? That does assume we can't have negative values (e.g. say a range of values from -10 to 0)?

I think it's little fragile that the rules for what max is are now split into 4 places:

1. deriveMax
2. the message max param
3. Bar max property (does logic)
4. Cirlce max property (does logic)

This is alot of risk for disagreement. Right now if there are multiple values but they are 0 you will get a memoizedMax of 0. The message will say 100 but the Bar and Circle will be passed max=0

memoizedMax will be 100 or if there are at least 2 values it adds them up. That also means if values only contains 1 thing it will return 100 or if there's a value it will return 100.

To avoid this we might want to refactor to normalize max in one spot and pass that one value to the message, Bar and Circle. Maybe something like:

Change the component prop to be max: maxProp and then

const max = useMemo(() => {
  let maxValue = 100;
  if (values?.length > 1) {
    maxValue = values.reduce((total, currentValue) => total + currentValue, 0);
  }
  return maxValue || maxProp || 100;
}, [maxProp, values]);  

And then just use max for the 3 places it's needed (message param, Bar prop and Circle prop).

@MikeKingdom

yes agree there is alot being done here

deriveMax
the message max param
Bar max property (does logic)
Cirlce max property (does logic)

I added the suggestion you provided with a small change.

1. I needed
   maxValue = values.reduce((total, currentValue) => total + currentValue, 0);
   currentValue.value

2. I put the maxProp to be the first in our || statement so its the following
   return maxProp || maxValue || 100;

for example if I have

      <Meter type="bar" max={40} value={30} />

with having maxValue || maxProp || 100
it was taking the maxValue of 100 and not respecting what the user passed in for maxProp

Thanks and good point.

One thing I just realized is the type isn't currently localizable. We should have keys in here for type. Although a bit wordy, I think a more flexible thing for localizers would be:

aw okay good point I can restructure

@MikeKingdom updated structure