use-editable
\nA small React hook to turn elements into fully renderable & editable content surfaces, like code editors, using contenteditable (and magic)
\n\n \n
![\"NPM](\"https://img.shields.io/npm/v/use-editable.svg\")
\n \n \n ![\"License\"](\"https://img.shields.io/npm/l/use-editable.svg\")
\n \n \n ![\"Minified](\"https://img.shields.io/bundlephobia/minzip/use-editable.svg?label=gzip%20size\")
\n \n \n
\n
A small React hook to turn elements into fully renderable & editable content surfaces, like code editors, using contenteditable (and magic)
\n\n \n \n \n \n \n \n \n `\nelement that is being rendered, and to `setCode` which drives our state containing some code.\n\n## Browser Compatibility\n\nThis library has been tested against and **should work properly** using:\n\n- Chrome\n- Safari\n- iOS Safari\n- Firefox\n\nThere are known issues in **IE 11** due to the `MutationObserver` method being unable to\nread text nodes that have been removed via the `contenteditable`.\n\n## FAQ\n\n### How does it work?\n\nTraditionally, there have been three options when choosing editing surfaces in React. Either one\ncould go for a large project like ProseMirror / CodeMirror or similar which take control over much\nof the editing and rendering events and are hence rather opinionated, or it's possible to just\nuse `contenteditable` and render to raw HTML that is replaced in the element's content, or lastly one\ncould combine a `textarea` with an overlapping `div` that renders stylised content.\n\nAll three options don't allow much customisation in terms of what actually gets rendered or put\nunreasonable restrictions on how easy it is to render and manage an editable's content.\n\n**So what makes rendering to a `contenteditable` element so hard?**\n\nTypically this is tough because they edit the DOM directly. This causes most rendering libraries, like\nReact and Preact to be confused, since their underlying Virtual DOMs don't match up with the actual\nDOM structure anymore. To prevent this issue `use-editable` creates a `MutationObserver`, which watches\nover all changes that are made to the `contenteditable` element. Before it reports these changes to\nReact it first rolls back all changes to the DOM so that React sees what it expects.\n\nFurthermore it also preserves the current position of the caret, the selection, and restores it once\nReact has updated the DOM itself. This is a rather common technique for `contenteditable` editors, but\nthe `MutationObserver` addition is what enables `use-editable` to let another view library update the element's\ncontent.\n\n### What's currently possible?\n\nCurrently either the rendered elements' text content has to eventually exactly match the code input,\nor your implementation must be able to convert the rendered text content back into what you're using\nas state. This is a limitation of how `contenteditable`'s work, since they'll only capture the actual\nDOM content. Since `use-editable` doesn't aim to be a full component that manages the render cycle, it\ndoesn't have to keep any extra state, but will only pass the DOM's text back to the `onChange` callback.\n\nUsing the `onChange` callback you'll also receive a `Position` object describing the cursor position,\nthe current line number, and the line's contents up until the cursor, which is useful for auto-suggestions,\nwhich could then be applied with the `update` function that `useEditable` returns to update the cursor\nposition.\n\n## API\n\n### useEditable\n\nThe **first argument** is `elementRef` and accepts a ref object of type `RefObject` which\npoints to the element that should become editable. This ref is allowed to be `null` or change during\nthe runtime of the hook. As long as the changes of the ref are triggered by React, everything should\nbehave as expected.\n\nThe **second argument** is `onChange` and accepts a callback of type `(text: string, pos: Position) => void`\nthat's called whenever the content of the `contenteditable` changes. This needs to be set up so that\nit'll trigger a rerender of the element's contents.\n\nThe `text` that `onChange` receives is just the textual representation of the element's contents, while the\n`Position` it receives contains the current position of the cursor, the line number (zero-indexed), and\nthe content of the current line up until the cursor, which is useful for autosuggestions.\n\nThe **third argument** is an optional `options` object. This accepts currently two options to change\nthe editing behavior of the hook:\n\n- The `disabled` option disables editing on the editable by removing the `contentEditable` attribute from\n it again.\n- The `indentation` option may be a number of displayed spaces for indentation. This also enables the\n improved `Tab` key behavior, which will indent the current line or dedent the current line when shift is\n held (Be aware that this will make the editor act as a focus trap!)\n\nWhen `options.indentation` is set then `useEditable` will prevent the insertion of tab characters and\nwill instead insert the specified amount of whitespaces, which makes handling of columns much easier.\n\nAdditionally the `useEditable` hook returns an `Edit` handle with several methods, as documented below.\n\n#### Edit.update\n\n`Edit.update(content: string): void`\n\nReplaces the entire content of the editable while adjusting the caret position.\nThis will shift the caret by the difference in length between the current content and the passed content.\n\n#### Edit.insert\n\n`Edit.insert(append: string, offset?: number): void`\n\nInserts new text at the caret position while deleting text in range of the offset (which accepts negative offsets).\nFor example, when `offset` is set to `-1` then a single character is deleted to the left of the caret before\ninserting any new text. When it's set to `2` then two characters to the right of the carets are deleted.\nThe `append` text may also be set to an empty string to only apply deletions without inserting any text.\nWhen any text is selected then it's simply erased first and `offset` is ignored.\n\n#### Edit.move\n\n`Edit.move(pos: number | { row: number; column: number }): void`\n\nThis moves the caret to the specified position. The position may either be a character index (a `number`)\nor coordinates specifying a `row` and `column` separately.\n\n#### Edit.getState\n\n`Edit.getState(): { text: string; position: Position }`\n\nThis method allows getting the current state of the editable, which is the same as what `onChange` usually\nreceives. This is useful when adding custom editing actions in a key down handler or when programmatically\nimitating `onChange` otherwise, while the editable is selected.\n\n## Acknowledgments\n\n- [`react-live`](https://github.com/FormidableLabs/react-live/blob/v1.12.0/src/components/Editor/index.js), which I've worked on\n had one of the early tiny `contenteditable` editors. (But with raw HTML updates)\n- [`react-simple-code-editor`](https://github.com/satya164/react-simple-code-editor) was the first (?) library to use a split textarea\n and rendering surface implementation, which presented what a nice editing API should look like.\n- [`codejar`](https://github.com/antonmedv/codejar) contains the best tricks to manage selections, although it lacks some\n Firefox workarounds. It also uses raw HTML highlighting / updating.\n- [`codemirror.next`](https://github.com/codemirror/codemirror.next) is an invaluable source to see different techniques when\n handling text input and DOM update tricks.\n","_attachments":{},"bugs":{"url":"https://github.com/kitten/use-editable/issues"},"license":"MIT"}