Open danilhendrasr opened 3 years ago
In React Native, the only units available are px
, dp
and %
.
Other units are not allowed. I don't know why rem
works here though. Maybe the author converted all rem
units to px
or dp
somehow.
And for the base lineHeight, you can change it like this: lineHeight: 1.125
. Hope it helps.
In React Native, the only units available are
px
,dp
and%
. Other units are not allowed. I don't know whyrem
works here though. Maybe the author converted allrem
units topx
ordp
somehow. And for the base lineHeight, you can change it like this:lineHeight: 1.125
. Hope it helps.
Yes, rem
is converted to 16px
as part of building the styles.json
file:
This is because the majority of Tailwind code was written using a combination of rem
and then the occasional px
for classes such as border-px
.
The resulting styles are passed to the css-to-react-native library. Values that do not translate (such as the line-heights above) are dropped to avoid a crash in RN.
I wonder if it would make size to do some mapping here for some common sense defaults? i.e., the font sizes for 5xl, 6xl...
are a unitless 1
. Would @vadimdemedes be open to a PR that mapped 1
to the same as the value being used?
i.e., the value for 5xl
gets mapped to 48, the line-height should get mapped to 48 as well
That would work, but we'd want to ensure we're applying this only to line-height
which in Tailwind encourages a mix of unitless values as well as rem
.
If we solve it in the build step: https://github.com/vadimdemedes/tailwind-rn/blob/master/build.js#L17
leading-tight
, leading-snug
, etc which also use unitless values such as 1.25
and 1.375
respectively. Setting a conversion for 1
to current-size means we'll need to disable alternate leading values. This would be a breaking change since someone might be relying on these pre-set values (even if they're wrong)If we solve it at runtime: https://github.com/vadimdemedes/tailwind-rn/blob/master/index.js#L41
{ fontSize: 48, lineHeight: 56}
and suddenly has a 2688dp tall line. This means releasing a new major version w/ breaking change notes.Between the two choices since both would be a major version bump, I'd rather see a runtime fix since we already have an established pattern for this in letter-spacing which also cannot be declared without a font size definition. It's also easier for developers to write codemods, since a declaration with lineHeight and fontSize can recalculate the lineHeight to lineHeight/fontSize
. Would love to have Vadim's thoughts as well
@jakobo Thanks!
Here's how I solved the issue via my tailwind config. I just copied the values from the default theme and noted which values I changed. Note this replaces (rather than extends) the fontSize
for your theme.
// tailwind.config.json
theme: {
extend: {},
fontSize: {
// default values
xs: ['0.75rem', { lineHeight: '1rem' }],
sm: ['0.875rem', { lineHeight: '1.25rem' }],
base: ['1rem', { lineHeight: '1.5rem' }],
lg: ['1.125rem', { lineHeight: '1.75rem' }],
xl: ['1.25rem', { lineHeight: '1.75rem' }],
'2xl': ['1.5rem', { lineHeight: '2rem' }],
'3xl': ['1.875rem', { lineHeight: '2.25rem' }],
'4xl': ['2.25rem', { lineHeight: '2.5rem' }],
// default values except i changed the line height from '1' to whatever the font size is
// https://github.com/vadimdemedes/tailwind-rn/issues/88#issuecomment-979433253
'5xl': ['3rem', { lineHeight: '3rem' }],
'6xl': ['3.75rem', { lineHeight: '3.75rem' }],
'7xl': ['4.5rem', { lineHeight: '4.5rem' }],
'8xl': ['6rem', { lineHeight: '6rem' }],
'9xl': ['8rem', { lineHeight: '8rem' }],
},
},
When customizing font size while also setting the default line height, like this, it seems the library doesn't accept line heights that are written in units other than
rem
.Thus causing the corresponding
text-<size>
key to not show up instyles.json
.Letter spacings are fine though.
I wonder if this is intentional?