Remove support for `className` prop

[remcohaszing]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

Typically a className prop in React adds a class name to the element it creates. For react-markdown this is not the case. Instead, it creates a wrapper that gets the class name. This is a fairly useless feature, because the user can wrap the content in a wrapper component themselves. That even gives the user more control.

In other words, these two are equivalent:

import Markdown from 'react-markdown'

export function Component({ children }) {
  return (
    <Markdown className="some-class">
      {children}
    </Markdown>
  )
}

import Markdown from 'react-markdown'

export function Component({ children }) {
  return (
    <div className="some-class">
      <Markdown>
        {children}
      </Markdown>
    </div>
  )
}

Solution

Deprecate the className prop, and remove it in then next semver major release.

Alternatives

• Do nothing.
• Don’t deprecate it.
• Make a semver major release just for this.

[wooorm]

a) is it really worth the churn to remove a nice to have feature that isn’t super useful but well, folks might want, and also people will already have, do we really need to break peoples code
b) we always generate a block. Generating a div around blocks is fine, doesn’t cause a shift.

Sure it’s quite useless. But it isn’t bad?

One more alternative: accept all IntrinsicAttributes['div'] too.

[wooorm]

@remcohaszing What do you think?

[remcohaszing]

I would flip the question: If we didn’t support the className prop yet, would it be worth adding it, if it requires doing something unexpected (adding a wrapper element)?

This behaviour is documented, but typically a className prop forwards it to the top-level component, not insert one additionally.

The alternative of having the user wrap <Markdown /> inside a <div /> manually is much more flexible. They can add any props they want to the <div />, or even use an entirely different element.

I don’t think we should remove of right away, but I think it would be nice to remove in a next major version.

[wooorm]

I’m not really opposed. But I feel like the churn/discussions/etc just doesn’t matter much. There’s a lot to maintain. Feel free to PR a comment: // To do: deprecate next major.

[CHE1RON]

Deprecating on next major or not, for the time being passing all IntrinsicAttributes['div'] grants more flexibility while not breaking anything for people (not) using className!

[ChristianMurphy]

I'm of a similar mind to @remcohaszing, I see a mapping of className or other <div> related props as muddling the top level API.
Users adding their own wrapper is more flexible and clear.

I'd lean against adding even more <div> props before a release removing support.
We want to minimize the amount of attributes users will need to change, not add more.

Feel free to PR a comment

Would we also want to add a devlop deprecation notice? (https://github.com/wooorm/devlop)

[JounQin]

Personally I prefer fewer nested depth, so I would like to add all props instead of removing the support.

[remcohaszing]

The problem with adding more props is, how far do you want to go? <div> supports tens (hundreds? Infinity including data-*?) of props. Why <div>, and not <main>, or a custom component? Should there be an as prop?

All of these choices complicate the API. Also there was simply no other way before the introduction of fragments / returning arrays. Removing the prop and promoting composition simplifies it.