
To get started, use the following command in whatever directory you want to initialise the project in:Ĭonst handleChange = (value : Node ) : void =>, ) Ī few notes: cloneRange() returns a new Range object so that we can alter the start of it without affecting our current selection. We’ll be using the excellent Create-React-App for initialising this project. Updates to the tutorial will be reflected here. This tutorial uses Slate 0.57.1, I recommend that this is the version that you use when following along.

This has stabilised somewhat since the start of 2020, but it is not possible to guarantee that this will remain the case forever until version 1.0.0. Slate is still in beta and has undergone a number of breaking changes over the past few months. A quick note on Slate.js beta and breaking changes I would also expect that you’ve run through the Slate.js walkthrough as it gives a good overview of styling nodes and applying custom formatting - which we do not touch on here. I like this tutorial project because it should give you the necessary skills to build upon it to create something pretty cool!īefore we begin, this tutorial expects that you have a basic knowledge of React, ES6 and Typescript syntax (we keep the TS pretty simple here though, as it’s more for the developer experience). On top of that, there isn’t any typescript documentation for Slate as it stands, so this can also act as a primer if you want to use Slate with TS in your future projects. We’ll do it all in Typescript to take advantage of Slate.js’ excellent type definitions.

Luckily, there are frameworks out there that take much of the hassle out of using contentEditable whilst keeping the things that make it good. Dealing with contentEditable directly though is… horrible.

After extensive testing though I can confirm that it’s the best way to go for dynamic, rich user input. You could always set the component to contentEditable="true" but I could write a whole essay on why contentEditable is broken (I just might one day…). A simple case of this are blog comments: where leaves a lot to be desired from a UX point of view.

Other times, however, this input is much more dynamic. In these cases forms are ideal as they let you specifically state what you need from the user and then save it in a server-friendly format. Maybe we should try to answer this by looking at the type of input you want to get? Often, it is well-structured and relatively static. What’s the best way of getting user input into your application? This isn’t an easy question.
