8000 Add `number` to `fontWeight` union by nezort11 · Pull Request #81 · Faire/mjml-react · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add number to fontWeight union #81

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

nezort11
Copy link

fontWeight can be a number (e.g. 700, 400).

like

<div style={{ fontWeight: 700 }}>Some text</div>

@emmclaughlin
Copy link
Collaborator

Hi @nezort11 ! Thank you for contributing. This is a great find, however we should fix this for all components instead of just for MjmlText. We have a function in the script that tries to determine prop type https://github.com/Faire/mjml-react/blob/main/scripts/generate-mjml-react.ts#L120. The fontWeight is "number" but we don't check for that so it seems we fall back to the line 153 return.

To fix this we should add a line like:

if (mjmlAttributeType === "number") {
 return "string | number"
}

inside of the getPropTypeFromMjmlAttributeType function, and perhaps a test to confirm we can pass a number to the fontWeight prop without a typescript error.

@IanEdington
Copy link
Contributor

It looks like mjml defines font-weight as a string: https://github.com/mjmlio/mjml/blob/85bc58e9e2a88cef7424dc2fce3d889f66fb4298/packages/mjml-text/src/index.js#L18

We typically want to stick with the mjml types but it seems that it's not enforced with their strict validation: https://mjml.io/try-it-live/dKaQw9yEj

Not positive what to do here yet.

IanEdington added a commit that referenced this pull request Feb 2, 2023
In the previous version enum was being pre-empted by CSSProperties. This resulted in some values not passing type checking when using validationLevel: "strict". Fixes #81
@IanEdington IanEdington reopened this Feb 2, 2023
@IanEdington
Copy link
Contributor

oops I referenced the wrong issue in #85. It should have fixed #82

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0