Ceph » mgr » Dashboard

As they appear in, for example, src/app/shared/pipes/health-color.pipe.ts.

This has 2 main downsides:

• Component presentation/styling becomes interleaved with component logic, which is a basic coding anti-pattern.
• It results in failing unit-tests, as they explicitly look for literals which need to be explicitly set at both sides.

The above makes hard to use alternative styles (vendor/downstream specific).

Alternatives (from less to more optimal):

• Using enums (as charts do) instead of literals. This enums are shared between code and tests. However, the above approach is still suboptimal (literal colors still apear in the code, while they should all come from SCSS).
• Ideally, components should rely on style classes (e.g: HealthPipe switches from health-ok-color to health-error-color when HEALTH_ERR happens). This approach, however, would not work with some TS components that rely on 3rd parties (chartjs) requiring explicit colors/styles. In this case
• An alternative would be to use CSS classes and make them available to code. Javascript allows for getting computed styles, and this tutorial provides a different approach