LocalizedRichTextInput adds <p> tag to entered value

[kterry1]

Describe the bug
The LocalizedRichTextInput component adds a <p> tag to the value entered in the input.

To Reproduce

1. Go to https://uikit.commercetools.com/?path=/story/components-inputs--localizedrichtextinput
2. Click on the input
3. Open up the console and check the value added in data.args[0].target.value
4. See that the value entered has a <p> tag around it

Expected behavior
The value to just be what is entered in the input without the <p> tag.

Screenshots

Additional context
It's causing the Audit Log to show <p> when a user makes changes to the Product description under General Info as the LocalizedRichTextInput component is used there.

[jaikumar-tj]

Plus one on this issue. We face the same problem in products. Because of this, we couldn't go to the public beta with the rich text editor feature on product detail page. It would be super helpful if the default text didn't have a <p> tag enclosing it.

[emmenko]

Hi, thanks for the feedback.

From my understanding this is actually the normal behavior for richt-text inputs, to include the <p> tag, as it's supposed to emit HTML.

@kark Do you know if it's possible to omit it?

[kark]

Thanks,
I'd have refresh my memory and look it up. Off the top of my head, that was required.
I remember we had a regression due to not wrapping text nodes with <p> in the initial implementation
https://github.com/commercetools/ui-kit/pull/2236/files

[emmenko]

@kterry1 @jaikumar-tj @kark Let's try keeping the discussion in the issue instead of the PR.

As mentioned here I believe a richt-text input always emits HTML and always wraps the content into an element by default. For instance, typing just some text is considered a paragraph thus wrapping it into a <p> is in theory correct.

What we would like to understand is what "problems" exactly are caused by this behavior.

Is it just an expectation problem from your side or is this causing like bugs or more technical issues?

[jaikumar-tj]

@emmenko Sure 👍.
The main problem for our case is that we use rich-text input for product descriptions(only usage in mc-frontend repo) and this feature is currently in closed beta for more than a couple of years. We want to enable the feature to public beta but there is one big problem.

If we enable it then all our customers who are consuming our product details API in their storefront websites will start seeing HTML tags since they may not have implemented any HTML parser in their frontend. So this makes the RichText input not easily usable anywhere in MC. If we use anywhere in MC then those fields can only be internal and cannot modify any data in the API which our customer might be consuming without an appropriate parser.

There is a investigation ticket to figure out how to make rich-text editor feature to release into public beta. We thought of multiple solutions and the solution suggested by @kterry1 seems to also helpful.

If anyone has any other idea on how to use such rich text editor without causing disturbance to customers' frontend/storefront site, please do let me know. We are actively discussing this in our team and looking for a solution.

[kterry1]

@emmenko When a user makes a change and uses the LocalizedRichTextInput in MC, they see the <p> tag in the audit log.

Whereas you can see that the same change made via the API results in obviously no <p> tag.