NumberFormatter architecture is flawed #9061
Labels
answered
For when a question was asked and we referred to forum or answered it.
c: Platform
For Matomo platform changes that aren't impacting any of our APIs but improve the core itself.
Milestone
The current NumberFormatter class is not built into the existing metrics formatting system in core. Instead, it essentially re-formats values, trying to guess the meaning of a value, after the meaning is removed or transformed. This approach is prone to error and adds an unnecessary extra layer of logic.
Instead, the logic in NumberFormatter should be included in the Html MetricsFormatter (if it is only for UI), or included in the MetricsFormatter base. If neither of these work for some reason, a new base class can be used. But the MetricsFormatter base should be the only way to format values for display and no method should try to guess how to format a value. Users should explicitly specify how they want values to be formatted.
This technical debt should be removed before the next major release.
The text was updated successfully, but these errors were encountered: