feat(devtools-core): Render ST's Visualizer to Include Root Field's Allowed Types #23573
Conversation
This reverts commit fd50e40.
| @@ -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 () => { | |||
There was a problem hiding this comment.
Will be removing only() (and the one below), once we agree on the structure of the visualization (especially adding the root layer).
| allowedTypes: concatenateTypes(treeSchema.allowedTypes), | ||
| }, | ||
| fields: { | ||
| root: await visualizeSharedTreeNodeBySchema(treeView, treeSchema, visualizeChildData), |
There was a problem hiding this comment.
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().
There was a problem hiding this comment.
Maybe @CraigMacomber can offer some recommendations around typing here?
There was a problem hiding this comment.
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
Outdated
Show resolved
Hide resolved
| visualizeChildData, | ||
| ); | ||
| const sf = new SchemaFactory(undefined); | ||
| const schemaName = Tree.is(treeView, [sf.boolean, sf.null, sf.number, sf.handle, sf.string]) |
There was a problem hiding this comment.
Do we need to special-case primitives here? Can we not just use Tree.schema(treeView).identifier?
There was a problem hiding this comment.
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
Outdated
Show resolved
Hide resolved
| }) {} | ||
|
|
||
| class RootNodeTwo extends builder.object("root-node-two", { | ||
| childField: builder.optional(RootNodeTwoItem), |
There was a problem hiding this comment.
builder.optional added to ensure rendering undefined object.
| if (treeView === undefined) { | ||
| throw new Error("Support for visualizing empty trees is not implemented"); | ||
| return { |
There was a problem hiding this comment.
Initializing the view with view.initialize({}) will render:
| tree: VerboseTree, | ||
| treeSchema: SimpleTreeSchema, | ||
| visualizeChildData: VisualizeChildData, | ||
| isRootField?: boolean, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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)?
Description
26472
The current visualization generation logic in
DefaultVisualizers.tstreats 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
Before
After
Non-Leaf Node
Leaf Node
