1
0
mirror of https://github.com/ianstormtaylor/slate.git synced 2025-07-31 04:20:26 +02:00

Upgrade docs (#1182)

* remove table of contents

* remove more hard-coded table of contents

* remove comparisons, rewrite "why" section to be more general

* update intro
This commit is contained in:
Ian Storm Taylor
2017-09-25 11:50:23 -07:00
committed by GitHub
parent f34a716ee7
commit c98ad903c8
30 changed files with 46 additions and 496 deletions

View File

@@ -45,21 +45,30 @@ _**Slate is currently in beta**. It's useable now, but you might need to pull re
### Why?
Why create Slate? Well... _(Beware: this section has a few of [my](https://github.com/ianstormtaylor) opinions!)_
Before creating Slate, I tried a lot of the other rich text libraries out there. What I found was that while getting simple examples to work might be possible, once you start trying to build something like [Medium](https://medium.com/), [Dropbox Paper](https://www.dropbox.com/paper) or [Canvas](https://usecanvas.com/), you have to resort to very hacky things to get the user experience you want. And some experiences are just impossible. On the way, your codebase becomes harder and harder to maintain.
Before creating Slate, I tried a lot of the other rich text libraries out there—[**Draft.js**](https://facebook.github.io/draft-js/), [**Prosemirror**](http://prosemirror.net/), [**Quill**](http://quilljs.com/), etc. What I found was that while getting simple examples to work was easy enough, once you started trying to build something like [Medium](https://medium.com/), [Dropbox Paper](https://www.dropbox.com/paper) or [Google Docs](https://www.google.com/docs/about/), you ran into deeper issues, like...
Here's how Slate compares to some of the existing editors out there:
- **The editor's "schema" was hardcoded and hard to customize.** Things like bold and italic were supported out of the box, but what about comments, or embeds, or even more domain-specific needs?
- [**Draft.js**](https://facebook.github.io/draft-js/) — Slate borrowed a few concepts from Draft.js, namely its event system, its use of Immutable.js and React, and its goal of being a "framework" for creating editors. It also borrowed its plugin-centric design from the [Draft.js Plugins](https://github.com/draft-js-plugins/draft-js-plugins) project. But the issues I ran into while using Draft.js were: that lots of the logic around the schema is hardcoded in "core" and difficult to customize, that the transform API is complex to use and not suited to collaborative editing in the future, that serialization isn't considered by the core library in a nice way, that the flat document model made certain behaviors impossible, and that lots of the API feels very heavy to work with.
- **Transforming the documents programmatically was very convoluted.** Writing as a user may have been nice, but performing programmatic changes, which is critical for building advanced behaviors, was needlessly complex.
- [**Prosemirror**](http://prosemirror.net/) — Slate borrowed a few concepts from Prosemirror, namely its nested document tree, its use of "schemas", and its transform model for collaboration. And since then, Prosemirror has become slightly more like Slate by adopting a barebones "core" and plugin system. But some of the issues I ran into while using it were: that the API can be hard to understand, that it implements its own custom view layer, that the documentation isn't simple to use, and that the source is often very complex and hard to read for insights when you get stuck. (It's still in beta though and many of these things might change!)
- **Serializing to HTML, Markdown, etc. seemed like an afterthought.** Simple things like transforming a document to HTML or Markdown involved writing lots of boilerplate code, for what seemed like very common use cases.
- [**Quill**](http://quilljs.com/) — I never used Quill directly, so my hesitations about it are solely from considering it in early stages—and it has changed since then! The issues I saw with it were: that the concept of "toolbars" is too coupled with the editor itself, that the configuration is too coupled to HTML classes and DOM nodes, that the idea of "formats" and "toolbars" being linked is limiting, and generally that too much "core" logic is given special privileges and is hard to customize.
- **Relearning a new view layer seemed inefficient and limiting.** Editors were re-implementing view layers instead of using existing technologies like React, which forced you to learn a whole new system with it's own restrictions and gotchas.
- _For more potentially useless comparisons check out the [Comparisons](./docs/general/comparisons.md) document..._
- **Collaborative editing wasn't designed for in advance.** Often the editor's internal representation of data made it impossible to use to for a realtime, collaborative editing use case without basically rewriting the editor.
Of course those are my own opinions, and if those libraries solve your needs, use them! But if you've tried using any of those libraries you might have run into similar problems. If so, you might like Slate. Which brings me to how Slate solves all of that...
- **The repostories were monolithic, not small and reusable.** The code bases for many of the editors often didn't expose the internal tooling that could have been re-used by developers, leading to having to reinvent the wheel.
- **Building complex, nested documents was impossible.** Many editors were designed around simplistic "flat" documents, making things like tables, embeds and captions difficult to reason about and sometimes impossible.
Of course not every editor exhibits all of these issues, but if you've tried using another editor you might have run into similar problems. To get around the limitations of their API's and achieve the user experience you're after, you have to resort to very hacky things. And some experiences are just plain impossible to achieve.
If that sounds familiar, you might like Slate.
Which brings me to how Slate solves all of that...
<br/>

View File

@@ -1,7 +1,7 @@
# Introduction
# Slate
[Slate](http://slatejs.org) is a _completely_ customizable framework for building rich text editors. [GitHub ⬈](https://github.com/ianstormtaylor/slate)
[Slate](http://slatejs.org) is a _completely_ customizable framework for building rich text editors.
Slate lets you build rich, intuitive editors like those in [Medium](https://medium.com/), [Dropbox Paper](https://www.dropbox.com/paper) or [Canvas](https://usecanvas.com/)—which are becoming table stakes for applications on the web—without your codebase getting mired in complexity.
@@ -14,11 +14,30 @@ _**Slate is currently in beta**. It's useable now, but you might need to pull re
### Why?
Why create Slate? Well... _(Beware: this section has a few of [my](https://github.com/ianstormtaylor) opinions!)_
Before creating Slate, I tried a lot of the other rich text libraries out there. What I found was that while getting simple examples to work might be possible, once you start trying to build something like [Medium](https://medium.com/), [Dropbox Paper](https://www.dropbox.com/paper) or [Canvas](https://usecanvas.com/), you have to resort to very hacky things to get the user experience you want. And some experiences are just impossible. On the way, your codebase becomes harder and harder to maintain.
Before creating Slate, I tried a lot of the other rich text libraries out there—[**Draft.js**](https://facebook.github.io/draft-js/), [**Prosemirror**](http://prosemirror.net/), [**Quill**](http://quilljs.com/), etc. What I found was that while getting simple examples to work was easy enough, once you started trying to build something like [Medium](https://medium.com/), [Dropbox Paper](https://www.dropbox.com/paper) or [Google Docs](https://www.google.com/docs/about/), you ran into deeper issues, like...
Of course those are my own opinions, and if those libraries solve your needs, use them! But if you've tried using any of those libraries you might have run into similar problems. If so, you might like Slate. Which brings me to how Slate solves all of that...
- **The editor's "schema" was hardcoded and hard to customize.** Things like bold and italic were supported out of the box, but what about comments, or embeds, or even more domain-specific needs?
- **Transforming the documents programmatically was very convoluted.** Writing as a user may have been nice, but performing programmatic changes, which is critical for building advanced behaviors, was needlessly complex.
- **Serializing to HTML, Markdown, etc. seemed like an afterthought.** Simple things like transforming a document to HTML or Markdown involved writing lots of boilerplate code, for what seemed like very common use cases.
- **Relearning a new view layer seemed inefficient and limiting.** Editors were re-implementing view layers instead of using existing technologies like React, which forced you to learn a whole new system with it's own restrictions and gotchas.
- **Collaborative editing wasn't designed for in advance.** Often the editor's internal representation of data made it impossible to use to for a realtime, collaborative editing use case without basically rewriting the editor.
- **The repostories were monolithic, not small and reusable.** The code bases for many of the editors often didn't expose the internal tooling that could have been re-used by developers, leading to having to reinvent the wheel.
- **Building complex, nested documents was impossible.** Many editors were designed around simplistic "flat" documents, making things like tables, embeds and captions difficult to reason about and sometimes impossible.
Of course not every editor exhibits all of these issues, but if you've tried using another editor you might have run into similar problems. To get around the limitations of their API's and achieve the user experience you're after, you have to resort to very hacky things. And some experiences are just plain impossible to achieve.
If that sounds familiar, you might like Slate.
Which brings me to how Slate solves all of that...
<br/>

View File

@@ -1,16 +0,0 @@
# Concepts
This document explain the core concepts that Slate is built on around. It is helpful to read it through in it's entirety to get a good mental model for how Slate works.
- [Statelessness & Immutability](./statelessness-and-immutability.md)
- [The Document Model](./the-document-model.md)
- [The Selection Model](./the-selection-model.md)
- [Plugins](./plugins.md)
- [FAQ](./faq.md)

View File

@@ -1,18 +0,0 @@
# Comparisons
A series of comparisons with other rich text editors, in a highly-opinionated way, and some of which without actual use. If these things mesh with your own experiences with those editors, then you might understand some of the reasons behind why Slate was created. If not, I'm sorry, feel free to contribute edits.
- [**Draft.js**](https://facebook.github.io/draft-js/) — Slate borrowed a few concepts from Draft.js, namely its event system, its use of Immutable.js and React, and its goal of being a "framework" for creating editors. It also borrowed its plugin-centric design from the [Draft.js Plugins](https://github.com/draft-js-plugins/draft-js-plugins) project. But the issues I ran into while using Draft.js were: that lots of the logic around the schema is hardcoded in "core" and difficult to customize, that the transform API is complex to use and not suited to collaborative editing in the future, that serialization isn't considered by the core library in a nice way, that the flat document model made certain behaviors impossible, and that lots of the API feels very heavy to work with.
- [**Prosemirror**](http://prosemirror.net/) — Slate borrowed a few concepts from Prosemirror, namely its nested document tree, its use of "schemas", and its transform model for collaboration. And since then, Prosemirror has become slightly more like Slate by adopting a barebones "core" and plugin system. But some of the issues I ran into while using it were: that the API can be hard to understand, that it implements its own custom view layer, that the documentation isn't simple to use, and that the source is often very complex and hard to read for insights when you get stuck. (It's still in beta though and many of these things might change!)
- [**Quill**](http://quilljs.com/) — I never used Quill directly, so my hesitations about it are solely from considering it in early stages—and it has changed since then. The issues I see with it are: that the concept of "toolbars" is too coupled with the editor itself, that the configuration is too coupled to HTML classes and DOM nodes, that the idea of "formats" and "toolbars" being linked is limiting, and generally that too much "core" logic is given special privileges and is hard to customize.
- [**Trix**](https://trix-editor.org/) — I never used Trix directly either, so my issues with it are solely from considering it in early stages. The issues I found with it are: that it aims to be simple by limiting functionality instead of by limiting its own scope, that many behaviors are just impossible to implement with it, that it's too coupled to the DOM, and that the flat document model is limiting.
- [**Medium Editor**](https://yabwe.github.io/medium-editor/) — I never used the Medium Editor directly either, so my issues with it are solely from considering it in early stages. The issues I found with it are: that it doesn't actually pave over `contenteditable`, so you continue wrestling with the DOM, that the concept of a "toolbar" is tightly coupled with core in many respects making it harder to customize, that the extension system requires learning an entirely new view abstraction, and that the editor relying on the DOM's HTML as its data model makes collaborative editing much more difficult.
- [**Scribe**](https://github.com/guardian/scribe) — I added Scribe to this list after creating Slate, so the issues with it are solely from reading their documentation. In terms of plugin architectures, Slate and Scribe are very similar in striving to move as much possible logic from "core" into plugins as possible. The issues I found with Scribe are: that it works directly on the DOM and its goal is to simply "fix" contenteditable such that all userland and plugin logic still has to account for x-browser differences, that its data model is tied to the DOM so serialization to formats besides HTML is more complex, that without a backing data model collaborative editing is much more difficult to layer in, and that it lacks broader mobile and browser support.
- [**Mobiledoc Kit**](https://github.com/bustlelabs/mobiledoc-kit) — I added Mobiledoc Kit to this list after creating Slate as well, so the issues with it are solely from reading their documentation. In terms of the goal of customizability, Slate and Mobiledoc Kit are similar in striving to give the developer control over the rendering and serialization methods. The issues I found with Mobiledoc Kit are: that the JSON representation of content is complex to wrap your head around, that the naming terminology chosen doesn't build on prior art to make it easier to pick up, that the event handler architecture makes assumptions about use cases which leads to complexity, that the flat document model makes certain complex experiences difficult to build, and that core library makes assumptions about the behavior of specific types of nodes in the content.

View File

@@ -3,11 +3,6 @@
Every Slate editor has a "schema" associated with it, which contains information about the structure of its content. It lets you specify how to render each different type of node. And for more advanced use cases it lets you enforce rules about what the content of the editor can and cannot be.
- [Rules](#rules)
- [Components](#components)
- [Decorators](#decorators)
- [Validations](#validations)
## Rules

View File

@@ -9,18 +9,6 @@ The HTML serializer lets you parse and stringify arbitrary HTML content, based o
For an example of the HTML serializer in action, check out the [`paste-html` example](../../../examples/paste-html).
- [Example](#example)
- [Properties](#properties)
- [`rules`](#rules)
- [`defaultBlock`](#defaultblock)
- [`parseHtml`](#parsehtml)
- [Methods](#methods)
- [`deserialize`](#deserialize)
- [`serialize`](#serialize)
- [Rules](#rules)
- [`rule.deserialize`](#ruledeserialize)
- [`rule.serialize`](#ruleserialize)
## Example

View File

@@ -8,11 +8,6 @@ import { createHyperscript } from 'slate-hyperscript'
A hyperscript helper for writing Slate documents with JSX!
- [Example](#example)
- [Exports](#methods)
- [`h`](#h)
- [`createHyperscript`](#createhyperscript)
## Example

View File

@@ -7,11 +7,6 @@ import Plain from 'slate-plain-serializer'
A serializer that converts a Slate [`State`](../slate/state.md) to and from a plain text string.
- [Example](#example)
- [Static Methods](#methods)
- [`Plain.deserialize`](#plaindeserialize)
- [`Plain.serialize`](#plainserialize)
## Example

View File

@@ -7,31 +7,6 @@ import Types from 'slate-prop-types'
A set of React prop types for Slate editors and plugins.
- [Example](#example)
- [Exports](#exports)
- [`block`](#block)
- [`blocks`](#blocks)
- [`change`](#change)
- [`character`](#character)
- [`characters`](#characters)
- [`data`](#data)
- [`document`](#document)
- [`history`](#history)
- [`inline`](#inline)
- [`inlines`](#inlines)
- [`mark`](#mark)
- [`marks`](#marks)
- [`node`](#node)
- [`nodes`](#nodes)
- [`range`](#range)
- [`ranges`](#ranges)
- [`schema`](#schema)
- [`selection`](#selection)
- [`stack`](#stack)
- [`state`](#state)
- [`text`](#text)
- [`texts`](#texts)
## Example
@@ -73,7 +48,7 @@ Ensure that a value is a Slate `Character`.
### `characters`
Ensure that a value is an immutable `List` of Slate `Character` objects.
Ensure that a value is an immutable `List` of Slate [`Character`](../slate/character.md) objects.
### `data`
@@ -101,7 +76,7 @@ Ensure that a value is a Slate `Mark`.
### `marks`
Ensure that a value is an immutable `Set` of Slate `Mark` objects.
Ensure that a value is an immutable `Set` of Slate [`Mark`](../slate/mark.md) objects.
### `node`
@@ -109,7 +84,7 @@ Ensure that a value is a Slate `Node`.
### `nodes`
Ensure that a value is an immutable `List` of Slate `Node` objects.
Ensure that a value is an immutable `List` of Slate [`Node`](../slate/mark.md) objects.
### `range`
@@ -117,7 +92,7 @@ Ensure that a value is a Slate `Range`.
### `ranges`
Ensure that a value is an immutable `List` of Slate `Range` objects.
Ensure that a value is an immutable `List` of Slate [`Range`](../slate/range.md) objects.
### `schema`
@@ -137,8 +112,8 @@ Ensure that a value is a Slate `State`.
### `text`
Ensure that a value is a Slate `Text`.
Ensure that a value is a Slate [`Text`](../slate/text.md).
### `texts`
Ensure that a value is a Slate `Texts`.
Ensure that a value is an immutable `List` of Slate [`Text`](../slate/text.md) objects.

View File

@@ -3,9 +3,6 @@
Slate's editor is very unopinionated. The only logic it handles by default is logic associated with the `contenteditable` functionality itself—managing text, selections, etc. That logic in contained in a single plugin, called the "core" plugin.
- [Default Behavior](#behavior)
- [Overriding Defaults](#overriding-defaults)
## Default Behavior

View File

@@ -3,16 +3,6 @@
Slate will render custom nodes for [`Block`](../slate/block.md) and [`Inline`](../slate/inline.md) models, based on what you pass in as your schema. This allows you to completely customize the rendering behavior of your Slate editor.
- [Properties](#properties)
- [`attributes`](#attributes)
- [`children`](#children)
- [`editor`](#editor)
- [`isSelected`](#isselected)
- [`node`](#node)
- [`parent`](#parent)
- [`readOnly`](#readonly)
- [`state`](#state)
- [`shouldNodeComponentUpdate`](#shouldnodecomponentupdate)
## Properties

View File

@@ -7,41 +7,6 @@ import { Editor } from 'slate-react'
The top-level React component that renders the Slate editor itself.
- [Properties](#properties)
- [`autoCorrect`](#autocorrect)
- [`autoFocus`](#autofocus)
- [`className`](#classname)
- [`onChange`](#onchange)
- [`plugins`](#plugins)
- [`readOnly`](#readonly)
- [`role`](#role)
- [`spellCheck`](#spellcheck)
- [`state`](#state)
- [`style`](#style)
- [`tabIndex`](#tabindex)
- [Placeholder Properties](#placeholder-properties)
- [`placeholder`](#placeholder)
- [`placeholderClassName`](#placeholderclassname)
- [`placeholderStyle`](#placeholderstyle)
- [Plugin-like Properties](#plugin-like-properties)
- [`onBeforeInput`](#onbeforeinput)
- [`onBlur`](#onblur)
- [`onFocus`](#onfocus)
- [`onCopy`](#oncopy)
- [`onCut`](#oncut)
- [`onDrop`](#ondrop)
- [`onKeyDown`](#onkeydown)
- [`onKeyUp`](#onkeyup)
- [`onPaste`](#onpaste)
- [`onSelect`](#onselect)
- [`schema`](#schema)
- [Methods](#methods)
- [`blur`](#blur)
- [`focus`](#focus)
- [`getSchema()`](#getschema)
- [`getState()`](#getstate)
- [`onChange(change)`](#onchange)
- [`change`](#change)
## Properties

View File

@@ -7,15 +7,6 @@ import { Placeholder } from 'slate-react'
A simple component that adds a placeholder to a node. It encapsulates all of the Slate-related logic that determines when to render the placeholder, so you don't have to think about it.
- [Properties](#properties)
- [`children`](#children)
- [`className`](#className)
- [`firstOnly`](#firstOnly)
- [`node`](#node)
- [`parent`](#parent)
- [`state`](#state)
- [`style`](#style)
## Properties

View File

@@ -7,24 +7,6 @@ Each editor has a "middleware stack" of plugins, which has a specific order.
When the editor needs to resolve a plugin-related handler, it will loop through its plugin stack, searching for the first plugin that successfully returns a value. After receiving that value, the editor will **not** continue to search the remaining plugins; it returns early. If you'd like for the stack to continue, a plugin handler should return `undefined`.
- [Conventions](#conventions)
- [Event Handler Properties](#event-handle-properties)
- [`onBeforeInput`](#onbeforeinput)
- [`onBlur`](#onblur)
- [`onFocus`](#onfocus)
- [`onCopy`](#oncopy)
- [`onCut`](#oncut)
- [`onDrop`](#ondrop)
- [`onKeyDown`](#onkeydown)
- [`onKeyUp`](#onkeyup)
- [`onPaste`](#onpaste)
- [`onSelect`](#onselect)
- [Other Properties](#other-properties)
- [`onChange`](#onchange)
- [`onBeforeChange`](#onbeforechange)
- [`render`](#render)
- [`schema`](#schema)
## Conventions

View File

@@ -7,8 +7,6 @@ import { findDOMNode } from 'slate-react'
React-specific utility functions for Slate that may be useful in certain use cases.
- [`findDOMNode`](#finddomnode)
## Functions

View File

@@ -7,18 +7,6 @@ import Simulator from 'slate-simulator'
A simulator to help writing tests for Slate editors and plugins.
- [Example](#example)
- [Methods](#methods)
- [`beforeInput`](#beforeinput)
- [`blur`](#blur)
- [`copy`](#copy)
- [`cut`](#cut)
- [`drop`](#drop)
- [`focus`](#focus)
- [`keyDown`](#keydown)
- [`paste`](#paste)
- [`select`](#select)
## Example

View File

@@ -9,24 +9,6 @@ A block node in a Slate [`Document`](./document.md). Block nodes implement the [
Block nodes may contain nested block nodes, inline nodes, and text nodes—just like in the DOM. They always contain at least one text node child.
- [Properties](#properties)
- [`data`](#data)
- [`isVoid`](#isvoid)
- [`key`](#key)
- [`nodes`](#nodes)
- [`type`](#type)
- [Computed Properties](#computed-properties)
- [`kind`](#kind)
- [`text`](#text)
- [Static Methods](#static-methods)
- [`Block.create`](#blockcreate)
- [`Block.createList`](#blockcreatelist)
- [`Block.fromJSON`](#blockfromjson)
- [`Block.isBlock`](#blockisblock)
- [Node Methods](#node-methods)
- [Instance Methods](#instance-methods)
- [`toJSON`](#tojson)
## Properties

View File

@@ -11,89 +11,6 @@ All changes are performed through `Change` objects, so that a history of changes
Change methods can either operate on the [`Document`](./document.md), the [`Selection`](./selection.md), or both at once.
- [Properties](#properties)
- [`state`](#state)
- [Methods](#methods)
- [`apply`](#apply)
- [`call`](#call)
- [Current State Changes](#current-state-changes)
- [`deleteBackward`](#deletebackward)
- [`deleteForward`](#deleteforward)
- [`delete`](#delete)
- [`insertBlock`](#insertblock)
- [`insertFragment`](#insertfragment)
- [`insertInline`](#insertinline)
- [`insertText`](#inserttext)
- [`addMark`](#addmark)
- [`setBlock`](#setblock)
- [`setInline`](#setinline)
- [`splitBlock`](#splitblock)
- [`splitInline`](#splitinline)
- [`removeMark`](#removemark)
- [`toggleMark`](#togglemark)
- [`unwrapBlock`](#unwrapblock)
- [`unwrapInline`](#unwrapinline)
- [`wrapBlock`](#wrapblock)
- [`wrapInline`](#wrapinline)
- [`wrapText`](#wraptext)
- [Selection Changes](#selection-changes)
- [`blur`](#blur)
- [`collapseTo{Edge}Of`](#collapsetoedgeof)
- [`collapseTo{Edge}Of{Direction}Block`](#collapsetoedgeofdirectionblock)
- [`collapseTo{Edge}Of{Direction}Text`](#collapsetoedgeofdirectiontext)
- [`collapseTo{Edge}`](#collapsetoedge)
- [`extendTo{Edge}Of`](#extendtoedgeof)
- [`extend`](#extend)
- [`flip`](#flip)
- [`focus`](#focus)
- [`move`](#move)
- [`move{Edge}`](#moveedge)
- [`moveOffsetsTo`](#moveoffsetsto)
- [`moveToRangeOf`](#movetorangeof)
- [`select`](#select)
- [`selectAll`](#selectall)
- [`deselect`](#deselect)
- [Node Changes](#node-changes)
- [`addMarkByKey`](#addmarkbykey)
- [`insertNodeByKey`](#insertnodebykey)
- [`insertFragmentByKey`](#insertfragmentbykey)
- [`insertTextByKey`](#inserttextbykey)
- [`moveNodeByKey`](#movenodebykey)
- [`removeMarkByKey`](#removemarkbykey)
- [`removeNodeByKey`](#removenodebykey)
- [`removeTextByKey`](#removetextbykey)
- [`setMarkByKey`](#setmarkbykey)
- [`setNodeByKey`](#setnodebykey)
- [`splitNodeByKey`](#splitnodebykey)
- [`unwrapInlineByKey`](#unwrapinlinebykey)
- [`unwrapBlockByKey`](#unwrapblockbykey)
- [`unwrapNodeByKey`](#unwrapnodebykey)
- [`wrapBlockByKey`](#wrapblockbykey)
- [`wrapInlineByKey`](#wrapinlinebykey)
- [Document Changes](#document-changes)
- [`deleteAtRange`](#deleteatrange)
- [`deleteBackwardAtRange`](#deletebackwardatrange)
- [`deleteForwardAtRange`](#deleteforwardatrange)
- [`insertBlockAtRange`](#insertblockatrange)
- [`insertFragmentAtRange`](#insertfragmentatrange)
- [`insertInlineAtRange`](#insertinlineatrange)
- [`insertTextAtRange`](#inserttextatrange)
- [`addMarkAtRange`](#addmarkatrange)
- [`setBlockAtRange`](#setblockatrange)
- [`setInlineAtRange`](#setinlineatrange)
- [`splitBlockAtRange`](#splitblockatrange)
- [`splitInlineAtRange`](#splitinlineatrange)
- [`removeMarkAtRange`](#removemarkatrange)
- [`toggleMarkAtRange`](#togglemarkatrange)
- [`unwrapBlockAtRange`](#unwrapblockatrange)
- [`unwrapInlineAtRange`](#unwrapinlineatrange)
- [`wrapBlockAtRange`](#wrapblockatrange)
- [`wrapInlineAtRange`](#wrapinlineatrange)
- [`wrapTextAtRange`](#wraptextatrange)
- [History Changes](#history-changes)
- [`redo`](#redo)
- [`undo`](#undo)
## Properties

View File

@@ -9,17 +9,6 @@ A character in a [`Text`](./text.md) node.
Characters are how Slate associates [`Marks`](./mark.md) with a range of text, for formatting.
- [Properties](#properties)
- [`marks`](#marks)
- [`text`](#text)
- [Static Methods](#static-methods)
- [`Character.create`](#charactercreate)
- [`Character.createList`](#charactercreatelist)
- [`Character.fromJSON`](#characterfromjson)
- [`Character.isCharacter`](#characterischaracter)
- [Instance Methods](#instance-methods)
- [`toJSON`](#tojson)
## Properties

View File

@@ -9,10 +9,6 @@ Data is simply a thin wrapper around [`Immutable.Map`](https://facebook.github.i
A data object can have any properties associated with it.
- [Static Methods](#static-methods)
- [`Data.create`](#datacreate)
- [`Data.fromJSON`](#datafromjson)
## Static Methods

View File

@@ -11,20 +11,6 @@ Documents are made up of block nodes, inline nodes, and text nodes—just like i
In some places, you'll see mention of "fragments", which are also `Document` objects, just that aren't attached to the main `State`. For example, when cutting-and-pasting a selection of content, that content will be referred to as a document "fragment".
- [Properties](#properties)
- [`data`](#data)
- [`nodes`](#nodes)
- [Computed Properties](#computed-properties)
- [`kind`](#kind)
- [`text`](#text)
- [Static Methods](#static-methods)
- [`Document.create`](#documentcreate)
- [`Document.fromJSON`](#documentfromjson)
- [`Document.isDocument`](#documentisdocument)
- [Node Methods](#node-methods)
- [Instance Methods](#instance-methods)
- [`toJSON`](#tojson)
## Properties

View File

@@ -9,24 +9,6 @@ A inline node in a Slate [`Document`](./document.md). Inline nodes implement the
Inline nodes may contain nested inline nodes and text nodes—just like in the DOM. They always contain at least one text node child.
- [Properties](#properties)
- [`data`](#data)
- [`isVoid`](#isvoid)
- [`key`](#key)
- [`nodes`](#nodes)
- [`type`](#type)
- [Computed Properties](#computed-properties)
- [`kind`](#kind)
- [`text`](#text)
- [Static Methods](#static-methods)
- [`Inline.create`](#inlinecreate)
- [`Inline.createList`](#inlinecreatelist)
- [`Inline.fromJSON`](#inlinefromjson)
- [`Inline.isInline`](#inlineisinline)
- [Node Methods](#node-methods)
- [Instance Methods](#instance-methods)
- [`toJSON`](#tojson)
## Properties

View File

@@ -7,17 +7,6 @@ import { Mark } from 'slate'
A formatting mark that can be associated with [`Characters`](./mark.md). Marks are how Slate represents rich formatting like **bold** or _italic_.
- [Properties](#properties)
- [`data`](#data)
- [`type`](#type)
- [Static Methods](#static-methods)
- [`Mark.create`](#markcreate)
- [`Mark.createSet`](#markcreateset)
- [`Mark.fromJSON`](#markfromjson)
- [`Mark.isMark`](#markismark)
- [Instance Methods](#instance-methods)
- [`toJSON`](#tojson)
## Properties

View File

@@ -3,45 +3,6 @@
`Node` is not a publicly accessible module, but instead an interface that [`Document`](./document.md), [`Block`](./block.md) and [`Inline`](./inline.md) all implement.
- [Properties](#properties)
- [`nodes`](#nodes)
- [Computed Properties](#computed-properties)
- [`kind`](#kind)
- [`text`](#text)
- [Methods](#methods)
- [`filterDescendants`](#filterdescendants)
- [`findDescendant`](#finddescendant)
- [`getBlocksAtRange`](#getblocksatrange)
- [`getBlocks`](#getblocks)
- [`getCharactersAtRange`](#getcharactersatrange)
- [`getChild`](#getchild)
- [`getClosestBlock`](#getclosestblock)
- [`getClosestInline`](#getclosestinline)
- [`getClosest`](#getclosest)
- [`getDepth`](#getdepth)
- [`getDescendant`](#getdescendant)
- [`getFirstText`](#getfirsttext)
- [`getFragmentAtRange`](#getfragmentatrange)
- [`getFurthestAncestor`](#getfurthestancestor)
- [`getFurthestBlock`](#getfurthestblock)
- [`getFurthestInline`](#getfurthestinline)
- [`getFurthestOnlyChildAncestor`](#getfurthestonlychildancestor)
- [`getFurthestBlock`](#getfurthestblock)
- [`getInlinesAtRange`](#getinlinesatrange)
- [`getLastText`](#getlasttext)
- [`getMarksAtRange`](#getmarksatrange)
- [`getNextBlock`](#getnextblock)
- [`getNextSibling`](#getnextsibling)
- [`getNextText`](#getnexttext)
- [`getParent`](#getparent)
- [`getPreviousBlock`](#getpreviousblock)
- [`getPreviousSibling`](#getprevioussibling)
- [`getPreviousText`](#getprevioustext)
- [`getTextAtOffset`](#gettextatoffset)
- [`getTextsAtRange`](#gettextsatrange)
- [`hasChild`](#haschild)
- [`hasDescendant`](#hasdescendant)
## Properties

View File

@@ -1,21 +1,8 @@
# Schemas
# `Schema`
Every Slate editor has a "schema" associated with it, which contains information about the structure of its content. It lets you specify how to render each different type of node. And for more advanced use cases it lets you enforce rules about what the content of the editor can and cannot be.
- [Properties](#properties)
- [`marks`](#marks)
- [`nodes`](#nodes)
- [`rules`](#rules)
- [Rule Properties](#rule-properties)
- [`decorate`](#decorate)
- [`match`](#match)
- [`normalize`](#normalize)
- [`render`](#render)
- [`validate`](#validate)
- [Static Methods](#static-methods)
- [`Schema.isSchema`](#schemaisschema)
## Properties

View File

@@ -11,36 +11,6 @@ The "anchor" is the fixed point in a selection, and the "focus" is the non-fixed
Often times, you don't need to specifically know which point is the "anchor" and which is the "focus", and you just need to know which comes first and last in the document. For these cases, there are many convenience equivalent properties and methods referring to the "start" and "end" points.
- [Properties](#properties)
- [`anchorKey`](#anchorkey)
- [`anchorOffset`](#anchoroffset)
- [`focusKey`](#focuskey)
- [`focusOffset`](#focusoffset)
- [`isBackward`](#isbackward)
- [`isFocused`](#isfocused)
- [Computed Properties](#computed-properties)
- [`endKey`](#endkey)
- [`endOffset`](#endoffset)
- [`isBlurred`](#isblurred)
- [`isCollapsed`](#iscollapsed)
- [`isExpanded`](#isExpanded)
- [`isForward`](#isForward)
- [`startKey`](#startkey)
- [`startOffset`](#startoffset)
- [Static Methods](#static-methods)
- [`Selection.create`](#selectioncreate)
- [`Selection.fromJSON`](#selectionfromjson)
- [`Selection.isSelection`](#selectionisselection)
- [Instance Methods](#instance-methods)
- [`toJSON`](#tojson)
- [Checking Methods](#checking-methods)
- [`has{Edge}AtEndOf`](#hasedgeatendof)
- [`has{Edge}AtStartOf`](#hasedgeatstartof)
- [`has{Edge}Between`](#hasedgebetween)
- [`has{Edge}In`](#hasedgein)
- [`isAtEndOf`](#isatendof)
- [`isAtStartOf`](#isatstartof)
## Properties

View File

@@ -11,38 +11,6 @@ All changes to the document and selection are also performed through the state o
For convenience, in addition to changes, many of the [`Selection`](./selection.md) and [`Document`](./document.md) properties are exposed as proxies on the `State` object.
- [Properties](#properties)
- [`document`](#document)
- [`selection`](#selection)
- [Computed Properties](#computed-properties)
- [`{edge}Text`](#edgetext)
- [`{edge}Block`](#edgeblock)
- [`marks`](#marks)
- [`activeMarks`](#activeMarks)
- [`blocks`](#blocks)
- [`fragment`](#fragment)
- [`inlines`](#inlines)
- [`texts`](#texts)
- [`hasUndos`](#hasundos)
- [`hasRedos`](#hasredos)
- [Selection-like Properties](#selection-like-properties)
- [`{edge}Key`](#edgekey)
- [`{edge}Offset`](#edgeoffset)
- [`isBackward`](#isbackward)
- [`isBlurred`](#isblurred)
- [`isCollapsed`](#iscollapsed)
- [`isExpanded`](#isExpanded)
- [`isFocused`](#isfocused)
- [`isForward`](#isForward)
- [`isEmpty`](#isEmpty)
- [Static Methods](#static-methods)
- [`State.create`](#statecreate)
- [`State.fromJSON`](#statefromjson)
- [`State.isState`](#stateisstate)
- [Instance Methods](#instance-methods)
- [`change`](#change)
- [`toJSON`](#tojson)
## Properties

View File

@@ -7,18 +7,6 @@ import { Text } from 'slate'
A text node in a Slate [`Document`](./document.md). Text nodes are always the bottom-most leaves in the document, just like in the DOM.
- [Properties](#properties)
- [`characters`](#characters)
- [`key`](#key)
- [Computed Properties](#computed-properties)
- [`kind`](#kind)
- [`text`](#text)
- [Static Methods](#static-methods)
- [`Text.create`](#textcreate)
- [`Text.fromJSON`](#textfromjson)
- [`Text.isText`](#textistext)
- [Instance Methods](#instance-methods)
- [`toJSON`](#tojson)
## Properties

View File

@@ -10,9 +10,6 @@ import {
Utility functions that ship with Slate that may be useful for certain use cases.
- [`resetKeyGenerator`](#resetkeygenerator)
- [`setKeyGenerator`](#setkeygenerator)
## Functions

View File

@@ -1,15 +0,0 @@
# Walkthroughs
These walkthroughs introduce you to the different parts of Slate in a step-by-step way that build on each other, perfect for getting started. We recommend reading them in order, start to finish!
- [Installing Slate](./installing-slate.md)
- [Using the Bundled Source](./using-the-bundled-source.md)
- [Adding Event Handlers](./adding-event-handlers.md)
- [Defining Custom Block Nodes](./defining-custom-block-nodes.md)
- [Applying Custom Formatting](./applying-custom-formatting.md)
- [Using Plugins](./using-plugins.md)
- [Saving to a Database](./saving-to-a-database.md)
- [Saving and Loading HTML Content](./saving-and-loading-html-content.md)
_If you have an idea for a walkthrough, or notice something that isn't clear, submit a pull request!_