Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(deps): update dependency slate-react to ^0.59.0 #3814

Closed
wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Sep 28, 2020

This PR contains the following updates:

Package Type Update Change
slate-react dependencies minor ^0.22.10 -> ^0.59.0

Release Notes

ianstormtaylor/slate

v0.59.0

Compare Source

v0.58.4

Compare Source

v0.58.3

Compare Source

v0.58.2

Compare Source

v0.58.1

Compare Source

v0.58.0

Compare Source

BREAKING

User properties on Elements and Texts now have an unknown type instead of any. Previously, the arbitrary user defined keys on the Text and Element interface had a type of any which effectively removed any potential type checking on those properties. Now these have a type of unknown so that type checking can be done by consumers of the API when they are applying their own custom properties to the Texts and Elements.


v0.57.3

Compare Source

v0.57.2

Compare Source

v0.57.1

Compare Source

v0.57.0

Compare Source

BREAKING

Overridable commands now live directly on the editor object. Previously the Command concept was implemented as an interface that was passed into the editor.exec function, allowing the "core" commands to be overridden in one place. But this introduced a lot of Redux-like indirection when implementing custom commands that wasn't necessary because they are never overridden. Instead, now the core actions that can be overridden are implemented as individual functions on the editor (eg. editor.insertText) and they can be overridden just like any other function (eg. isVoid).

Previously to override a command you'd do:

const withPlugin = editor => {
  const { exec } = editor

  editor.exec = command => {
    if (command.type === 'insert_text') {
      const { text } = command

      if (myCustomLogic) {
        // ...
        return
      }
    }

    exec(command)
  }

  return editor
}

Now, you'd override the specific function directly:

const withPlugin = editor => {
  const { insertText } = editor

  editor.insertText = text => {
    if (myCustomLogic) {
      // ...
      return
    }

    insertText(text)
  }

  return editor
}

You shouldn't ever need to call these functions directly! They are there for plugins to tap into, but there are higher level helpers for you to call whenever you actually need to invoke them. Read on…

Transforms now live in a separate namespace of helpers. Previously the document and selection transformation helpers were available directly on the Editor interface as Editor.*. But these helpers are fairly low level, and not something that you'd use in your own codebase all over the place, usually only inside specific custom helpers of your own. To make room for custom userland commands, these helpers have been moved to a new Transforms namespace.

Previously you'd write:

Editor.unwrapNodes(editor, ...)

Now you'd write:

Transforms.unwrapNodes(editor, ...)

The Command interfaces were removed. As part of those changes, the existing Command, CoreCommand, HistoryCommand, and ReactCommand interfaces were all removed. You no longer need to define these "command objects", because you can just call the functions directly. Plugins can still define their own overridable commands by extending the Editor interface with new functions. The slate-react plugin does this with insertData and the slate-history plugin does this with undo and redo.

NEW

User action helpers now live directly on the Editor.* interface. These are taking the place of the existing Transforms.* helpers that were moved. These helpers are equivalent to user actions, and they always operate on the existing selection. There are some defined by core, but you are likely to define your own custom helpers that are specific to your domain as well.

For example, here are some of the built-in actions:

Editor.insertText(editor, 'a string of text')
Editor.deleteForward(editor)
Editor.deleteBackward(editor, { unit: 'word' })
Editor.addMark(editor, 'bold', true)
Editor.insertBreak(editor)
...

Every one of the old "core commands" has an equivalent Editor.* helper exposed now. However, you can easily define your own custom helpers and place them in a namespace as well:

const MyEditor = {
  ...Editor,
  insertParagraph(editor) { ... },
  toggleBoldMark(editor) { ... },
  formatLink(editor, url) { ... },
  ...
}

Whatever makes sense for your specific use case!


v0.56.1

Compare Source

v0.56.0

Compare Source

BREAKING

The format_text command is split into add_mark and remove_mark. Although the goal is to keep the number of commands in core to a minimum, having this as a combined command made it very hard to write logic that wanted to guarantee to only ever add or remove a mark from a text node. Now you can be guaranteed that the add_mark command will only ever add custom properties to text nodes, and the remove_mark command will only ever remove them.

Previously you would write:

editor.exec({
  type: 'format_text',
  properties: { bold: true },
})

Now you would write:

if (isActive) {
  editor.exec({ type: 'remove_mark', key: 'bold' })
} else {
  editor.exec({ type: 'add_mark', key: 'bold', value: true })
}

🤖 Note that the "mark" term does not mean what it meant in 0.47 and earlier. It simply means formatting that is applied at the text level—bold, italic, etc. We need a term for it because it's such a common pattern in richtext editors, and "mark" is often the term that is used. For example the <mark> tag in HTML.

The Node.text helper was renamed to Node.string. This was simply to reduce the confusion between "the text string" and "text nodes". The helper still just returns the concatenated string content of a node.


v0.55.3

Compare Source

v0.55.2

Compare Source

v0.55.1

Compare Source

v0.55.0

Compare Source

BREAKING

The match option must now be a function. Previously there were a few shorthands, like passing in a plain object. This behavior was removed because it made it harder to reason about exactly what was being matched, it made debugging harder, and it made it hard to type well. Now the match option must be a function that receives the Node object to match. If you're using TypeScript, and the function you pass in is a type guard, that will be taken into account in the return value!

Previously you might write:

Editor.nodes(editor, {
  at: range,
  match: 'text',
})

Editor.nodes(editor, {
  at: range,
  match: { type: 'paragraph' },
})

Now you'd write:

Editor.nodes(editor, {
  at: range,
  match: Text.isText,
})

Editor.nodes(editor, {
  at: range,
  match: node => node.type === 'paragraph',
})

The mode option now defaults to 'lowest'. Previously the default varied depending on where in the codebase it was used. Now it defaults to 'lowest' everywhere, and you can always pass in 'highest' to change the behavior. The one exception is the Editor.nodes helper which defaults to 'all' since that's the expected behavior most of the time.

The Editor.match helper was renamed to Editor.above. This was just to make it clear how it searched in the tree—it looks through all of the nodes directly above a location in the document.

The Editor.above/previous/next helpers now take all options in a dictionary. Previously their APIs did not exactly match the Editor.nodes helper which they are shorthand for, but now this is no longer the case. The at, match and mode options are all passed in the options argument.

Previously you would use:

Editor.previous(editor, path, n => Text.isText(n), {
  mode: 'lowest',
})

Now you'd use:

Editor.previous(editor, {
  at: path,
  match: n => Text.isText(n),
  mode: 'lowest',
  ...
})

The Editor.elements and Editor.texts helpers were removed. These were simple convenience helpers that were rarely used. You can now achieve the same thing by using the Editor.nodes helper directly along with the match option. For example:

Editor.nodes(editor, {
  at: range,
  match: Element.isElement,
})

v0.54.6

Compare Source

v0.54.5

Compare Source

v0.54.4

Compare Source

v0.54.3

Compare Source

v0.54.2

Compare Source

v0.54.1

Compare Source

v0.54.0

Compare Source

BREAKING

The <Slate> onChange handler no longer receives the selection argument. Previously it received (value, selection), now it receives simply (value). Instead, you can access any property of the editor directly (including the value as editor.children). The value/onChange convention is provided purely for form-related use cases that expect it. This is along with the change to how extra props are "controlled". By default they are uncontrolled, but you can pass in any of the other top-level editor properties to take control of them.

The Command and CoreCommand interfaces have been split apart. Previously you could access Command.isCoreCommand, however now this helper lives directly on the core command interface as CoreCommand.isCoreCommand. This makes it more symmetrical with userland commands.

Command checkers have been simplified. Previously Slate exposed command-checking helpers like Command.isInsertTextCommand. However these were verbose and not useful most of the time. Instead, you can now check for CoreCommand.isCoreCommand and then use the command.type property to narrow further. This keeps core more symmetrical with how userland will implement custom commands.

NEW

The <Slate> component is now pseudo-controlled. It requires a value= prop to be passed in which is controlled. However, the selection, marks, history, or any other props are not required to be controlled. They default to being uncontrolled. If your use case requires controlling these extra props you can pass them in and they will start being controlled again. This change was made to make using Slate easier, while still allowing for more complex state to be controlled by core or plugins going forward—state that users don't need to concern themselves with most of time.

The Editor now has a marks property. This property represents text-level formatting that will be applied to the next character that is inserted. This is a common richtext editor behavior, where pressing a Bold button with a collapsed selection turns on "bold" formatting mode, and then typing a character becomes bold. This state isn't stored in the document, and is instead stored as an extra property on the editor itself.


v0.53.0

Compare Source

BREAKING

The slate-schema package has been removed! This decision was made because with the new helpers on the Editor.* interface, and with the changes to normalizeNode in the latest version of Slate, adding constraints using normalizeNode actually leads to more maintainable code than using slate-schema. Previously it was required to keep things from getting too unreadable, but that always came at a large cost of indirection and learning additional APIs. Everything you could do with slate-schema you can do with normalizeNode, and more.

