Skip to content
This repository has been archived by the owner on Feb 6, 2023. It is now read-only.

Defer adding editorKey until after initial render #822

Closed
wants to merge 3 commits into from

Conversation

nsfmc
Copy link
Contributor

@nsfmc nsfmc commented Nov 29, 2016

Summary

currently, the generation of _editorKey during construction causes serverside rendering to break. This PR changes the behavior so that the _editorKey is either passed in as a prop or generated dynamically during componentDidMount if no prop was provided.

Test Plan

Included is a minimal universal/iso example which breaks before adding the subsequent commit. Upon building draft-js with the second commit, the universal rendering works if an editorKey prop is passed, or not, or whatever.

A slight gotcha here: EditorState.createEmpty() will create mismatched content states between the server rendered editor and the browser rendered one. For this reason, the example uses a dummy empty rawDraftContentState rather than using the other examples' approach of using createEmpty()

I'm 100% ok if this is the wrong approach or not good to merge, i'm opening it as an rfc mostly to get feedback or to understand if this is not a tenable approach to getting universal rendering unbroken with draft.

adds a small express-backed universal react app that only accepts `/`
requests but that exhibits a client/server mismatch issue
allows callers of <Editor /> to pass a custom `editorKey` to a draft
instance. This fixes universal rendering mismatches between client and
the server.

Instead of generating a random key when the component initializes, it
waits for a custom one. If one is not passed, its key is empty until it
renders and then it receives a random one when mounted if one was not
passed in as a prop.
@nsfmc nsfmc changed the title RFC: Support editorKey via props Defer adding editorKey until after initial render Nov 29, 2016
@pofigizm
Copy link
Contributor

It's similar to #796 ))

@nsfmc
Copy link
Contributor Author

nsfmc commented Feb 9, 2017

@flarnie this can probably be closed. it's similar to #796 but keys blocks on mount via setState to maintain compat with the accessibility stuff. not sure what the status on the other pr is, but it seems to have greater mindshare and has probably been updated more frequently than this (as well as having inherited this pr's tests 😛 )

@flarnie flarnie self-assigned this Mar 14, 2017
@flarnie
Copy link
Contributor

flarnie commented Mar 15, 2017

Thanks again - merged #796 so closing this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants