Change <Slate> to a controlled component

[ianstormtaylor]

Is this adding or improving a feature or fixing a bug?

Improvement.

What's the new behavior?

It changes <Slate> to be a controlled component.

How does this change work?

It takes value= and selection= props and ensures they are updated on the editor whenever they change, such that people can use their own useState to store them. People must now store state for both of these.

Currently it is:

<Slate defaultValue={initialValue}>
  // ...
</Slate>

With this PR it is:

const [value, setValue] = useState(initialValue)
const [selection, setSelection] = useState(null)

<Slate 
  value={value} 
  selection={selection} 
  onChange={(value, selection) => {
    setValue(value)
    setSelection(selection)
  }}
>
  // ...
</Slate>

For an example in context, check out the changes to the rich-text example on this branch.

Have you checked that...?

• The new code matches the existing patterns and styles.
• The tests pass with yarn test.
• The linter passes with yarn lint. (Fix errors with yarn fix.)
• The relevant examples still work. (Run examples with yarn start.)

Does this fix any issues or need any specific reviewers?

Fixes: #3209

[PeterKottas]

Looks great, well done man!

[cameracker]

moving this to a different module was a good decision i think, it took a little bit to find it just diving through github.

[cameracker]

i wonder if there will be some gotchas around memoizing around the extra props. for the most part this is probably what a caller is going to need but this seems like a subtle trap for users who are not paying attention

[ianstormtaylor]

Yeah, although by including them it's less restrictive (not more) so I think it's alright? Otherwise implementing your own custom editor properties becomes impossible I think?

[cameracker]

This looks pretty good to me. I'm happy that this still works well with the context based distribution work flow.

[focux]

Looks good to me, also, thank you for all your work @ianstormtaylor.

[benjycui]

How can I get operations for collaborative editing after this MR?

[wmertens]

I would prefer that the entire state gets controlled as state and the current value is a part of that (much like it was before).

• plugins can add their own editor state without changing the public API. E.g. a history plugin can add a history key to the state.
• only one state needs storing by the user
• the name state makes clear that it's not just the text value

[rikkit]

Not really been following this - is it possible to use Slate as an uncontrolled component after this? Or is this fully switching it over? I guess you can always have a wrapper component to make it uncontrolled.

[Jokcy]

@ianstormtaylor https://docs.slatejs.org/concepts/xx-migrating#plugins

So plugin deps on operation won't work anymore? What's the new way to build a plugin?

[PeterKottas]

I think your question doesn't belong here @Jokcy, try slack, this PR is for making slate into a controlled component again.

@ianstormtaylor , just out of curiosity, since this is a breaking change, how long do you think it will take to get this out? Not sure what the policy about stuff like this is with slate. Thanks!

[ianstormtaylor]

How can I get operations for collaborative editing after this MR?

You can access them from editor.operations. (Actually you can access the children and selection that way too, but I've changed the onChange handler to be more of a convenience for making things React-ish instead of "the only way to get things".)

[ianstormtaylor]

Not really been following this - is it possible to use Slate as an uncontrolled component after this? Or is this fully switching it over? I guess you can always have a wrapper component to make it uncontrolled.

This fully switches to a controlled component. I think using React's own helpers you can make it "uncontrolled" kind of. But I'd rather have only a single way to do it.

[maksimsemenov]

I think docs still refer to the old API (an un-controlled). Not sure if it is a known issue, though