Should we move the Chakra UI Prose package in the core library?

[nikolovlazar]

Recently I've developed a Chakra UI Prose package that adds ready-made styling to a remote HTML content. We decided to roll it out as a separate package is to avoid bloating the core library while we figure out how much people actually need it.

This discussion will help us figure out if we should move it in the core library package. Let us know what you think. Add a reaction or comment if you need this to be part of the core package.

[chasinhues]

Love the idea to build a rich text editor into Chakra.

We used tiptap at work which is a headless rich text editor built on top of Prose as well. Because it's headless, we were able to build the view with Chakra components. I really like the way this turned out, so excited to see what you guys can do with an official Chakra Prose package!

[nikolovlazar]

Hey that's so cool! I didn't know about tiptap.

[JTBrinkmann]

I think a rich text editor would be completely out of the scope for Chakra. But having an editor that works nicely with Chakra is a great thing for a separate project.

[pckben]

Same here, I discovered Prose while trying to make Tiptap works with Chakra. So glad I don't have to hand customize all the tiptap nodes to display HTML.

[muco-rolle]

I think would be great to keep it as a separate Chakra UI package

[perkinsjr]

Finally! Prose, As a heavy Chakra UI user who has built sites, applications for clients I am so glad to see this. I don't think it needs to be a core offering but @chakra-ui/prose would be a nice touch.

I just added prose to a blog and removed 50+ lines of code that basically passed each HTML element to a component.

[Jarmos-san]

I'm working on a blog which used TailwindCSS earlier & is gradually migrating to Chakra-UI. The blog used the @tailwindcss/typography plugin which was quite handy when it came to providing some default styling to the contents of the CMS. And I think Chakra-UI Prose can serve a similar purpose as well.

Also I think the project might benefit better if it was moved under the official Chakra-UI GitHub organisation (considering it's already being maintained by a Chakra-UI developer!) Moving the project under an official banner will gather more exposure to the project as well.

[wh1337]

I would love to see this in the core package. This is something that I feel is greatly missing from Chakra UI and can greatly improve the library.

[ivan-kleshnin]

For a difference, I'm strongly against the idea of adding this library to a core package and I even against exposing it at @chakra-ui/prose 👎 👎

"Chakra Prose" current implementation is too opinionated and goes to a wrong direction (all IMO).
I don't enjoy critizing other people's work, but please hear me out:

---

Defaults

1. The main purpose of such Typography component – confirmed by comparisons to MUI, Mantine, etc. known UI libs –
   is to make sure all basic tags have the same look they would have being defined as components!

h1 should look like the default variant of Heading. a should look like the default variant of Link.
ul should look like UnorderedList. And so on.

Now Chakra-Prose just barely follows the above rule assigning its own custom values to all props.

Prose version

h4: {
  fontFamily: 'heading', // this is right
  fontWeight: 'semibold', // what if defauls were overriden?
  fontSize: { base: 'md', md: 'lg' }, // what if defauls were overriden?
  mt: { base: 6, md: 8 }, // what if defauls were overriden?
  mb: 2, // what if defauls were overriden?
},

My version

const {Code, Heading, Link, List, ...} = theme.components
...
"& h4:not(.chakra-heading)": {
  ...Heading.baseStyle, // !!!
  fontSize: Heading.sizes.xs.fontSize,     // this is also too subjective, should be rethinked
  lineHeight: Heading.sizes.xs.lineHeight, // ...
},

As you can see Chakra-Prose assigns its own custom styles to headings instead of reusing the ones that were set for Heading which seems like the only sane default! The same happens with all tags:

Prose version

a: {
    fontWeight: 500, // ?! not all fonts support 500 weight
    transitionProperty: 'common',
    transitionDuration: 'fast',
    transitionTimingFunction: 'ease-out',
    cursor: 'pointer',
    textDecoration: 'none', // does not follow defaultProps...
    outline: 'none',
    color: 'inherit',
    _hover: {
      textDecoration: 'underline', // does not follow defaultProps...
    },
    _focus: {
      boxShadow: 'outline', // does not follow defaultProps...
    },
  },

My version

const {Code, Heading, Link, List, ...} = theme.components
...
"& a:not(.chakra-link)": {
  ...Link.baseStyle, // !!!
  ...Link.variants[Link.defaultProps.variant]({theme, colorScheme: Link.defaultProps.colorScheme}), // !!!
},

---

API

2. Another very important feature of Typography is to support ALL of the following APIs:

<Typography>
  <h1>...</h1>
</Typography>

<Typography>
  <Heading as="h1" size="_">...</Heading>
</Typography>

<Typography>{`
  <h1>...</h1>
`}</Typography>

All 3 must look the same (all other things being equal)!
From the docs, Chakra-UI supports only the 3rd way and doesn't care about 1 and 2.

Again, I rechecked what other UI libraries do before writing this. For example, Mantine's TypographyStylesProvider, while being buggy, still approaches the "right goal" here. It attempts to reproduce the component look.

Conclusion

Chakra-Prose, in its current form, goes to a very subjective and opinionated direction which contradicts key values of Chakra-UI:

• simplicity
• predictability
• consistency
• ease of customization

My goal here is not to push an alternative version. I'd just like Chakra-UI to not contain packages that are objectively bad (and I'm open to being proven wrong). It's easy to say "Just ignore the component you don't like!" But in the future I might have to support an app built on top of these things.

If next Chakra-Prose's version revisits its premises and addresses the above points – I'll be the first to support it.

---

If it ever becomes a part of Chakra UI, I'd also like it to be named more generic, like Typography.
It should be used to style poetry, cards, maybe hero sections etc. "rich text" blocks where you want something to set proper distances between elements (without adding margins to each of them manually).

It should not be limited to styling HTML/Markdown content.

[elauser]

For anyone else where just restyling the components isn't enough and would up here like me, I created a parser which turns a html string into chakra-ui components. I needed it especially for turning links into next.js links so the state doesn't break on parsed links.

I don't think that this should be in the main chakra-ui core library but I really do appreciate the theme config which I copy and pasted into my projects, I think this should be somewhere linked to from the chakra-ui docs though (it might be already I don't know 100%). <3

Here's a gist, and a preview below
https://gist.github.com/elauser/9a24ac10216aafba8a2b8c21c1e58e24

import type { As } from '@chakra-ui/react'
import { Heading, ListItem, OrderedList, Text } from '@chakra-ui/react'
import { NextLink } from 'design_system/utility/NextLink'
import type { DOMNode, Element, HTMLReactParserOptions } from 'html-react-parser'
import parse, { domToReact } from 'html-react-parser'

export const headingSizes = {
  h1: ['4xl', '5xl', '6xl'],
  h2: ['3xl', '4xl', '5xl'],
  h3: ['2xl', '3xl', '4xl'],
  h4: ['xl', '2xl', '3xl'],
  h5: ['lg', 'xl', '2xl'],
  h6: ['md', 'lg', 'xl'],
}

export type HeadingKey = keyof typeof headingSizes

export const asComponent = (plainHtml: string) => {
  return <>{parse(plainHtml, options)}</>
}

function isParsedElement (domNode: DOMNode | Element): domNode is Element {
  return domNode.constructor.name === 'Element' || domNode.type === 'tag'
}

const toCamelCase = (s: string) => s.replace(/-./g, x => x[1].toUpperCase())

const styleStringAsObject = (style: string) => {
  const noWhitespaces = style.replace(/\s+/g, '')
  const attributes = noWhitespaces.split(';')

  return Object.fromEntries(attributes.map(attribute => {
    const entry = attribute.split(/:(.+)/) // TODO refactor adds an unneccesary empty element at the end hence the filter on value
    const key = entry.splice(0, 1)[0]
    const value = entry.filter(e => e !== '').join(':')
    return [key, value]
  }))
}

const options: HTMLReactParserOptions = {
  replace: domNode => {
    if (isParsedElement(domNode)) {
      const children = domNode.children
      const tagName = domNode.name

      const safeAttribs: { [key: string]: string | object } = {}
      for (const [key, value] of Object.entries(domNode.attribs)) {
        const safeKey = toCamelCase(key)
        if (safeKey === 'style') {
          safeAttribs[safeKey] = styleStringAsObject(value)
        } else {
          safeAttribs[safeKey] = value
        }
      }

      const reHeading = /^h\d$/
      if (tagName.match(reHeading)) {
        const heading: As = (tagName as As)
        return (
          <Heading
            as={heading}
            marginLeft="auto"
            marginRight="auto"
            fontSize={headingSizes[tagName as HeadingKey]}
            pb={['8px', '20px']}
            pt={['20px', '40px']}
            lineHeight={1}
            {...safeAttribs}
          >{domToReact(children, options)}
          </Heading>
        )
      }
      switch (tagName) {
        case 'a': {
          return (
            <NextLink
              color="primary.500"
              _hover={{
                textDecoration: 'underline',
              }}
              {...safeAttribs}
            >{domToReact(children, options)}
            </NextLink>
          )
        }
        case 'ul': {
          return (
            <OrderedList
              lineHeight="2rem"
              {...safeAttribs}
            >{domToReact(children, options)}
            </OrderedList>
          )
        }
....