Node matching functions now receive just a Node. Previously they received a NodeEntry tuple, which consisted of [node, path]. However now they receive only a node argument, which makes it easier to write one-off node-checking helpers and pass them in directly as arguments. If you need to ensure a path, lookup the node first.

A few unnecessary helpers were removed. There were a handful of leftovers helpers that were not used anywhere in Slate's core logic, and were very unlikely to be used in userland, so they've been removed to reduce bundle size. You are always free to re-implement them if you truly need them. The list of helpers removed is:

  • Editor.ancestor
  • Node.closest
  • Node.furthest
  • Range.exists
  • Range.isRangeList
  • Range.isRangeMap

v0.52.7

Compare Source

v0.52.6

Compare Source

v0.52.5

Compare Source

v0.52.4

Compare Source

v0.52.3

Compare Source

v0.52.2

Compare Source

v0.52.1

Compare Source

v0.52.0

Compare Source

BREAKING

The slate-schema package now exports a factory. Previously you imported the withSchema function directly from the package, and passed in your schema rules when you called it. However, now you import the defineSchema factory instead which takes your schema rules and returns a custom withSchema plugin function. This way you can still use helpers like compose with the plugin, while pre-defining your custom rules.

The properties validation in the schema is now exhaustive. Previously a properties validation would check any properties you defined, and leave any unknown ones as is. This made it hard to be certain about which properties would end up on a node. Now any non-defined properties are considered invalid. And using an empty {} validation would ensure that there are no custom properties at all.

NEW

The leaves schema validation ensures text-level formatting. You can use it from any higher up element node in the tree, to guarantee that it only contains certain types of text-level formatting on its inner text nodes. For example you could use it to ensure that a code block doesn't allow any of its text to be bolded or italicized.


v0.51.0

Compare Source

BREAKING

The Mark interface has been removed! Previously text-level formatting was stored in an array of unique marks. Now that same formatting is stored directly on the Text nodes themselves. For example instead of:

{
  text: 'A line of text.',
  marks: [{ type: 'bold' }],
}

You now have:

{
  text: 'A line of text.',
  bold: true,
}

And the marks are added and removed from the text nodes using the same Editor.setNodes transform that you use for toggling formatting on block and inline nodes. This greatly simplifies things and makes Slate's core even smaller.

The <Slate> component is now a "controlled" component. This makes things a bit more React-ish, and makes it easier to update the editor's value when new data is received after the initial render. To arrive at the previous "uncontrolled" behavior you'll need to implement it in userland using React's built-in hooks.

Whereas previously you would do:

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

Now you must manage the value and selection yourself, like:

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

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

v0.50.11

Compare Source

v0.50.10

Compare Source

v0.50.9

Compare Source

v0.50.8

Compare Source

v0.50.7

Compare Source

v0.50.6

Compare Source

v0.50.5

Compare Source

v0.50.4

Compare Source

v0.50.3

Compare Source

v0.50.2

Compare Source

v0.50.1

Compare Source

v0.50.0

Compare Source

BREAKING

A complete overhaul. The Slate codebase has had a complete overhaul and many pieces of its core architecture have been reconsidered from the ground up. There are lots of changes. We recommend re-reading the Walkthroughs and Concepts documentation and the Examples to get a sense for everything that has changed. As well as the Migration writeup for what the major changes are.


Warning: Changes past this point refer to the older Slate architecture, based on Immutable.js and without TypeScript. Many things are different in the older architecture and may not apply to the newer one.



Renovate configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

@changeset-bot
Copy link

changeset-bot bot commented Sep 28, 2020

⚠️ No Changeset found

Latest commit: ed5da90

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@renovate renovate bot force-pushed the renovate/slate-react-0.x branch from 40ea46b to ed5da90 Compare September 28, 2020 22:07
@timleslie timleslie closed this Sep 28, 2020
@renovate
Copy link
Contributor Author

renovate bot commented Sep 28, 2020

Renovate Ignore Notification

As this PR has been closed unmerged, Renovate will now ignore this update (^0.59.0). You will still receive a PR once a newer version is released, so if you wish to permanently ignore this dependency, please add it to the ignoreDeps array of your renovate config.

If this PR was closed by mistake or you changed your mind, you can simply rename this PR and you will soon get a fresh replacement PR opened.

@renovate renovate bot deleted the renovate/slate-react-0.x branch September 28, 2020 22:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants