You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We are attempting to use a templated value as a background color (in this case a handlebars-like string). However, when building our emails, we get an error from mjml: Attribute background-color has invalid value: <value> for type Color. This happens because the Color type in mjml has a list of matchers that looks for "real" color values such as a hex value or rgb value. For our use case, the built email will work just fine since there's additional processing that happens to render the actual email that is sent out.
Describe the solution you'd like
Ideally we could configure the Color type (and maybe any type) matchers to accommodate our use case. This way developers still get the default type checking while accommodating uses cases where the values are not known at build time.
Describe alternatives you've considered
Alternatives would be to build a mechanism that disables type checking either globally for a specific type, like Color, or on a per component basis.
The text was updated successfully, but these errors were encountered:
I know about this but I didnt found any solution. Maybe it could be handled
in mjmlconfig if we provide somekind of a `.js` version with a filter
function. Feel free to open a PR if you want
Is your feature request related to a problem? Please describe.
We are attempting to use a templated value as a background color (in this case a handlebars-like string). However, when building our emails, we get an error from mjml:
Attribute background-color has invalid value: <value> for type Color
. This happens because the Color type in mjml has a list of matchers that looks for "real" color values such as a hex value or rgb value. For our use case, the built email will work just fine since there's additional processing that happens to render the actual email that is sent out.Describe the solution you'd like
Ideally we could configure the Color type (and maybe any type) matchers to accommodate our use case. This way developers still get the default type checking while accommodating uses cases where the values are not known at build time.
Describe alternatives you've considered
Alternatives would be to build a mechanism that disables type checking either globally for a specific type, like Color, or on a per component basis.
The text was updated successfully, but these errors were encountered: