Skip to main content

ITreeConfigurationOptions Interface

Options when constructing a tree view.

Signature​

export interface ITreeConfigurationOptions

Properties​

Property Modifiers Default Value Type Description
enableSchemaValidation optional false. boolean If true, the tree will validate new content against its stored schema at insertion time and throw an error if the new content doesn't match the expected schema.
preventAmbiguity optional, readonly false. boolean A flag used to opt into strict rules ensuring that the schema avoids cases which can make the type of nodes ambiguous when importing or exporting data.

Property Details​

enableSchemaValidation​

If true, the tree will validate new content against its stored schema at insertion time and throw an error if the new content doesn't match the expected schema.

Signature​

enableSchemaValidation?: boolean;

Type: boolean

Remarks​

Enabling schema validation has a performance penalty when inserting new content into the tree because additional checks are done. Enable this option only in scenarios where you are ok with that operation being a bit slower.

preventAmbiguity​

A flag used to opt into strict rules ensuring that the schema avoids cases which can make the type of nodes ambiguous when importing or exporting data.

Signature​

readonly preventAmbiguity?: boolean;

Type: boolean

Remarks​

When this is true, it ensures that the compile time type safety for data when constructing nodes is sufficient to ensure that the runtime behavior will not give node data ambiguity errors.

This ensures that the canonical JSON-like representation of all unions in the tree are lossless and unambiguous. This canonical JSON-like representation consists of arrays, plain old JavaScript objects with string keys, booleans, numbers (excluding NaN, -0 and infinities), strings, null and _@fluidframework/core-interfaces#IFluidHandle_s. It is compatible with the node creation APIs (such as schema class constructors) and is also compatible with JSON assuming any IFluidHandles get special handling (since they are not JSON compatible). Currently these cases can cause ambiguity in a union:

  • More than one ArrayNode type: it's impossible to tell which array type is intended in the case of empty arrays ([]).

  • More than one MapNode type: it's impossible to tell which map type is intended in the case of an empty map ({}).

  • Both a MapNode and an ArrayNode: this case is not a problem for the canonical JSON representation, but is an issue when constructing from an Iterable, which is supported for both MapNode and ArrayNode.

  • Both a MapNode and an ObjectNode: when the input is valid for the ObjectNode, the current parser always considers it ambiguous with being a MapNode.

  • ObjectNodes which have fields (required or optional) which include all required fields of another ObjectNode: currently each ObjectNode is differentiated by the presence of its required fields.

This check is conservative: some complex cases may error if the current simple algorithm cannot show no ambiguity is possible. This check may become more permissive over time.

Usage​

Example 1​

Ambiguous schema (with preventAmbiguity: false), and how to disambiguate it using Unhydrated nodes:

const schemaFactory = new SchemaFactory("com.example");
class Feet extends schemaFactory.object("Feet", { length: schemaFactory.number }) {}
class Meters extends schemaFactory.object("Meters", { length: schemaFactory.number }) {}
const config = new TreeViewConfiguration({
	// This combination of schema can lead to ambiguous cases and will error if `preventAmbiguity` is true.
	schema: [Feet, Meters],
	preventAmbiguity: false,
});
const view = tree.viewWith(config);
// This is invalid since it is ambiguous which type of node is being constructed:
// view.initialize({ length: 5 });
// To work, an explicit type can be provided by using an {@link Unhydrated} Node:
view.initialize(new Meters({ length: 5 }));
Example 2​

Schema disambiguated by adjusting field names, validated with preventAmbiguity: true:

const schemaFactory = new SchemaFactory("com.example");
class Feet extends schemaFactory.object("Feet", { length: schemaFactory.number }) {}
class Meters extends schemaFactory.object("Meters", {
	// To avoid ambiguity when parsing unions of Feet and Meters, this renames the length field to "meters".
	// To preserve compatibility with existing data from the ambiguous case,
	// `{ key: "length" }` is set, so when persisted in the tree "length" is used as the field name.
	meters: schemaFactory.required(schemaFactory.number, { key: "length" }),
}) {}
const config = new TreeViewConfiguration({
	// This combination of schema is not ambiguous because `Feet` and `Meters` have different required keys.
	schema: [Feet, Meters],
	preventAmbiguity: true,
});
const view = tree.viewWith(config);
// This now works, since the field is sufficient to determine this is a `Meters` node.
view.initialize({ meters: 5 });