evergreen-typography outline
See original GitHub issueThe evergreen-typography
is a package exporting React components and text styles. I am not sure yet about some of the API design. Any input is appreciated.
Usage
import {
Text, // Primitive
Paragraph,
Heading,
Code,
Pre,
Label,
Small,
Strong
} from 'evergreen-typography'
Text component primitive
The <Text />
component is the primitive for all other text components.
It should implement a Box from ui-box
.
Working example
import React from 'react'
import ReactDOM from 'react-dom'
import { Text } from 'evergreen-typography'
ReactDOM.render(<Text size={400} />, document.getElementById('root'))
The size
prop
The Text component has a size
prop that uses city blocks naming convention:
100, 200, 300, 400, 500, 600, 700, 800, 900
.
The default size is 500
for a Text component.
Text implementation
I am thinking something like the following.
import React from 'react'
import PropTypes from 'prop-types'
import Box from 'ui-box'
import TextStyles from './text-styles'
const Text = ({ size, ...props }) => {
return <Box {...TextStyles.get(size)} {...props} />
}
Text.defaultProps = {
is: 'p' // not sure if this should be a `p` or a `span`
}
export default Text
Potential API’s
For the most part I don’t you should have to configure Text outside of properties already supported by Box. The following come to mind:
<Text textAlign='center' color='white' />
Dedicated API for color options
This begs the question if text styles should be implemented with a color. It might be nice to have somewhat of a dedicated API for color. Here are some options I am thinking of:
<Text muted />
<Text color='muted' />
<Text color={TextColors.muted} />
<MutedText />
<Text muted />
option
This is the implementation used inside of the React UI Library (current internal Segment UI framework).
- Short and clean
- Allows a value to be passed
- Pain to cancel out
- Priority conflicts when used with color
<Text muted={null} />
<Text color='muted' />
option
This option might be powerful to use as a standard across components. I have experienced that key/value props end up the most easiest to understand.
- This API also allows easy composition
- Still compact API
- Minimizes naming conflicts
- Prevents priority conflicts when used with color
const TextColors = {
dark: '',
default: '',
muted: '',
extraMuted: '',
}
const Text = ({ color, ...props }) => {
return <Box {...props} color={TextColors[color] || color} />
}
<Text color={TextColors.muted} />
option
This options is to most powerful but also the most verbose.
- Most powerful and understandable
- More verbose
- More to import
<MutedText />
option
- Most powerful and understandable
- Limited composability
- More to import
Text based components
The following components can be fairly simply implemented on top of Text.
Paragraph, // => increases line height
Heading, // => increased font weight
Code, // => different font
Pre, // => styles added
Label, // => more semantic (I don't think different styling)
Small, // => decreased size
Strong // => sets font weight
Some might not be as useful, but it doesn’t break anything either. I have experienced some engineers prefer this instead.
Potentially split up in two packages
It might be beneficial to split up the React components from the actual type styles.
This would potentially mean another package: evergreen-type-styles
. This might is useful in the case of using react-sketchapp
, or CSS generation tools.
What I have in Sketch so far
The text styles I have in Sketch so far are. Although I don’t think we need to be that explicit up front. I generated this today and don’t think we should mirror this API.
Text
Muted Text
White Text
Heading
Muted Heading
White Heading
Text styles we should use
Still unsure if we should base everything from one set of text styles. But in my react-sketchapp generator I am using the following two objects:
heading-styles.js
const fontFamily = 'SF UI Text'
export default {
h800: {
fontFamily,
fontSize: '29px',
fontWeight: 500,
lineHeight: '32px',
letterSpacing: '-0.2px',
color: '#1f4160',
},
h700: {
fontFamily,
fontSize: '28px',
fontWeight: 500,
lineHeight: '28px',
letterSpacing: '-0.2px',
color: '#1f4160',
},
h600: {
fontFamily,
fontSize: '20px',
fontWeight: 500,
lineHeight: '24px',
letterSpacing: '-0.05px',
color: '#1f4160',
},
h500: {
fontFamily,
fontSize: '16px',
fontWeight: 500,
lineHeight: '20px',
letterSpacing: '-0.05px',
color: '#1f4160',
},
h400: {
fontFamily,
fontSize: '14px',
fontWeight: 600,
lineHeight: '20px',
letterSpacing: '-0.05px',
color: '#1f4160',
},
h300: {
fontFamily,
fontSize: '12px',
fontWeight: 600,
lineHeight: '16px',
letterSpacing: '0',
color: '#1f4160',
},
h200: {
fontFamily,
fontSize: '11px',
fontWeight: 600,
lineHeight: '16px',
letterSpacing: '0.3px',
color: '#1f4160',
textTransform: 'uppercase',
},
h100: {
fontFamily,
fontSize: '11px',
fontWeight: 500,
lineHeight: '16px',
letterSpacing: '0.3px',
color: '#1f4160',
textTransform: 'uppercase',
},
}
text-styles.js
const fontFamily = 'SF UI Text'
export default {
t800: {
fontFamily,
fontSize: '29px',
fontWeight: 400,
lineHeight: '32px',
letterSpacing: '-0.2px',
},
t700: {
fontFamily,
fontSize: '28px',
fontWeight: 400,
lineHeight: '28px',
letterSpacing: '-0.2px',
},
t600: {
fontFamily,
fontSize: '20px',
fontWeight: 400,
lineHeight: '24px',
letterSpacing: '-0.05px',
},
t500: {
fontFamily,
fontSize: '16px',
fontWeight: 400,
lineHeight: '20px',
letterSpacing: '-0.05px',
color: '#1f4160',
},
t400: {
fontFamily,
fontSize: '14px',
fontWeight: 400,
lineHeight: '20px',
letterSpacing: '-0.05px',
},
t300: {
fontFamily,
fontSize: '12px',
fontWeight: 400,
lineHeight: '16px',
letterSpacing: '0',
color: '#1f4160',
},
t200: {
fontFamily,
fontSize: '11px',
fontWeight: 400,
lineHeight: '16px',
letterSpacing: '0.3px',
textTransform: 'uppercase',
},
t100: {
fontFamily,
fontSize: '11px',
fontWeight: 300,
lineHeight: '16px',
letterSpacing: '0.3px',
textTransform: 'uppercase',
},
}
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
I vote for keeping this one package, exporting both react components and the type styles, as they are so tightly coupled.
Oh, and there’s also the fact that Text wouldn’t create those unexpected line breaks we see in the current UI lib