Skip to content

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

Merged
merged 5 commits into from
Aug 28, 2018

Conversation

edgarmueller
Copy link
Contributor

@edgarmueller edgarmueller commented Aug 8, 2018

This is a 1st attempt at removing the assumption that relevant subschemas have to be annotated with $id when using the TreeWithDetail 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. Tthe modelMapping, 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 $ids.

Relevant changes also include:

  • Move traverse to common util
  • Remove reference service (if this is in use anywhere it should be moved there, this is currently dead code)
  • Export UISchemaTester type
  • Remove treeWithDetail/editor reducer
  • Use UI schemas state to register detail UI schemas
  • Rename types in TreeWithDetailRenderer for consistency reasons

@coveralls
Copy link

coveralls commented Aug 8, 2018

Coverage Status

Coverage increased (+0.7%) to 89.55% when pulling e81101e on edgarmueller:master into 14b21da on eclipsesource:master.

@@ -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,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix casts

Copy link
Contributor

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?

Copy link
Contributor

@AhmetTanakol AhmetTanakol left a 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';
Copy link
Contributor

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.

Copy link
Contributor Author

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>,
Copy link
Contributor

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,
Copy link
Contributor

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;
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@eneufeld
Copy link
Member

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
@edgarmueller
Copy link
Contributor Author

@eneufeld I've rebased my changes, please have a look again

Copy link
Member

@eneufeld eneufeld left a 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 => {
Copy link
Member

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?

@edgarmueller edgarmueller merged commit c6e7f43 into eclipsesource:master Aug 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants