search

betancourtl / draft-js-custom-styles

Create custom inline styles for draft-js in a sane way
MIT License
34 stars 17 forks source link

Exporter does not work with ContentState #14

Closed virgilbugnariu closed 5 years ago

virgilbugnariu commented 5 years ago

Hi Luis and first of all thank you for making and maintaining this library.

I've encountered the following situation where I need to use exporter without having access to an EditorState object, but a ContentState object. The reason behind this is that I need to render HTML in another part of our application where a DraftJS editor is not instantiated. That being said, the only data I can get is a ContentState object returned by the convertFromRaw function. The problem arises when exporter tries to access the getCurrentContent() method from the editorState object passed as argument.

I think this is somewhat related to this issue, in my case converting from raw content rather than HTML.

I managed to make a fork and fix this and I'm more than happy to make a pull request, but I wanted to discuss this first.

Is there a reason for requiring EditorState in in the export process or is this just an edge case? Am I missing something and is there the possibility of converting from raw directly to EditorState?

Thanks :)

betancourtl commented 5 years ago

Hi thx for taking your time to submit this issue.

I see maybe 3 possible solutions.

  1. Pass the ContentState to EditorState. createWithContent to create an EditorState from your ContentState.

https://draftjs.org/docs/api-reference-editor-state#createwithcontent

This is a static method that you can call 

static createWithContent(
  contentState: ContentState,
  decorator?: DraftDecoratorType
): EditorState

  1. Change the library. Accept ContentState|EditorState as inputs and create the logic for handling both.

  2. Change the API to accept only the ContentState.

The easiest one will probably be option 1 because you can probably already use the library as is, but option 2 seems like it would be more flexible. I am somewhat hesitant about options 3 because It would be a breaking change.

I would accept a PR that handles option 2 as long as it has tests for accepting an EditorState or a ContentState. as inputs.

Initially I created the API to take in an EditorState, and I overlooked your specific case. I think it is a valid request. Feel free to submit a PR and I will take a look at it whenever I can. Thank you!

virgilbugnariu commented 5 years ago

Hi,

You're right, the createWithContent method should actually do the trick. I will use this for now, thank you for your suggestion!

I'm closing this issue.