Skip to content
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

evergreen-typography outline #2

Closed
jeroenransijn opened this issue Aug 20, 2017 · 5 comments · Fixed by #732
Closed

evergreen-typography outline #2

jeroenransijn opened this issue Aug 20, 2017 · 5 comments · Fixed by #732

Comments

@jeroenransijn
Copy link
Contributor

jeroenransijn commented Aug 20, 2017

The 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',
  },
}
@nettofarah
Copy link
Contributor

nettofarah commented Aug 20, 2017

This is a great start!
I'd say I'm more inclined on Text being a span over a p, as I think that would make the component a bit more composable.

@nettofarah
Copy link
Contributor

Oh, and there's also the fact that Text wouldn't create those unexpected line breaks we see in the current UI lib

@jeroenransijn jeroenransijn added this to the First Release milestone Aug 21, 2017
@casesandberg
Copy link

I vote for keeping this one package, exporting both react components and the type styles, as they are so tightly coupled.

@jeroenransijn
Copy link
Contributor Author

Additional Text Styles

I have added the components and styles described below in #7. I realized it makes sense to also cover OL,UL and potentially others.

I would say these are nice to haves and require a new issue.

@casesandberg
Copy link

casesandberg commented Aug 29, 2017 via email

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

Successfully merging a pull request may close this issue.

3 participants