mirror/slate
1
0
Fork 0
mirror of https://github.com/ianstormtaylor/slate.git synced 2025-08-30 18:39:51 +02:00
Code Issues Releases Wiki Activity

fix docs links, closes #1116

Browse Source
This commit is contained in:
Ian Storm Taylor
2017-09-12 08:55:15 -07:00
parent 5c840c78e1
commit 560dbe5038
7 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/Introduction.md
View File

@@ -89,10 +89,10 @@ Slate encourages you to write small, reusable modules. Check out the public ones
### Documentation
If you're using Slate for the first time, check out the [Getting Started](http://docs.slatejs.org/walkthroughs/installing-slate.html) walkthroughs to familiarize yourself with Slate's architecture and mental models. Once you've gotten familiar with those, you'll probably want to check out the full [API Reference](http://docs.slatejs.org/reference/components/editor.html).
If you're using Slate for the first time, check out the [Getting Started](http://docs.slatejs.org/walkthroughs/installing-slate.html) walkthroughs to familiarize yourself with Slate's architecture and mental models. Once you've gotten familiar with those, you'll probably want to check out the full [API Reference](http://docs.slatejs.org/reference/slate-react/editor.html).
- [**Walkthroughs**](http://docs.slatejs.org/walkthroughs/installing-slate.html)
- [**Reference**](http://docs.slatejs.org/reference/components/editor.html)
- [**Reference**](http://docs.slatejs.org/reference/slate-react/editor.html)
- [**FAQ**](http://docs.slatejs.org/general/faq.html)
- [**Resources**](http://docs.slatejs.org/general/resources.html)

8
docs/concepts/plugins.md
View File

@@ -3,18 +3,18 @@
In Slate, all custom logic added to the editor is done via plugins. Plugins have complete control over the schema, the behaviors, and the rendering of the components of the editor. Slate encourages you to break up code into small, reusable modules that can be shared with others, and easily reasoned about.
_To learn more, check out the [Using Plugins guide](../walkthroughs/using-plugins.md), or the [Plugins reference](../reference/plugins/plugins.md)._
_To learn more, check out the [Using Plugins guide](../walkthroughs/using-plugins.md), or the [Plugins reference](../reference/slate-react/plugins.md)._
### The Core Plugin
The "core" plugin that ships with Slate is where the default editing behavior is kept. It performs actions like splitting the current block when `enter` is pressed, or inserting a string of text when the user pastes from their clipboard. But it stops short of anything opinionated, leaving that for userland plugins to add.
_To learn more, check out the [Core Plugin reference](../reference/plugins/core.md)._
_To learn more, check out the [Core Plugin reference](../reference/slate-react/core-plugin.md)._
### The Editor Plugin
Plugins are so central to Slate's architecture, that the properties of the [`<Editor>`](../reference/components/editor.md) that allow you to add custom functionality (eg. `onKeyDown` or `onPaste`) are actually implemented as a plugin too. All of those properties actually just create an implicitly, top-priority plugin that gets added at the beginning of the editor's plugin stack. But you'd never even know it!
Plugins are so central to Slate's architecture, that the properties of the [`<Editor>`](../reference/slate-react/editor.md) that allow you to add custom functionality (eg. `onKeyDown` or `onPaste`) are actually implemented as a plugin too. All of those properties actually just create an implicitly, top-priority plugin that gets added at the beginning of the editor's plugin stack. But you'd never even know it!
_To learn more, check out the [`<Editor>` component reference](../reference/components/editor.md)._
_To learn more, check out the [`<Editor>` component reference](../reference/slate-react/editor.md)._

10
docs/concepts/statelessness-and-immutability.md
View File

@@ -3,7 +3,7 @@
All of the data in Slate is immutable, thanks to [Immutable.js](https://facebook.github.io/immutable-js/). This makes it much easier to reason about complex editing logic, and it makes maintaining a history of changes for undo/redo much simpler.
_To learn more, check out the [`State` model reference](../reference/models/state.md)._
_To learn more, check out the [`State` model reference](../reference/slate/state.md)._
### The `onChange` Handler
@@ -12,13 +12,13 @@ Because of Slate's immutability, you don't actually "set" itself a new state whe
Instead, the new state is propagated to the Slate editor's parent component, who decides what to do with it. Usually, you'll simply give the new state right back to the editor via React's `this.setState()` method, similarly to other internal component state. But that's up to you!
_To learn more, check out the [`<Editor>` component reference](../reference/components/editor.md)._
_To learn more, check out the [`<Editor>` component reference](../reference/slate-react/editor.md)._
### Changes
All of the changes in Slate are applied via [`Changes`](../reference/models/change.md). This makes it possible to enforce some of the constraints that Slate needs to enforce, like requiring that [all leaf nodes be text nodes](./the-document-model.md#leaf-text-nodes). This also makes it possible to implement collaborative editing, where information about changes must be serialized and sent over the network to other editors.
All of the changes in Slate are applied via [`Changes`](../reference/slate/change.md). This makes it possible to enforce some of the constraints that Slate needs to enforce, like requiring that [all leaf nodes be text nodes](./the-document-model.md#leaf-text-nodes). This also makes it possible to implement collaborative editing, where information about changes must be serialized and sent over the network to other editors.
You should never update the `selection` or `document` of an editor other than by using the [`change()`](../reference/models/state.md#change) method of a `State`.
You should never update the `selection` or `document` of an editor other than by using the [`change()`](../reference/slate/state.md#change) method of a `State`.
_To learn more, check out the [`Change` model reference](../reference/models/change.md)._
_To learn more, check out the [`Change` model reference](../reference/slate/change.md)._

8
docs/concepts/the-document-model.md
View File

@@ -6,18 +6,18 @@ A big difference between Slate and other rich-text editors is that Slate is buil
### Node Hierarchy
Each Slate document is made up of [`Document`](../reference/models/document.md), [`Block`](../reference/models/block.md), [`Inline`](../reference/models/inline.md) and [`Text`](../reference/models/text.md) nodes—again, very similar to the DOM.
Each Slate document is made up of [`Document`](../reference/slate/document.md), [`Block`](../reference/slate/block.md), [`Inline`](../reference/slate/inline.md) and [`Text`](../reference/slate/text.md) nodes—again, very similar to the DOM.
The top-level node of a Slate document is the `Document` node. The `Document` then has child `Block` node children.
After that, nesting can occur to any depth. `Block` nodes can contain other `Block` nodes, or they can contain `Inline` or `Text` nodes. And `Inline` nodes can contain other `Inline` nodes or simply `Text` nodes.
Each `Document`, `Block` and `Inline` node implements a [`Node`](../reference/models/node.md) interface, to make working with the nested tree easier.
Each `Document`, `Block` and `Inline` node implements a [`Node`](../reference/slate/node.md) interface, to make working with the nested tree easier.
### Characters & Marks
As the leaves of the tree, `Text` nodes contain both the text content of the document as well as all of the text-level formatting, like **bold** and _italic_. In Slate, that formatting is referred to as [`Marks`](../reference/models/mark.md), and `Marks` are applied to individual [`Characters`](../reference/models/character.md).
As the leaves of the tree, `Text` nodes contain both the text content of the document as well as all of the text-level formatting, like **bold** and _italic_. In Slate, that formatting is referred to as [`Marks`](../reference/slate/mark.md), and `Marks` are applied to individual [`Characters`](../reference/slate/character.md).
### Void Nodes
@@ -31,4 +31,4 @@ Note that even though the node is "void", it will still have an empty text node
One constraint of Slate documents is that the leaf nodes are always `Text` nodes. No `Block` or `Inline` node will ever have no children. It will always have at least an empty text node. (However, you can _render_ text-less nodes, see the [Void Nodes](#void-nodes) section above!)
This constraint means that [`Selections`](../reference/models/selection.md) can always refer to text nodes, and many text-node-level operations are always "safe" regardless of the tree's structure.
This constraint means that [`Selections`](../reference/slate/selection.md) can always refer to text nodes, and many text-node-level operations are always "safe" regardless of the tree's structure.

6
docs/concepts/the-selection-model.md
View File

@@ -1,7 +1,7 @@
# The Selection Model
Slate keeps track of the user's selection in the editor in an immutable data store called a [`Selection`](../reference/models/selection.md). By doing this, it lets Slate manipulate the selection with changes, but still update it in the DOM on `render`.
Slate keeps track of the user's selection in the editor in an immutable data store called a [`Selection`](../reference/slate/selection.md). By doing this, it lets Slate manipulate the selection with changes, but still update it in the DOM on `render`.
### Always References Text
@@ -15,11 +15,11 @@ This makes selections easier to reason about, while still giving us the benefits
### Leaf Blocks
When a selection is used to compute a set of [`Block`](../reference/models/block.md) nodes, by convention those nodes are always the leaf-most `Block` nodes (ie. the lowest `Block` nodes in the tree at their location). This is important, because the nested document model allows for nested `Block` nodes.
When a selection is used to compute a set of [`Block`](../reference/slate/block.md) nodes, by convention those nodes are always the leaf-most `Block` nodes (ie. the lowest `Block` nodes in the tree at their location). This is important, because the nested document model allows for nested `Block` nodes.
This convention makes it much simpler to implement selection and changeation logic, since the user's actions are very often supposed to effect the leaf blocks.
### Trunk Inlines
Unline `Block` nodes, when a selection is used to compute a set of [`Inline`](../reference/models/inline.md) nodes, the trunk-most nodes are used (ie. the highest `Inline` nodes in the tree at their location). This is done for the same reason, that most user actions are supposed to act at the highest level of inline nodes.
Unline `Block` nodes, when a selection is used to compute a set of [`Inline`](../reference/slate/inline.md) nodes, the trunk-most nodes are used (ie. the highest `Inline` nodes in the tree at their location). This is done for the same reason, that most user actions are supposed to act at the highest level of inline nodes.

2
docs/general/faq.md
View File

@@ -14,7 +14,7 @@ One of Slate's core principles is that, unlike most other editors, it does **not
For this most part, this leads to increased flexbility without many downsides, but there are certain cases where you have to do a bit more work. Pasting is one of those cases.
Since Slate knows nothing about your schema, it can't know how to parse pasted HTML content (or other content). So, by default whenever a user pastes content into a Slate editor, it will parse it as plain text. If you want it to be smarter about pasted content, you need to define an [`onPaste`](../reference/components/editor.md#onpaste) handler that parses the content as you wish.
Since Slate knows nothing about your schema, it can't know how to parse pasted HTML content (or other content). So, by default whenever a user pastes content into a Slate editor, it will parse it as plain text. If you want it to be smarter about pasted content, you need to define an [`onPaste`](../reference/slate-react/editor.md#onpaste) handler that parses the content as you wish.
### What can a `Block` node have as its children?

4
docs/walkthroughs/saving-and-loading-html-content.md
View File

@@ -92,9 +92,9 @@ const rules = [
]
```
The `serialize` function should also feel familiar. It's just taking [Slate models](../reference/models) and turning them into React elements, which will then be rendered to an HTML string.
The `serialize` function should also feel familiar. It's just taking [Slate models](../reference/slate) and turning them into React elements, which will then be rendered to an HTML string.
The `object` argument of the `serialize` function will either be a [`Node`](../reference/models/node.md), a [`Mark`](../reference/models/mark.md) or a special immutable [`String`](../reference/serializers/html.md#ruleserialize) object. And the `children` argument is a React element describing the nested children of the object in question, for recursing.
The `object` argument of the `serialize` function will either be a [`Node`](../reference/slate/node.md), a [`Mark`](../reference/slate/mark.md) or a special immutable [`String`](../reference/serializers/html.md#ruleserialize) object. And the `children` argument is a React element describing the nested children of the object in question, for recursing.
Okay, so now our serializer can handle `paragraph` nodes.