Skip to content
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

preferences: improve category headers and leaf #8512

Merged
merged 1 commit into from
Sep 22, 2020
Merged

preferences: improve category headers and leaf #8512

merged 1 commit into from
Sep 22, 2020

Conversation

liorfr
Copy link

@liorfr liorfr commented Sep 16, 2020

Fixes issue: #7745

  1. Fixed category bug in the leaf. When the category contains more than one word the leaf contains category words.
  2. Added colon after the subcategory in the leaf
  3. Changed the size of the category and the subcategory

Before
image

After
image

How to test

Open the preferences

Signed-off-by: Lior Frenkel lior.frenkel@sap.com

Review checklist

Reminder for reviewers

@vince-fugnitto vince-fugnitto added preferences issues related to preferences ui/ux issues related to user interface / user experience labels Sep 16, 2020
@vince-fugnitto
Copy link
Member

@colin-grant-work would you like to review the pull-request?

@colin-grant-work
Copy link
Contributor

@vince-fugnitto, sure, I'll take a look later today.

Copy link
Author

@liorfr liorfr left a comment

Choose a reason for hiding this comment

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

@colin-grant-work / @vince-fugnitto, Can you please check my changes?

@colin-grant-work
Copy link
Contributor

It seems we're getting more instances of labels with colons than VSCode. Here's a side-by-side comparison of editor.find:
image
image

I think you may be treating the subcategory name as the leaf name, and the actual property name as the value in some cases.

Copy link
Author

@liorfr liorfr left a comment

Choose a reason for hiding this comment

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

@colin-grant-work

The logic has not changed

Theia before my change
image

Theia after my change
image

We have two cases

Case 1: rawLeafValue exist:

image

Case 2: rawLeafValue does not exist:

image

The preferences behavior in Vs code is different than Theia however I believe that this PR is a step in the right direction. Can we merge this PR and define the new behavior in a new issue?

@colin-grant-work
Copy link
Contributor

I agree your changes are an improvement, but I think we're pretty close to achieving the VSCode-type behavior and still may be able to in this PR:

if three parts (category.subcategory.property)
    use property as leaf name
else if two parts (category.property)
    use property as leaf name

Are there cases that I'm missing where we actually want to include more than the last part as the property name? If not, we can always just use the last segment, and discard the rest.

@vince-fugnitto
Copy link
Member

vince-fugnitto commented Sep 17, 2020

The preferences behavior in Vs code is different than Theia however I believe that this PR is a step in the right direction. Can we merge this PR and define the new behavior in a new issue?

We can of course have an iterative approach to fix the headers if it currently adds value.
However, I don't believe the pull-request as is fixes #7745 (as we want a similar behavior as vscode).

Signed-off-by: Lior Frenkel <lior.frenkel@sap.com>
Copy link
Author

@liorfr liorfr left a comment

Choose a reason for hiding this comment

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

@colin-grant-work, Can you please check my changes?

const propertySpecifier = this.split(property).slice(1);
const name = propertySpecifier.map(word => word.slice(0, 1).toLocaleUpperCase() + word.slice(1)).join(' ').trim();
const rawLeaf = property.split('.').pop();
const name = this.formatString(rawLeaf!);
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks good to me. @vince-fugnitto, I'm a bit wary of the non-null assertion, but I've seen it elsewhere around the repo, and this seems like a fairly safe instance to me. What are your thoughts?

An option to avoid it would be to have .formatString return an empty string when passed undefined.

Copy link
Member

Choose a reason for hiding this comment

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

We could also do the following @colin-grant-work?

const rawLeaf: string = property.split('.').pop() || property;
const name = this.formatString(rawLeaf);

It would be a safeguard against preferences which do not follow the format of being a.b but rather a.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's functionally equivalent to the current code, but it would make Typescript happier 😄 . If there's no ., then the split will just return an array with the whole string at index 0.

Copy link
Member

Choose a reason for hiding this comment

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

I think it's functionally equivalent to the current code, but it would make Typescript happier . If there's no ., then the split will just return an array with the whole string at index 0.

Correct :) if you are wary about uses of it we can think about adding an eslint rule against it: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-non-null-assertion.md. I believe it would benefit the project to be more strict regarding null-checking.

@colin-grant-work
Copy link
Contributor

colin-grant-work commented Sep 17, 2020

@liorfr, the latest changes look good to me, and very close to VSCode. 👍
(Latest version, for comparison with previous)
image

Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

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

The changes look good to me 👍
Thank you for your contribution and for also adding tests!

Copy link
Author

@liorfr liorfr left a comment

Choose a reason for hiding this comment

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

@vince-fugnitto, can you please merge?

@vince-fugnitto
Copy link
Member

@vince-fugnitto, can you please merge?

Sure, I just wanted to give it a couple of days to give others the opportunity to review if they were interested.
I'll merge tomorrow morning if there are no objections.

@colin-grant-work
Copy link
Contributor

This is likely outside of the scope of this PR, but I did notice today a couple of cases where the VSCode label includes a colon and consists of more than the final entry outside of the 'Commonly Used' section:
image
I'm not sure why 'Comments' isn't treated as a full subcategory here. There may be some number of children that a subcategory has to have to receive a full sub-head. I'm fine with the treatment of this type of situation in this PR.

@vince-fugnitto
Copy link
Member

This is likely outside of the scope of this PR, but I did notice today a couple of cases where the VSCode label includes a colon and consists of more than the final entry outside of the 'Commonly Used' section:
image
I'm not sure why 'Comments' isn't treated as a full subcategory here. There may be some number of children that a subcategory has to have to receive a full sub-head. I'm fine with the treatment of this type of situation in this PR.

I think it is something we can fix at a later point, this pull-request is already a step in the right direction 👍

@vince-fugnitto vince-fugnitto merged commit 2d86390 into eclipse-theia:master Sep 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
preferences issues related to preferences ui/ux issues related to user interface / user experience
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants