UPDATE
This was commited here
A missing use case for Draftjs i've ran into a couple times is that when text is pasted, there are ways to override the default paste handler and do your own thing.
That said, overriding the default paste handler means you have to manage your own fragment, have logic to handle html potentially, and then insert the blocks you generate in the proper place relative to the cursor and selection. For a lot of use cases, this seems overkill?
An example: (And the reason I'm posting this RFC) is that I'm trying to turn leading tabs into spaces when pasting markdown lists, since they can't be parsed. Users can't actually _type_ a tab so this is only a problem on pastes. Reimplementing the paste handler for this is doable but using the proposed method, it's implementation becomes a oneliner.
type FormatPastedTextFn = (
text: string,
html: ?string,
) => {text: string, html: ?string},
// this replaces every vowel with a happy face
<DraftEditor
{...otherProps}
formatPastedText={text => {
return {
text: text.replace(/[aeiou]/gi, '馃槉'),
};
}}
/>
There's some precedent to this type of handler. blockRendererFn and blockStyleFn both plug into a similar way, overriding the default implementation if they are in place.
Then handlePastedText of course works similarly and I went ahead and copied its signature, when it comes to naming formatPastedText, all handle* functions return a handle, which is not what we want in this case.
Handling html might be a bit smelly? it is doable but you really don't wanna transform raw html to raw html, at that point you do wanna replace the paste handler.
What I've done is that it's the responsibility of formatPastedText to pass the html result through or eat it up and return undefined, formatting only the static text.
An option here is to make formatPastedText text only (formatPastedText(text)=>text), if this prop is in place we ignore all html automatically, and that simplifies the signature.
Thank you for putting this up @walaura! From a maintainer's perspective I think your proposal is good as-is but let's see if people have any strong arguments against it. I'd especially love to hear from folks who currently override editOnPaste and have to duplicate (i.e. copypasta) a lot of behavior to perform trivial text transform if this approach would be beneficial to them as well.
Sorry for the delayed response. Was thinking about it for a bit because in general, I think erring on the side avoiding increasing the API surface area tends to be better. On that vain, I was wondering if we could achieve this with a helper function that has your signature, but sits on top of the current API. Something along the lines of:
<DraftEditor
{...otherProps}
handlePastedText={pasteWithFormatter(({text}) => {
return {
text: text.replace(/[aeiou]/gi, 'x'),
};
})}
/>
But this doesn't look like it'll be possible though because handlePastedText can't modify state.
The addition of formatPastedText seems simple enough and tbh I think it'll be fine. I have no objections, happy to accept this. 馃憤
This new prop will need a PR for TypeScript types in the DefinitelyTyped repo as well. We don't actively manage TS types for Draft, but feel free to prepare one if you like 馃殌
Examples:
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/45522
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/45591
Hey, awesome!
I'm gonna go ahead and close this issue since this change got merged (not sure if it needs a version bump or something?) and i'll get to the type defs in the afternoon
Yes I'd say this would require a minor version bump, but we can take care when approaching the next release 馃憤
Most helpful comment
Hey, awesome!
I'm gonna go ahead and close this issue since this change got merged (not sure if it needs a version bump or something?) and i'll get to the type defs in the afternoon