-
-
Notifications
You must be signed in to change notification settings - Fork 865
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
Remove the className
prop
#781
Comments
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 Sure it’s quite useless. But it isn’t bad? One more alternative: accept all |
@remcohaszing What do you think? |
I would flip the question: If we didn’t support the This behaviour is documented, but typically a The alternative of having the user wrap I don’t think we should remove of right away, but I think it would be nice to remove in a next major version. |
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: |
Deprecating on next major or not, for the time being passing all |
I'm of a similar mind to @remcohaszing, I see a mapping of I'd lean against adding even more
Would we also want to add a |
Personally I prefer fewer nested depth, so I would like to add all props instead of removing the support. |
Users should wrap the `<Markdown>` component inside a `<div>` manually instead. Closes #781
The problem with adding more props is, how far do you want to go? 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. |
All props can be supported via simple
Actually the user can just don't pass any HTML attributes with a wrapper by themselves. |
@JounQin there seems to be two different discussions here:
I completely agree that is it possible, though code to support all attributes and switching HTML tags. I respectfully disagree that |
Yeah, think that’s easiest. Removing it. |
I think it's best to leave it as is. It just doesn't seem like a pressing concern and will require users to change their code, all for something that isn't truly important. Let's leave this as is, I think we should minimize breaking changes, especially when it's something as benign as this. It's a nice-to-have without negative consequences, no harm. |
Agree with @AVGVSTVS96. It is better to keep it, at least for now. Maybe when the next necessary breaking change will be introduced - the |
Initial checklist
Problem
Typically a
className
prop in React adds a class name to the element it creates. Forreact-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:
Solution
Deprecate the
className
prop, and remove it in then next semver major release.Alternatives
The text was updated successfully, but these errors were encountered: