@fluidframework/tree 2.81.0-374083 → 2.81.1

package/dist/text/index.js

@@ -4,7 +4,9 @@
  * Licensed under the MIT License.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.TextAsTree = void 0;
+exports.FormattedTextAsTree = exports.TextAsTree = void 0;
 var textDomain_js_1 = require("./textDomain.js");
 Object.defineProperty(exports, "TextAsTree", { enumerable: true, get: function () { return textDomain_js_1.TextAsTree; } });
+var textDomainFormatted_js_1 = require("./textDomainFormatted.js");
+Object.defineProperty(exports, "FormattedTextAsTree", { enumerable: true, get: function () { return textDomainFormatted_js_1.FormattedTextAsTree; } });
 //# sourceMappingURL=index.js.map

package/dist/text/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/text/index.ts"],"names":[],"mappings":";AAAA;;;GAGG;;;AAEH,iDAA6C;AAApC,2GAAA,UAAU,OAAA","sourcesContent":["/*!\n * Copyright (c) Microsoft Corporation and contributors. All rights reserved.\n * Licensed under the MIT License.\n */\n\nexport { TextAsTree } from \"./textDomain.js\";\n"]}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/text/index.ts"],"names":[],"mappings":";AAAA;;;GAGG;;;AAEH,iDAA6C;AAApC,2GAAA,UAAU,OAAA;AACnB,mEAA+D;AAAtD,6HAAA,mBAAmB,OAAA","sourcesContent":["/*!\n * Copyright (c) Microsoft Corporation and contributors. All rights reserved.\n * Licensed under the MIT License.\n */\n\nexport { TextAsTree } from \"./textDomain.js\";\nexport { FormattedTextAsTree } from \"./textDomainFormatted.js\";\n"]}

package/dist/text/textDomain.d.ts

@@ -3,6 +3,14 @@
  * Licensed under the MIT License.
  */
 import type { TreeNode, WithType } from "../simple-tree/index.js";
+/**
+ * Interpret a string as an iterable of characters.
+ * @remarks
+ * This mostly exists to clearly document where the code is interpreting a string as characters,
+ * and provide a centralized place where validation could be added in the future if desired.
+ * Additionally using this function consistently will make any refactors to support alternative character boundaries easier.
+ */
+export declare function charactersFromString(value: string): Iterable<string>;
 /**
  * A collection of text related types, schema and utilities for working with text beyond the basic {@link SchemaStatics.string}.
  * @privateRemarks

package/dist/text/textDomain.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"textDomain.d.ts","sourceRoot":"","sources":["../../src/text/textDomain.ts"],"names":[],"mappings":"AAAA;;;GAGG;AASH,OAAO,KAAK,EAAE,QAAQ,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAkDlE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6DG;AACH,yBAAiB,UAAU,CAAC;IAC3B;;;OAGG;IACH,UAAiB,OAAO;QACvB;;;WAGG;QACH,UAAU,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI,CAAC;KAChC;IAED;;;;;;;;;;;;;;;;OAgBG;IACH,UAAiB,OAAO;QACvB;;;;WAIG;QACH,UAAU,IAAI,QAAQ,CAAC,MAAM,CAAC,CAAC;QAE/B;;WAEG;QACH,UAAU,IAAI,MAAM,CAAC;QAErB;;;;;;;;;;;;WAYG;QACH,QAAQ,CAAC,KAAK,EAAE,MAAM,EAAE,oBAAoB,EAAE,MAAM,GAAG,IAAI,CAAC;QAE5D;;;WAGG;QACH,WAAW,CAAC,KAAK,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;KACjD;IAED;;;;;;OAMG;IACI,MAAM,IAAI,0QAAmD,CAAC;IACrE,KAAY,IAAI,GAAG,OAAO,GAAG,QAAQ,GAAG,QAAQ,CAAC,8BAA8B,CAAC,CAAC;CACjF"}
+{"version":3,"file":"textDomain.d.ts","sourceRoot":"","sources":["../../src/text/textDomain.ts"],"names":[],"mappings":"AAAA;;;GAGG;AASH,OAAO,KAAK,EAAE,QAAQ,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAkClE;;;;;;GAMG;AACH,wBAAgB,oBAAoB,CAAC,KAAK,EAAE,MAAM,GAAG,QAAQ,CAAC,MAAM,CAAC,CAKpE;AAID;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6DG;AACH,yBAAiB,UAAU,CAAC;IAC3B;;;OAGG;IACH,UAAiB,OAAO;QACvB;;;WAGG;QACH,UAAU,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI,CAAC;KAChC;IAED;;;;;;;;;;;;;;;;OAgBG;IACH,UAAiB,OAAO;QACvB;;;;WAIG;QACH,UAAU,IAAI,QAAQ,CAAC,MAAM,CAAC,CAAC;QAE/B;;WAEG;QACH,UAAU,IAAI,MAAM,CAAC;QAErB;;;;;;;;;;;;WAYG;QACH,QAAQ,CAAC,KAAK,EAAE,MAAM,EAAE,oBAAoB,EAAE,MAAM,GAAG,IAAI,CAAC;QAE5D;;;WAGG;QACH,WAAW,CAAC,KAAK,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;KACjD;IAED;;;;;;OAMG;IACI,MAAM,IAAI,0QAAmD,CAAC;IACrE,KAAY,IAAI,GAAG,OAAO,GAAG,QAAQ,GAAG,QAAQ,CAAC,8BAA8B,CAAC,CAAC;CACjF"}

package/dist/text/textDomain.js

@@ -4,7 +4,7 @@
  * Licensed under the MIT License.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.TextAsTree = void 0;
+exports.TextAsTree = exports.charactersFromString = void 0;
 const index_js_1 = require("../core/index.js");
 const index_js_2 = require("../simple-tree/index.js");
 const sf = new index_js_2.SchemaFactoryAlpha("com.fluidframework.text");
@@ -43,6 +43,7 @@ function charactersFromString(value) {
     // But those are not widely supported yet.
     return value;
 }
+exports.charactersFromString = charactersFromString;
 class StringArray extends sf.array("StringArray", index_js_2.SchemaFactory.string) {
 }
 /**

package/dist/text/textDomain.js.map

@@ -1 +1 @@
-{"version":3,"file":"textDomain.js","sourceRoot":"","sources":["../../src/text/textDomain.ts"],"names":[],"mappings":";AAAA;;;GAGG;;;AAEH,+CAA4C;AAC5C,sDAKiC;AAGjC,MAAM,EAAE,GAAG,IAAI,6BAAkB,CAAC,yBAAyB,CAAC,CAAC;AAE7D,MAAM,QACL,SAAQ,EAAE,CAAC,MAAM,CAAC,MAAM,EAAE;IACzB,OAAO,EAAE,wBAAa,CAAC,QAAQ,CAAC,CAAC,GAAG,EAAE,CAAC,WAAW,CAAC,EAAE,EAAE,GAAG,EAAE,mBAAQ,EAAE,CAAC;CACvE,CAAC;IAGK,QAAQ,CAAC,KAAa,EAAE,oBAA4B;QAC1D,IAAI,CAAC,OAAO,CAAC,QAAQ,CACpB,KAAK,EACL,wBAAa,CAAC,MAAM,CAAC,oBAAoB,CAAC,oBAAoB,CAAC,CAAC,CAChE,CAAC;IACH,CAAC;IACM,WAAW,CAAC,KAAa,EAAE,MAAc;QAC/C,IAAI,CAAC,OAAO,CAAC,WAAW,CAAC,KAAK,EAAE,MAAM,CAAC,CAAC;IACzC,CAAC;IACM,UAAU;QAChB,OAAO,IAAI,CAAC,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,EAAE,CAAC;IACxC,CAAC;IACM,UAAU;QAChB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAC9B,CAAC;IAEM,MAAM,CAAC,UAAU,CAAC,KAAa;QACrC,mJAAmJ;QACnJ,qKAAqK;QACrK,0EAA0E;QAC1E,OAAO,IAAI,QAAQ,CAAC,EAAE,OAAO,EAAE,CAAC,GAAG,oBAAoB,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC;IACpE,CAAC;CACD;AAED;;;;;;GAMG;AACH,SAAS,oBAAoB,CAAC,KAAa;IAC1C,0GAA0G;IAC1G,iKAAiK;IACjK,0CAA0C;IAC1C,OAAO,KAAK,CAAC;AACd,CAAC;AAED,MAAM,WAAY,SAAQ,EAAE,CAAC,KAAK,CAAC,aAAa,EAAE,wBAAa,CAAC,MAAM,CAAC;CAAG;AAE1E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6DG;AACH,IAAiB,UAAU,CA0E1B;AA1ED,WAAiB,UAAU;IAiE1B;;;;;;OAMG;IACU,eAAI,GAAG,IAAA,6BAAkB,GAAoB,CAAC,QAAQ,CAAC,CAAC;AAEtE,CAAC,EA1EgB,UAAU,0BAAV,UAAU,QA0E1B","sourcesContent":["/*!\n * Copyright (c) Microsoft Corporation and contributors. All rights reserved.\n * Licensed under the MIT License.\n */\n\nimport { EmptyKey } from \"../core/index.js\";\nimport {\n\teraseSchemaDetails,\n\tSchemaFactory,\n\tSchemaFactoryAlpha,\n\tTreeArrayNode,\n} from \"../simple-tree/index.js\";\nimport type { TreeNode, WithType } from \"../simple-tree/index.js\";\n\nconst sf = new SchemaFactoryAlpha(\"com.fluidframework.text\");\n\nclass TextNode\n\textends sf.object(\"Text\", {\n\t\tcontent: SchemaFactory.required([() => StringArray], { key: EmptyKey }),\n\t})\n\timplements TextAsTree.Members\n{\n\tpublic insertAt(index: number, additionalCharacters: string): void {\n\t\tthis.content.insertAt(\n\t\t\tindex,\n\t\t\tTreeArrayNode.spread(charactersFromString(additionalCharacters)),\n\t\t);\n\t}\n\tpublic removeRange(index: number, length: number): void {\n\t\tthis.content.removeRange(index, length);\n\t}\n\tpublic characters(): Iterable<string> {\n\t\treturn this.content[Symbol.iterator]();\n\t}\n\tpublic fullString(): string {\n\t\treturn this.content.join(\"\");\n\t}\n\n\tpublic static fromString(value: string): TextNode {\n\t\t// Constructing an ArrayNode from an iterator is supported, so creating an array from the iterable of characters seems like its not necessary here,\n\t\t// but to reduce the risk of incorrect data interpretation, we actually ban this in the special case where the iterable is a string directly, which is the case here.\n\t\t// Thus the array construction here is necessary to avoid a runtime error.\n\t\treturn new TextNode({ content: [...charactersFromString(value)] });\n\t}\n}\n\n/**\n * Interpret a string as an iterable of characters.\n * @remarks\n * This mostly exists to clearly document where the code is interpreting a string as characters,\n * and provide a centralized place where validation could be added in the future if desired.\n * Additionally using this function consistently will make any refactors to support alternative character boundaries easier.\n */\nfunction charactersFromString(value: string): Iterable<string> {\n\t// Uses the string as an iterable of characters, so utf-16 surrogate pairs get grouped together correctly.\n\t// Might be nice to call isWellFormed or toWellFormed here (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/toWellFormed)\n\t// But those are not widely supported yet.\n\treturn value;\n}\n\nclass StringArray extends sf.array(\"StringArray\", SchemaFactory.string) {}\n\n/**\n * A collection of text related types, schema and utilities for working with text beyond the basic {@link SchemaStatics.string}.\n * @privateRemarks\n * Currently this API only supports a really minimal feature set, and has no support for more advanced features like:\n * - Alternative character boundaries (e.g. grapheme clusters, paragraphs, tokens, etc.).\n * We may want to provide either ways to create strings with application controlled character boundaries since there is not a clear single answer on how to break a string into atomic units.\n * - Character attributes (e.g. bold, italic, etc):\n * Properties that can be set on any character independently with optimizations for runs of characters with the same attributes.\n * - Inline objects (e.g. images, embedded components, etc):\n * These would be logically part of the text, generalizing characters to allow inline objects in character ranges.\n * How character attributes apply to inline objects is an open question\n * (there could be a kind of object which gets them, and one that doesn't for example).\n * - Annotations (e.g. comments, suggestions, etc).\n * Objects which can be associated with a range of characters but are not logically part of the text.\n * These would need to have the logical range they apply to updated by edits.\n * How edits which overlap annotation boundaries are handled may require hints from the application for optimal behavior (mainly inserts at the boundaries).\n * These get a lifetime tied to the text node, not any of the characters the annotation covers,\n * however it might be desirable to have a way for a range edit to (optionally) also remove any annotations which are fully covered by the edit.\n * Annotations over an empty range should also be supported and behave well (for example not end up with characters inside the range after edits unless specifically structured so that makes sense).\n * - Anchors (e.g. positions in the text which survive edits).\n * These would be useful for ephemeral state like cursor positions, but should match the behaviors with respect to edits exhibited by the ends of Annotations.\n *\n * How these features will be represented in the schema and API should be determined before any of this is stabilized so the simple more limited version can neatly fit into the larger design.\n *\n * There are various optimizations that should be implemented to make this performant for large texts and common usage patterns.\n * These include:\n * - Optimized persisted format.\n * - Optimized in memory representation (via chunked forest).\n * - Optimized edit persisted format (e.g. combining adjacent inserts/removes into single operations as well as support for efficient attribute editing of ranges).\n * - Optimized edit application (e.g. applying the above noted optimizable edit cases efficiently).\n * This applies to the revision manager, the forest, and any flex or simple-tree nodes and user events.\n *\n * There are also additional features required for ensuring the invariants of collaborative text editing are maintained through concurrent edits.\n * The main challenges here are related to annotations, but some policies for what to do in the case of corrupt/invalid text should also be included.\n * There are quite a few ways invariants could break, including:\n * - concurrent edits without proper constraints.\n * - collaboration with clients using compatible schema with different constraints.\n * - opening documents which contain invalid content (e.g. from older versions of the software, manual edits to the persisted format, or simply an existing corrupt case which was saved).\n * - a user inserting/constructing/importing invalid content.\n *\n * These cases could break constraints causing issues like invalided characters (empty, a utf-16 surrogate pair alone, etc) or\n * annotations which reference out of bounds character ranges.\n * Addressing these issues mainly falls into these categories:\n * - Handling of invalid content on import/construction of unhydrated nodes and/or insertion into the document (hydration).\n * - Handling of invalid content which is already part of the document (live). This should ideally include both detection and repair.\n * - Constraints on edits to prevent invalid content from being created by merges.\n * - Optimization of the constraints to reduce cases in which edits are rejected due to conflicts.\n *\n * Note that these cases of invariant violations are the same cases any component should handle, so ideally there would be a general framework or pattern for documenting and enforcing such constraints.\n *\n * Another area for future work is improved APIs for import, export and non-schema-aware use. This includes a variety of cases, including but not limited to:\n * - Insertable content format (taken by the constructor and import APIs).\n * - Customizable export formats (like a way to make exportVerbose and exportConcise flatten the text nodes to strings automatically).\n * - Customizable toJson behavior (e.g. flattening to strings, possibly via tools or patterns for custom tree stringifier).\n * - Ensure JS object APIs (like iteration, own vs inherited properties, etc) provide a good and consistent experience with respect to other nodes.\n * - Support in generateSchemaFromSimpleSchema for recognizing text nodes and generating the appropriate schema.\n * - Ensure above features work well enough to support important scenarios like AI assisted editing and document indexing for search.\n *\n * Part of that work will be establishing and documenting those patterns so other components with complex encodings can follow them,\n * in addition to implementing them for text.\n * @internal\n */\nexport namespace TextAsTree {\n\t/**\n\t * Statics for text nodes.\n\t * @internal\n\t */\n\texport interface Statics {\n\t\t/**\n\t\t * Construct a {@link TextAsTree.(Tree:type)} from a string, where each character (as defined by iterating over the string) becomes a single character in the text node.\n\t\t * This combines pairs of utf-16 surrogate code units into single characters as appropriate.\n\t\t */\n\t\tfromString(value: string): Tree;\n\t}\n\n\t/**\n\t * Interface for a text node.\n\t * @remarks\n\t * The string is broken up into substrings which are referred to as 'characters'.\n\t * Unlike with JavaScript strings, all indexes are by character, not UTF-16 code unit.\n\t * This avoids the problem JavaScript where it can split UTF-16 surrogate pairs producing invalid strings,\n\t * and avoids the issue where indexing a string and iterating it segment the string differently.\n\t * This does NOT mean the characters correspond to user perceived characters (like grapheme clusters try to do):\n\t * applications will likely want to include higher level segmentation logic\n\t * which might differ between operations like delete\n\t * (which often operates on something in between unicode code points and grapheme clusters)\n\t * and navigation/selection (which typically uses grapheme clusters).\n\t *\n\t * @see {@link TextAsTree.Statics.fromString} for construction.\n\t * @see {@link TextAsTree.(Tree:type)} for schema.\n\t * @internal\n\t */\n\texport interface Members {\n\t\t/**\n\t\t * Gets an iterable over the characters currently in the text.\n\t\t * @remarks\n\t\t * This iterator matches the behavior of {@link (TreeArrayNode:interface)} with respect to edits during iteration.\n\t\t */\n\t\tcharacters(): Iterable<string>;\n\n\t\t/**\n\t\t * Copy the content of this node into a string.\n\t\t */\n\t\tfullString(): string;\n\n\t\t/**\n\t\t * Insert a range of characters into the string based on character index.\n\t\t * @remarks\n\t\t * See {@link (TreeArrayNode:interface).insertAt} for more details on the behavior.\n\t\t * See {@link TextAsTree.Statics.fromString} for how the `additionalCharacters` string is broken into characters.\n\t\t * @privateRemarks\n\t\t * If we provide ways to customize character boundaries, that could be handled here by taking in an Iterable<string> instead of a string.\n\t\t * Doing this currently would enable insertion of text with different character boundaries than the existing text,\n\t\t * which would violate the currently documented character boundary invariants.\n\t\t *\n\t\t * Another option would be to take an approach like Table,\n\t\t * where the user of the API uses a factory function to generate the schema, and can inject custom logic, like a string character iterator.\n\t\t */\n\t\tinsertAt(index: number, additionalCharacters: string): void;\n\n\t\t/**\n\t\t * Remove a range from a string based on character index.\n\t\t * See {@link (TreeArrayNode:interface).removeRange} for more details on the behavior.\n\t\t */\n\t\tremoveRange(index: number, length: number): void;\n\t}\n\n\t/**\n\t * Schema for a text node.\n\t * @remarks\n\t * See {@link TextAsTree.Members} for the API.\n\t * See {@link TextAsTree.Statics} for static APIs on this Schema, including construction.\n\t * @internal\n\t */\n\texport const Tree = eraseSchemaDetails<Members, Statics>()(TextNode);\n\texport type Tree = Members & TreeNode & WithType<\"com.fluidframework.text.Text\">;\n}\n"]}
+{"version":3,"file":"textDomain.js","sourceRoot":"","sources":["../../src/text/textDomain.ts"],"names":[],"mappings":";AAAA;;;GAGG;;;AAEH,+CAA4C;AAC5C,sDAKiC;AAGjC,MAAM,EAAE,GAAG,IAAI,6BAAkB,CAAC,yBAAyB,CAAC,CAAC;AAE7D,MAAM,QACL,SAAQ,EAAE,CAAC,MAAM,CAAC,MAAM,EAAE;IACzB,OAAO,EAAE,wBAAa,CAAC,QAAQ,CAAC,CAAC,GAAG,EAAE,CAAC,WAAW,CAAC,EAAE,EAAE,GAAG,EAAE,mBAAQ,EAAE,CAAC;CACvE,CAAC;IAGK,QAAQ,CAAC,KAAa,EAAE,oBAA4B;QAC1D,IAAI,CAAC,OAAO,CAAC,QAAQ,CACpB,KAAK,EACL,wBAAa,CAAC,MAAM,CAAC,oBAAoB,CAAC,oBAAoB,CAAC,CAAC,CAChE,CAAC;IACH,CAAC;IACM,WAAW,CAAC,KAAa,EAAE,MAAc;QAC/C,IAAI,CAAC,OAAO,CAAC,WAAW,CAAC,KAAK,EAAE,MAAM,CAAC,CAAC;IACzC,CAAC;IACM,UAAU;QAChB,OAAO,IAAI,CAAC,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,EAAE,CAAC;IACxC,CAAC;IACM,UAAU;QAChB,OAAO,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAC9B,CAAC;IAEM,MAAM,CAAC,UAAU,CAAC,KAAa;QACrC,mJAAmJ;QACnJ,qKAAqK;QACrK,0EAA0E;QAC1E,OAAO,IAAI,QAAQ,CAAC,EAAE,OAAO,EAAE,CAAC,GAAG,oBAAoB,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC;IACpE,CAAC;CACD;AAED;;;;;;GAMG;AACH,SAAgB,oBAAoB,CAAC,KAAa;IACjD,0GAA0G;IAC1G,iKAAiK;IACjK,0CAA0C;IAC1C,OAAO,KAAK,CAAC;AACd,CAAC;AALD,oDAKC;AAED,MAAM,WAAY,SAAQ,EAAE,CAAC,KAAK,CAAC,aAAa,EAAE,wBAAa,CAAC,MAAM,CAAC;CAAG;AAE1E;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6DG;AACH,IAAiB,UAAU,CA0E1B;AA1ED,WAAiB,UAAU;IAiE1B;;;;;;OAMG;IACU,eAAI,GAAG,IAAA,6BAAkB,GAAoB,CAAC,QAAQ,CAAC,CAAC;AAEtE,CAAC,EA1EgB,UAAU,0BAAV,UAAU,QA0E1B","sourcesContent":["/*!\n * Copyright (c) Microsoft Corporation and contributors. All rights reserved.\n * Licensed under the MIT License.\n */\n\nimport { EmptyKey } from \"../core/index.js\";\nimport {\n\teraseSchemaDetails,\n\tSchemaFactory,\n\tSchemaFactoryAlpha,\n\tTreeArrayNode,\n} from \"../simple-tree/index.js\";\nimport type { TreeNode, WithType } from \"../simple-tree/index.js\";\n\nconst sf = new SchemaFactoryAlpha(\"com.fluidframework.text\");\n\nclass TextNode\n\textends sf.object(\"Text\", {\n\t\tcontent: SchemaFactory.required([() => StringArray], { key: EmptyKey }),\n\t})\n\timplements TextAsTree.Members\n{\n\tpublic insertAt(index: number, additionalCharacters: string): void {\n\t\tthis.content.insertAt(\n\t\t\tindex,\n\t\t\tTreeArrayNode.spread(charactersFromString(additionalCharacters)),\n\t\t);\n\t}\n\tpublic removeRange(index: number, length: number): void {\n\t\tthis.content.removeRange(index, length);\n\t}\n\tpublic characters(): Iterable<string> {\n\t\treturn this.content[Symbol.iterator]();\n\t}\n\tpublic fullString(): string {\n\t\treturn this.content.join(\"\");\n\t}\n\n\tpublic static fromString(value: string): TextNode {\n\t\t// Constructing an ArrayNode from an iterator is supported, so creating an array from the iterable of characters seems like its not necessary here,\n\t\t// but to reduce the risk of incorrect data interpretation, we actually ban this in the special case where the iterable is a string directly, which is the case here.\n\t\t// Thus the array construction here is necessary to avoid a runtime error.\n\t\treturn new TextNode({ content: [...charactersFromString(value)] });\n\t}\n}\n\n/**\n * Interpret a string as an iterable of characters.\n * @remarks\n * This mostly exists to clearly document where the code is interpreting a string as characters,\n * and provide a centralized place where validation could be added in the future if desired.\n * Additionally using this function consistently will make any refactors to support alternative character boundaries easier.\n */\nexport function charactersFromString(value: string): Iterable<string> {\n\t// Uses the string as an iterable of characters, so utf-16 surrogate pairs get grouped together correctly.\n\t// Might be nice to call isWellFormed or toWellFormed here (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/toWellFormed)\n\t// But those are not widely supported yet.\n\treturn value;\n}\n\nclass StringArray extends sf.array(\"StringArray\", SchemaFactory.string) {}\n\n/**\n * A collection of text related types, schema and utilities for working with text beyond the basic {@link SchemaStatics.string}.\n * @privateRemarks\n * Currently this API only supports a really minimal feature set, and has no support for more advanced features like:\n * - Alternative character boundaries (e.g. grapheme clusters, paragraphs, tokens, etc.).\n * We may want to provide either ways to create strings with application controlled character boundaries since there is not a clear single answer on how to break a string into atomic units.\n * - Character attributes (e.g. bold, italic, etc):\n * Properties that can be set on any character independently with optimizations for runs of characters with the same attributes.\n * - Inline objects (e.g. images, embedded components, etc):\n * These would be logically part of the text, generalizing characters to allow inline objects in character ranges.\n * How character attributes apply to inline objects is an open question\n * (there could be a kind of object which gets them, and one that doesn't for example).\n * - Annotations (e.g. comments, suggestions, etc).\n * Objects which can be associated with a range of characters but are not logically part of the text.\n * These would need to have the logical range they apply to updated by edits.\n * How edits which overlap annotation boundaries are handled may require hints from the application for optimal behavior (mainly inserts at the boundaries).\n * These get a lifetime tied to the text node, not any of the characters the annotation covers,\n * however it might be desirable to have a way for a range edit to (optionally) also remove any annotations which are fully covered by the edit.\n * Annotations over an empty range should also be supported and behave well (for example not end up with characters inside the range after edits unless specifically structured so that makes sense).\n * - Anchors (e.g. positions in the text which survive edits).\n * These would be useful for ephemeral state like cursor positions, but should match the behaviors with respect to edits exhibited by the ends of Annotations.\n *\n * How these features will be represented in the schema and API should be determined before any of this is stabilized so the simple more limited version can neatly fit into the larger design.\n *\n * There are various optimizations that should be implemented to make this performant for large texts and common usage patterns.\n * These include:\n * - Optimized persisted format.\n * - Optimized in memory representation (via chunked forest).\n * - Optimized edit persisted format (e.g. combining adjacent inserts/removes into single operations as well as support for efficient attribute editing of ranges).\n * - Optimized edit application (e.g. applying the above noted optimizable edit cases efficiently).\n * This applies to the revision manager, the forest, and any flex or simple-tree nodes and user events.\n *\n * There are also additional features required for ensuring the invariants of collaborative text editing are maintained through concurrent edits.\n * The main challenges here are related to annotations, but some policies for what to do in the case of corrupt/invalid text should also be included.\n * There are quite a few ways invariants could break, including:\n * - concurrent edits without proper constraints.\n * - collaboration with clients using compatible schema with different constraints.\n * - opening documents which contain invalid content (e.g. from older versions of the software, manual edits to the persisted format, or simply an existing corrupt case which was saved).\n * - a user inserting/constructing/importing invalid content.\n *\n * These cases could break constraints causing issues like invalided characters (empty, a utf-16 surrogate pair alone, etc) or\n * annotations which reference out of bounds character ranges.\n * Addressing these issues mainly falls into these categories:\n * - Handling of invalid content on import/construction of unhydrated nodes and/or insertion into the document (hydration).\n * - Handling of invalid content which is already part of the document (live). This should ideally include both detection and repair.\n * - Constraints on edits to prevent invalid content from being created by merges.\n * - Optimization of the constraints to reduce cases in which edits are rejected due to conflicts.\n *\n * Note that these cases of invariant violations are the same cases any component should handle, so ideally there would be a general framework or pattern for documenting and enforcing such constraints.\n *\n * Another area for future work is improved APIs for import, export and non-schema-aware use. This includes a variety of cases, including but not limited to:\n * - Insertable content format (taken by the constructor and import APIs).\n * - Customizable export formats (like a way to make exportVerbose and exportConcise flatten the text nodes to strings automatically).\n * - Customizable toJson behavior (e.g. flattening to strings, possibly via tools or patterns for custom tree stringifier).\n * - Ensure JS object APIs (like iteration, own vs inherited properties, etc) provide a good and consistent experience with respect to other nodes.\n * - Support in generateSchemaFromSimpleSchema for recognizing text nodes and generating the appropriate schema.\n * - Ensure above features work well enough to support important scenarios like AI assisted editing and document indexing for search.\n *\n * Part of that work will be establishing and documenting those patterns so other components with complex encodings can follow them,\n * in addition to implementing them for text.\n * @internal\n */\nexport namespace TextAsTree {\n\t/**\n\t * Statics for text nodes.\n\t * @internal\n\t */\n\texport interface Statics {\n\t\t/**\n\t\t * Construct a {@link TextAsTree.(Tree:type)} from a string, where each character (as defined by iterating over the string) becomes a single character in the text node.\n\t\t * This combines pairs of utf-16 surrogate code units into single characters as appropriate.\n\t\t */\n\t\tfromString(value: string): Tree;\n\t}\n\n\t/**\n\t * Interface for a text node.\n\t * @remarks\n\t * The string is broken up into substrings which are referred to as 'characters'.\n\t * Unlike with JavaScript strings, all indexes are by character, not UTF-16 code unit.\n\t * This avoids the problem JavaScript where it can split UTF-16 surrogate pairs producing invalid strings,\n\t * and avoids the issue where indexing a string and iterating it segment the string differently.\n\t * This does NOT mean the characters correspond to user perceived characters (like grapheme clusters try to do):\n\t * applications will likely want to include higher level segmentation logic\n\t * which might differ between operations like delete\n\t * (which often operates on something in between unicode code points and grapheme clusters)\n\t * and navigation/selection (which typically uses grapheme clusters).\n\t *\n\t * @see {@link TextAsTree.Statics.fromString} for construction.\n\t * @see {@link TextAsTree.(Tree:type)} for schema.\n\t * @internal\n\t */\n\texport interface Members {\n\t\t/**\n\t\t * Gets an iterable over the characters currently in the text.\n\t\t * @remarks\n\t\t * This iterator matches the behavior of {@link (TreeArrayNode:interface)} with respect to edits during iteration.\n\t\t */\n\t\tcharacters(): Iterable<string>;\n\n\t\t/**\n\t\t * Copy the content of this node into a string.\n\t\t */\n\t\tfullString(): string;\n\n\t\t/**\n\t\t * Insert a range of characters into the string based on character index.\n\t\t * @remarks\n\t\t * See {@link (TreeArrayNode:interface).insertAt} for more details on the behavior.\n\t\t * See {@link TextAsTree.Statics.fromString} for how the `additionalCharacters` string is broken into characters.\n\t\t * @privateRemarks\n\t\t * If we provide ways to customize character boundaries, that could be handled here by taking in an Iterable<string> instead of a string.\n\t\t * Doing this currently would enable insertion of text with different character boundaries than the existing text,\n\t\t * which would violate the currently documented character boundary invariants.\n\t\t *\n\t\t * Another option would be to take an approach like Table,\n\t\t * where the user of the API uses a factory function to generate the schema, and can inject custom logic, like a string character iterator.\n\t\t */\n\t\tinsertAt(index: number, additionalCharacters: string): void;\n\n\t\t/**\n\t\t * Remove a range from a string based on character index.\n\t\t * See {@link (TreeArrayNode:interface).removeRange} for more details on the behavior.\n\t\t */\n\t\tremoveRange(index: number, length: number): void;\n\t}\n\n\t/**\n\t * Schema for a text node.\n\t * @remarks\n\t * See {@link TextAsTree.Members} for the API.\n\t * See {@link TextAsTree.Statics} for static APIs on this Schema, including construction.\n\t * @internal\n\t */\n\texport const Tree = eraseSchemaDetails<Members, Statics>()(TextNode);\n\texport type Tree = Members & TreeNode & WithType<\"com.fluidframework.text.Text\">;\n}\n"]}