html-react-parser

html-react-parser copied to clipboard

It seems that the attributesToProps method is converting all keys to lowercase (see https://github.com/remarkablemark/html-react-parser/blob/master/lib/attributes-to-props.js#L37 ).

Why is this happening? We would like to pass case-sensitive attributes to our dynamic html content and with the current implementation it doesn't work, since all attributes are converted to lower case?

Thanks for the question @h0jeZvgoxFepBQ2C, attributesToProps converts all keys to lowercase because the DOM/SVG attributes get remapped to React props (e.g., class to className).

On the browser, the attributes technically don't care about case-sensitivity. Is there a particular reason why you need case-sensitive attributes?

There are htmlparser2 options, but they only work on Node.js (server-side) and do not work in the browser (client-side).

Thanks for the follow up @remarkablemark

Actually we would like to pass react specific arguments to our html, so we can use these attributes directly.. F.e. imagine a div should be replaced with a countdown element with the argument endsAt:

<div role="countdown" endsAt="2021-10-10 01:01:01+0200"/>

should be converted to

<Countdown endsAt="2021-10-10 01:01:01+0200"/>

So if the arguments are always downcased, I cannot use them for the react components? Also we cannot map the arguments, since we provide the arguments dynamically (yeah, this is a security concern, but we are in a trusted environment, so this is not an issue for us)

@remarkablemark Any thoughts on this? Your library would offer much more possibilities if it doesn't convert all keys to downcase. And as you said, browsers don't care about case sensitivity, so it wouldn't make a difference?

Right now there is only this downside, that we can't use it to pass props directly to other React components?

@h0jeZvgoxFepBQ2C If you're using the library only on the server-side (Node.js), then you can override the htmlparser2 options. You can find a list of the parser options here.

I know, but we are clientside rendering

Adding my vote to this. If possible it would be nice with an option to enable the client side version to work the same as the server side version. Some use cases, like mine, don't need to care about e.g. XSS issues.

@remarkablemark would you accept a PR for this, to make the option also available for the client side?

@h0jeZvgoxFepBQ2C I feel the approach will add more complexity to html-dom-parser.

If you really want to achieve this, one approach is to override Webpack to ensure htmlparser2 is imported in html-dom-parser. The downside is your bundle size will increase a lot.