Let mentions render with plain JS Object #326
Conversation
When you try to use an `editorState` that was converted from a
RawDraftContentState, the assumption that a mention is a `Map` does not
hold.
````
const contentState = convertFromRaw(instanceOfRawDraftContentState);
const editorState = EditorState.createWithContent(contentState);
this.state = {
editorState: editorState,
}
````
anderslemke
changed the title
|
@anderslemke this a really interesting approach … I was thinking about switching to non-immutable structures for 2.0 version. I would like to discuss what are the up & downsides of doing so compared to your version: Pro of you version:
Con of you version:
It kind of reminds me of the robustness principle: |
|
I merged it to cut a last 1.x.x release, but I'm still curious if we should switch to plain JS objects in 2.0 as it would speed things up a bit and make it more consistent. |
|
It does seem a little weird to me to "force" people into using ImmutableJS in a library, although since DraftJS is built upon ImmutableJS and requires it already it seems a little less heavy-handed than if you had done it in another library. I would generally prefer plain JS objects allowing people to use custom creators for Immutable if they want it, but I don't typically use Immutable in my projects so I am probably a bit biased. |
|
Thank you for merging @nikgraf As for your thoughts about switching to plain JS object, I think that discussion could be split into two parts. What do you want to use internally in the plugins, and what do you support from the outside. As for "internally", I do not feel qualified to answer that question. Externally, I think the current way of supporting both plain and ImmutableJS externally is good way to go. People doesn't control what comes out of That was my thoughts. Thanks for some great plugins. 👍 |
|
I agree with @mjrussell about the fact that a library shouldn't force you to change your workflow but is acceptable in regards to DraftJS as the core library does itself forces you to use ImmutableJS. That been said, @anderslemke raised some pretty valid points regarding the difference between internal mechanics and external API usage. If possible, I'd suggest to make a choice between the two - the external API should always provide and accept the same kind of objects (I'd personally vote for plain JavaScript object, there's no risk of users mutating the objects anyway). |
|
Sounds good to me! Accepting both is ideal, but if not possible we switch to plain objects. I added this discussion to the roadmap issue. |
|
@zhouzi DraftJS does include Immutable, but doesn't force you to use it explicitly (i.e. you don't have to |
When you try to use an
editorStatethat was converted from aRawDraftContentState, the assumption that a mention is aMapdoes nothold.
I assume that calling
fromJSon something that is already aMapis a no-op.Which seems to be the case: https://github.com/facebook/immutable-js/blob/38019326a8d006a45ef48d9c4644e23ea476d298/src/fromJS.js#L28-L36