This approach would also allow us to observe selection changes within the editor and map them back to our known model. After rendering updated contents, we could use that knowledge to instruct the native imperative selection API to put the cursor in the correct location. We had knowledge of the entire DOM structure at any point, so we could map our selection model directly to a position in the DOM. Our complete control over the rendered DOM gave us a window into cursor control.
Support for Input Method Editor (IME), cut/copy/paste, and spellcheck.Strict control of cursor and selection with Native Selection API.Strict control of rendered contents with React.To that end, we wanted to create a framework that would accomplish the following: Given the default feature set, we decided to build a controlled ContentEditable React component, following the same control pattern as controlled React DOM inputs. Automatic auto-growing - no DOM hacks or measurement needed.Native input events (e.g., key events, Input Method Editor ).However, we recognized that it offered quite a few positive attributes: ContentEditable is often regarded as confusing, unpredictable, and hard to use, and it directly violates the philosophy of keeping the application state separate from the DOM. Another possibility we considered was to use ContentEditable, a browser widget that often forms the basis for rich editors on the web. A key problem with this approach is the need to manually draw a fake cursor or selection, which would require either more DOM measurement or hacks. One proposed solution was to draw all contents manually, thus providing complete support for styling and embedded features. We also needed to identify the right approach for rendering our editor, so we considered a few options. Additionally, as we began to build more interfaces with React, we wanted to build a framework that would seamlessly integrate into React applications. To resolve the above challenges, we decided to develop our own rich text editor and make rich text input more customizable. Not only that, but since supports only plaintext, we could never expand our feature set to include richer styles or embedded content. These issues in turn led to poor user experiences, with misaligned backgrounds and broken input. There were also challenges with synchronizing state and DOM, since the plaintext contained no information about the structured mention data. However, this solution led to a poor developer experience, with lots of DOM hacks needed to measure text to autogrow the textarea, keep highlighters positioned properly, and track cursor positions with invisible unicode characters.
In the past, we've addressed this format with and background highlighter tags. For instance, within a comment, you might add mentions and hashtags. Rich text is a core part of Facebook products. We're thrilled to share that it now has nearly 4,000 stars. This is a new area for us because we've never open-sourced a rich-text framework, but we were excited to see that within the first couple of hours of it being open-sourced in GitHub, Draft.js received more than 1,000 stars. We open-sourced Draft.js, a React-based rich text editor framework that has been in development since summer 2013. One of the event's highlights came from our very own product infrastructure team here at Facebook. This week, 400 engineers from the React community came together for React.js Conf in San Francisco, a two-day conference dedicated to discussing React developer trends while addressing some common challenges to improve the experience for both the developer and the user.
0 kommentar(er)
