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

jikim-msft · 2025-01-16T01:09:46Z

Description

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
Non-Leaf Node

Leaf Node

This reverts commit fd50e40.

jikim-msft · 2025-01-16T01:14:34Z

packages/tools/devtools/devtools-core/src/test/DefaultVisualizers.spec.ts

@@ -1730,6 +1730,380 @@ describe("DefaultVisualizers unit tests", () => {
 		expect(result).to.deep.equal(expected);
 	});

+	it.only("SharedTree: Renders multiple allowed types in SharedTree's root field", async () => {


Will be removing only() (and the one below), once we agree on the structure of the visualization (especially adding the root layer).

jikim-msft · 2025-01-16T01:20:09Z

packages/tools/devtools/devtools-core/src/data-visualization/DefaultVisualizers.ts

+			allowedTypes: concatenateTypes(treeSchema.allowedTypes),
+		},
+		fields: {
+			root: await visualizeSharedTreeNodeBySchema(treeView, treeSchema, visualizeChildData),


Initially thought of replacing this with visualizeVerboseNodeFields() which iterates through tree.fields.

However, a leaf node in the root of the field can not have type VerboseTreeNode from exportVerbose() which is the expected type of visualizeVerboseNodeFields().

Maybe @CraigMacomber can offer some recommendations around typing here?

consider also note (and test) that the root can be optional, and undefined. There is error thrown in that case above this: this case should also be fixed.

I think the fix that makes sense here is to handle the root using the same code which handles fields of objects. Both have a field schema, and the same set of things that could be in the content or schema. The document root really is the same as an object node field: they use the same types and implementation.

Factor out a function from the object node handling code which takes in a field schema and its content, then call that with treeView (up on line 268) instead of all this logic.

packages/tools/devtools/devtools-core/src/data-visualization/DefaultVisualizers.ts

Josmithr · 2025-01-16T01:39:31Z

packages/tools/devtools/devtools-core/src/data-visualization/DefaultVisualizers.ts

-		visualizeChildData,
-	);
+	const sf = new SchemaFactory(undefined);
+	const schemaName = Tree.is(treeView, [sf.boolean, sf.null, sf.number, sf.handle, sf.string])


Do we need to special-case primitives here? Can we not just use Tree.schema(treeView).identifier?

TreeNodeApi.schema accepts either a TreeNode or a TreeLeafValue.

If TreeView is a non-leaf node (thus has a type of VerboseTree), I believe we should use type to get its metadata.

packages/tools/devtools/devtools-core/src/test/DefaultVisualizers.spec.ts

jikim-msft · 2025-01-17T20:02:02Z

packages/tools/devtools/devtools-test-app/src/FluidObject.ts

+		}) {}
+
+		class RootNodeTwo extends builder.object("root-node-two", {
+			childField: builder.optional(RootNodeTwoItem),


builder.optional added to ensure rendering undefined object.

jikim-msft · 2025-01-17T20:03:07Z

packages/tools/devtools/devtools-core/src/data-visualization/DefaultVisualizers.ts

 	if (treeView === undefined) {
-		throw new Error("Support for visualizing empty trees is not implemented");
+		return {


Initializing the view with view.initialize({}) will render:

jikim-msft · 2025-01-17T23:21:04Z

packages/tools/devtools/devtools-core/src/data-visualization/SharedTreeVisualizer.ts

+	tree: VerboseTree,
+	treeSchema: SimpleTreeSchema,
+	visualizeChildData: VisualizeChildData,
+	isRootField?: boolean,


@Josmithr

Interested in your thoughts of this optional parameter. This is to display all the allowed types of the "first" rootfield when it is populated by the leaf-node.

This shouldn't be needed. Fundamentally, there is no difference between the root field and any other.

Where we're using it below - does this not recreate the same issue we're trying to fix? E.g., if the root field allows number | string, but the tree is of type number, won't that just display "number" when we want "number | string"?

No, excuse me, I was reading the code backwards. I think the change creates the problem for non-root fields?

Shouldn't we just always call concatenateTypes(treeSchema.allowedTypes)?

The problem I was seeing was that unless I have this condition (just concatenateTypes(treeSchema.allowedTypes)), all the leaf nodes that are at the sub-root-fields display the allowed types under the tree root.

class RootNodeTwoItem extends builder.object("root-node-item", { childrenOne: builder.number, // Should display number childrenTwo: RootNodeTwoItemTwo, }) {}

This is because the SimpleTreeSchema.allowedTypes gives the allowedTypes directly under the root. Thus, I was inclined to add a filter here.

What is the root schema in this example?

The one that is in the FluidObject.ts.

This is also why I have the condition in the visualizeObjectNode().

Oh, I see. In that case, an easier fix might just be to take in the allowedTypes instead of treeSchema. Then each place that calls this can just pass in the appropriate items.

But I would recommend taking in a list of types, rather than the concatenated string.

jikim-msft added 3 commits January 16, 2025 00:31

include allowedTypes for root field

df3da17

add condition

fd50e40

Revert "add condition"

cf42f7a

This reverts commit fd50e40.

github-actions bot added the base: main PRs targeted against main branch label Jan 16, 2025

jikim-msft commented Jan 16, 2025

View reviewed changes

Josmithr reviewed Jan 16, 2025

View reviewed changes

packages/tools/devtools/devtools-core/src/data-visualization/DefaultVisualizers.ts Outdated Show resolved Hide resolved

Josmithr reviewed Jan 16, 2025

View reviewed changes

packages/tools/devtools/devtools-core/src/test/DefaultVisualizers.spec.ts Outdated Show resolved Hide resolved

jikim-msft added 3 commits January 16, 2025 09:51

Merge branch 'main' into devtools/shared-tree-visualizer

1e29755

Merge branch 'main' into devtools/shared-tree-visualizer

5e96b73

change variable name & remove test

9a6793a

jikim-msft requested a review from CraigMacomber January 16, 2025 19:51

jikim-msft added 3 commits January 17, 2025 19:38

Co-authored-by: Joshua Smithrud <[email protected]>

d4c4901

change name

4990a60

handle undefined

363ced9

jikim-msft commented Jan 17, 2025

View reviewed changes

refactor / undefined

dbf8f9b

jikim-msft commented Jan 17, 2025

View reviewed changes

jikim-msft requested a review from Josmithr January 17, 2025 23:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

jikim-msft commented Jan 16, 2025 •

edited

Loading

jikim-msft Jan 16, 2025

jikim-msft Jan 16, 2025

Josmithr Jan 16, 2025

CraigMacomber Jan 16, 2025 •

edited

Loading

Josmithr Jan 16, 2025 •

edited

Loading

jikim-msft Jan 16, 2025

jikim-msft Jan 17, 2025

jikim-msft Jan 17, 2025

jikim-msft Jan 17, 2025

Josmithr Jan 17, 2025 •

edited

Loading

Josmithr Jan 17, 2025

jikim-msft Jan 18, 2025 •

edited

Loading

Josmithr Jan 18, 2025

jikim-msft Jan 18, 2025

Josmithr Jan 18, 2025

Josmithr Jan 18, 2025

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

Are you sure you want to change the base?

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

Conversation

jikim-msft commented Jan 16, 2025 • edited Loading

Description

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CraigMacomber Jan 16, 2025 • edited Loading

Choose a reason for hiding this comment

Josmithr Jan 16, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Josmithr Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jikim-msft Jan 18, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jikim-msft commented Jan 16, 2025 •

edited

Loading

CraigMacomber Jan 16, 2025 •

edited

Loading

Josmithr Jan 16, 2025 •

edited

Loading

Josmithr Jan 17, 2025 •

edited

Loading

jikim-msft Jan 18, 2025 •

edited

Loading