-
Notifications
You must be signed in to change notification settings - Fork 391
Remove $id dependency from property util #1052
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -56,7 +53,7 @@ export const findPropertyLabel = (property: Property): string => { | |||
[ | |||
property.schema.title, | |||
property.label, | |||
property.schema.$id, | |||
(property.schema as any).$id || (property.schema as any).id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix casts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since using id
is not mandatory, should we really check this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to look at it in detail. It is hard to make assumptions on efficiency but maybe we can try to cache matching schema. We can save the matching ones in a map so that before traversing we can check whether the schema that we are looking for exists in the map.
@@ -1,17 +1,14 @@ | |||
import * as _ from 'lodash'; | |||
import { JsonSchema7 } from '@jsonforms/core'; | |||
import { JsonSchema } from '@jsonforms/core'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we using version 4? If yes, this might cause inconsistencies for the applications that depend on material-tree-renderer. As I remembered using version 7 in ui-schema-editor with material-tree-renderer which depends on version 4 was problematic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JsonSchema
is a union type of JsonSchema4
and JsonSchema7
, so that should be fine I guess, or did I miss something?
schema: JsonSchema, | ||
rootSchema: JsonSchema, | ||
isInContainer: boolean, | ||
visisted: Map<string, string>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a typo
@@ -56,7 +53,7 @@ export const findPropertyLabel = (property: Property): string => { | |||
[ | |||
property.schema.title, | |||
property.label, | |||
property.schema.$id, | |||
(property.schema as any).$id || (property.schema as any).id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since using id
is not mandatory, should we really check this?
]; | ||
|
||
const filterPredicate = () => (property: Property): boolean => | ||
traverse(taskSchema, subSchema => subSchema === property.schema) !== undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe instead of ===
, we can use _.isEqual()
for deep comparison
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This always returned false, I'm wondering why this actually worked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, got it, traverse
always returns a boolean
(which is kinda weird, but that's a different story), hence the expression evaluated to true. I hopefully fixed this by tracking the schema path in findContainerProps
as well and maintaining an additional property orgSchema
in Property
which is the reference to the sub schema of the root schema, so that we are able to compare by reference here.
I like the change, but I would still suggest to split it into at least two part, one being the refactoring of the label and image provider and a second being the change of the resolver. |
* Remove $id properties from schema * Remove obsolete treeWithDetailReducer and init state * Use simple functions for providing labels and images * Remove config.ts * Remove resolving of $refs
@eneufeld I've rebased my changes, please have a look again |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
return label; | ||
} | ||
} | ||
(schema: JsonSchema7) => (element: any): string => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we remove all the JsonSchema7 stuff and replace it with JsonSchema?
This is a 1st attempt at removing the assumption that relevant subschemas have to be annotated with
$id
when using theTreeWithDetail
renderer. These changes might cause the renderer to be somewhat slower as we can not lookup the container properties anymore, but instead re-calculate them. It also depends on a deep equal comparison of the involved schemas. TthemodelMapping
, label and image provider are pure functions now. Declarative maps can still be provided by creating helpers around these functions, e.g. we could do so in the theia-tree-editor extension. I believe these changes have simplified the code a bit, and we can still re-introduce lookups later as an optimization step, in case the schema provides$id
s.Relevant changes also include:
traverse
to common utilUISchemaTester
typetreeWithDetail
/editor
reducerTreeWithDetailRenderer
for consistency reasons