feat(devtools-core): Render ST's Visualizer to Include Root Field's Allowed Types

[jikim-msft]

Description

26472

The current visualization generation logic in DefaultVisualizers.ts treats the root of the shared tree as a node and thus omits information that should be included in the root of the ST visualizer. Since the root field is allowed to have multiple types (i.e., different schema or primitive types), this information should be rendered in the tooltip of the visualizer.

This PR changes how the visualizer renders the allowed types in the tooltip

Example Schema

const config = new TreeViewConfiguration({
			schema: [RootNodeOne, RootNodeTwo, builder.string, builder.number],
		});

Before

After
Defined

Undefined

[Josmithr]

I don't think this is quite right. If the tree root is optional and there is no data (i.e., the root field is set to undefined), we will get undefined here. But there is still schema information to display.

This case should be like any other optional field with no data (undefined) that we encounter while walking the tree. So, I would expect us to just be able to call visualizeSharedTreeBySchema in this case like any other.

[Josmithr]

Have we tested other cases where we have optional fields in the tree and no data is set? I'm curious how we display them currently. Ideally, we should still be able to see the allowed types for the field, even when there is no data in it.

[jikim-msft]

You're right. We should still be able to display the relevant schema information even if the tree root is optional (this isn't the case right now. I will fix it).

In addition, I personally think the non-root optional fields with no data should be omitted in the visualizer. Using the schema example in FluidObject.ts,

class TodoItem extends builder.object("todo-item", {
	title: builder.string,
	completed: builder.boolean,
	dueDate: builder.optional(builder.string),
	assignee: builder.optional(builder.string),
	colloborators: builder.optional(builder.array(builder.string)),
}) {}

class TodoObject extends builder.object("todo-list", {
	items: builder.array(TodoItem),
	optionalItem: builder.optional(builder.string), // CHANGE 1: Others are identical
}) {}

class TodoCategory extends builder.object("todo-category", {
	work: TodoObject,
	personal: TodoObject,
}) {}

class TodoWorkspace extends builder.object("todo-workspace", {
	lists: TodoCategory,
}) {}

const config = new TreeViewConfiguration({
	schema: [TodoWorkspace],
});

const view = sharedTree.viewWith(config);
view.initialize({
	lists: {
		work: {
			items: [
				{
					title: "Finish design doc.",
					completed: false,
					dueDate: "2048-01-01",
					assignee: "Kevin",
					colloborators: ["Rick"],
				},
				{
					title: "Review pull requests",
					completed: true,
					assignee: "Bob",
				},
			],
			optionalItem: "optional", // CHANGE 2: Others are identical
		},
		personal: {
			items: [
				{
					title: "Buy groceries",
					completed: false,
				},
				{
					title: "Schedule dentist appointment",
					completed: false,
					dueDate: "2024-05-04",
				},
			],
		},
	},
});

I think the visualization above provides enough information to developers:

• It gives the name of its direct child schema (todo-list). And I think this name is indicative enough for the devs to figure out that field optionalItem is indeed optional in the actual code.
• It intentionally omits the unprovided data

With that said, I believe what we can do is:

• Keep the current if condition and instead return the FluidObjectTreeNode withtooltipContents populated (which contains the information on optionality and direct child schema name).

[jikim-msft]

If I do something like this:

	const allowedTypes = concatenateTypes(sharedTree.exportSimpleSchema().allowedTypes);
	const isRequired = getIsRequired(sharedTree.exportSimpleSchema());

	if (treeView === undefined) {
		return {
			fluidObjectId: sharedTree.id,
			typeMetadata: "SharedTree",
			nodeKind: VisualNodeKind.FluidTreeNode,
			tooltipContents: {
				schema: {
					nodeKind: VisualNodeKind.TreeNode,
					children: {
						name: {
							nodeKind: VisualNodeKind.ValueNode,
							value: "undefined tree", // TODO: Better name
						},
						allowedTypes: {
							nodeKind: VisualNodeKind.ValueNode,
							value: allowedTypes,
						},
						isRequired: {
							nodeKind: VisualNodeKind.ValueNode,
							value: isRequired,
						},
					},
				},
			},
			children: {},
		};
	}

[Josmithr]

If a field's value is undefined, I think we want to display that fact (i.e., that the data is undefined. But we should omit the schema field for it, since there is no data, so there isn't a corresponding schema.

[Josmithr]

So I would probably make schema an optional property, and omit it for undefined field values.

[Josmithr]

Were we going to change this from requirements: required / optional / identifier to required: true / false?

[jikim-msft]

You're right. With the removal of the getRequirement(), I am simply filtering based on the Required & Optional kinds.

Is the name requirements misleading?

[Josmithr]

Just double-checking: is there an existing "isLeaf" (or something) helper we could use for this check?

[jikim-msft]

Will double check on this. Thanks for the reminder.