Optional keyed resolvers

[alvarosabu]

Currently, all the resolvers return a randomly generated key attribute

https://github.com/storyblok/richtext/blob/54befd6568bd71a91ebdabe180a08631a93d3f7f/src/richtext.ts#L68C3-L71C4

This was initially aimed to avoid key-related warnings when extended with React. However, keys are also returned on the vanilla string usage, resulting in an invalid HTML markup.

This is currently blocking adding @storyblok/richtext to React SDK

Solution

Provide a flag via options keys with default value false on the StoryblokRichTextOptions

Alternative solution

We could also remove it completely and leave the responsibility to the user when extending with React and Vue, since those are the only frameworks requiring a attr/prop key

[alvarosabu]

I would like to have your opinion @Edo-San @edodusi

[edodusi]

@alvarosabu i don't get where this error is raised, plus do we need key for headings and in general for elements outside of a list?

[alvarosabu]

Hi @edodusi

It will prompt only in your React app when using the package.

Plus do we need key for headings and in general for elements outside of a list?

Maybe for React not, but for Vue you do need a key whenever you use v-for no matter the tag, if the end user is using a custom block that iterates inside the richtext key is required

Also vanilla li items should not have key either, we still need the flag no matter if we decide to key all of just lists

[edodusi]

@alvarosabu ok now I'm starting to get it 😅

The key attribute is needed when you render lists in React, but then the actual markup that React normally produces strips the key away. So this is not happening with this module, apparently everything that is generated by defaultRenderFn ends up in the actual markup returned to the browser, is that correct?

Pardon my noob question, but the markup coming out of that render function is supposed to be valid markup or React (or Vue) markup that the framework should then render?