Rename the children 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 discussions and couldn’t find anything (or linked relevant results below)

Problem

We require children to be a string. In theory this is completely fine, but sometimes this is confusing for users or doesn’t play nice with external tooling. Users often don’t know what they pass as children. Many users already struggle with multiline strings, but JSX children add another layer of confusion. #886 is a recent example. Typically children are passed to React directly, but in our case it’s processed using a unified processor.

Some examples I could come up with:

<Markdown>
  # Hello

  world
</Markdown>

<Markdown>
  # Hello

  <br />

  world
</Markdown>

<Markdown>
  # Hello

  world
</Markdown>

<Markdown>{`
  # Hello

  world
`}</Markdown>

Current solutions

Tell users the problem is outside of react-markdown. (Which it is! But we can improve react-markdown anyway.)

Proposed solutions

Rename the children prop. For example, name it content, value, or markdown.

[wooorm]

I am against this. There is no need to cause a breaking change for tiny gains. Especially if it’s a trade off that also comes with losses.

If we rename it to value then people will still pass weird things—numbers, arrays.
I also wager that more people will be confused that children (the prop or actual ones) don’t work.

A couple years ago, the property was renamed from value to children. There are also arguments for this. One of them is consistency with other tools such as https://github.com/quantizor/markdown-to-jsx.

[wooorm]

@remcohaszing Shall I then close this?

[remcohaszing]

It’s a prop rename. We’ve had more of those. I also don’t think we should cut a major release just for this, but when it’s time for a major release, I would welcome this change.

I also believe people will still pass invalid things if the prop is named differently. Indented multiline strings come to mind. But the children prop invites user to pass more categories of invalid things, such as JSX elements or expressions.

I wouldn’t prioritize similarity to other libraries. I don’t really see the benefit of using the children prop.

This is just a suggestion though. The current situation works on a technical level. Feel free to close this issue. But I think it would be better to avoid the children prop for this use case.

[wooorm]

Sure we’ve had breaking changes, but we don’t need to have breaking changes.
There are a million users of this package and you propose that they all spend 5 minutes to change their code bases: a colossal cost!
When there is the inevitable major, we don’t need to change this.