-
Notifications
You must be signed in to change notification settings - Fork 350
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
Add ability to group metadata #871
Conversation
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.
Ran it locally and it works, included some review comments below, but I have a small issue with the implementation, it feels more like a "hack" to support the previous implementation (not that it's not a decent working solution). You create an array of categories then create a list of fields that is created by adding fields matching each category one by one. The idea I had in mind during the previous call was a bit different, rather than having two lists it would be one dict. the dict would use each category as a key with each value being the list of fields. This would then combine the two for loops in your code to just one loop. (This is just my opinion, the implementation here is ok and I would be ok with merging it as is, pending my comments below)
// Find categories of all schema properties | ||
for (const schemaProperty in this.schema) { | ||
if (!this.schema[schemaProperty].uihints) { | ||
this.schema[schemaProperty].uihints = {}; |
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 believe we do something similar to this in renderField
might be worth updating that to remove any redundant code.
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.
thanks for the quick updates
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.
Some followup review based on your latest updates. I'll also test it locally but I expect it'll work the same as before
The latest release of JupyterLab updated to the latest release of blueprintjs core, which included an async bugfix for `InputGroup` which broke how our async update interacts with fields. Causing any already rendered `InputGroup` to not update it value on an async call to `uodate()` such as the one we do after calling the metadata api. I solved this by making the rendering of the display_name field conditional on the existance of an inital value, just like we already do with the other fields. Fixes elyra-ai#883
Just pulled in changes from #885 to make sure they're compatible with these changes. |
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.
Tested locally and LGTM
Co-authored-by: Alex Bozarth <ajbozart@us.ibm.com>
Fixes #789. Using an optional "category" field in the "uihints" of a schema, adds a header when a new category encountered.

First pass relies on order of schema properties to determine where to add the headers - planning to incorporate some sorting to make that less reliant on JSON ordering.
Developer's Certificate of Origin 1.1