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

Infra UI cleanup -- and learning resource! #4875

Merged
merged 33 commits into from
Apr 5, 2021

Conversation

SEAjamieD
Copy link
Contributor

@SEAjamieD SEAjamieD commented Mar 25, 2021

🔩 Description: What code changed, and why?

This was a rough and quick first pass at correcting code throughout the infrastructure pages where we've noticed a multitude of mistakes begin to present themselves. While this doesn't cover every piece that needs to be addressed, it shows the depth of the work needed and can hopefully be used as a learning resource as well--both for code authors and for code reviewers!

As you go through this, keep PR #4874 open next to it, so you can see how that revised checklist helps to point you towards things covered here.

⛓️ Related Resources

msorens' remarks: Following on Jamie's introduction above, I thought this would be a good place to reiterate guidelines I put together (over a span of years!) on authoring and on reviewing code.


Reviewing code is just as important as writing code. Really. Here are some important reasons why:

  • It promotes knowledge transfer.
  • It shakes out different ideas/strategies.
  • It encourages team consistency and communication.
  • It helps you improve your craft.
  • It reduces buggy software very cost effectively--as close to inception as possible.

As a Code Author

  1. Be your own first code reviewer. Go through your code thoroughly and provide pre-review comments to your audience. Also look for things your IDE did to "help" you (reformatting, etc).
  2. Distinguish between in-code comments, which describe what is present, and pre-review comments, which describe why it changed.
  3. Also use pre-review comments to filter out noise (e.g. "only function xyz changed in this file; the other 95% of the changes were just reformatting").
  4. Include only one issue in a code review (i.e. apply Single Responsibility Principle) for focus, traceability, and tidiness. It also makes searching commit histories more straightforward.
  5. Exception to above: for those really small or simple–but unrelated–things that are just simpler to include now rather than later, mark them as such by beginning with something like "PR Bonus: ...".
  6. Include all of one issue including, but not limited to: user interface changes, application code changes, documentation updates, help text revisions, database schema revisions, unit test additions, configuration file updates, build script changes, installer tweaks... and do not forget the new files you added! (Note that this is not advocating an entire, humongous feature at one go; rather whatever size piece you are working on, make it complete.)
  7. Rebase your changes so they are on top of the latest code from the main branch before sending out your review.
  8. Verify the four cornerstones: unit tests, lint, build, execution.
  9. Make your presentation shine: spell check, no leftover TODO's, no locally tweaked configuration files, no orphaned properties/variables/files, no missing files.
  10. Always make changes for a reason: you should be able to justify every character you are changing.

As a Code Reviewer

Ultimately your task is to answer the question: do the changes accurately and completely cover the requirements?

  1. Understand the requirements of the issue before you dig into the code, including reading the issue and other pertinent background material.
  2. If there are UI changes, was a screenshot included?
  3. Compare requirements against unit tests (every requirement should be tested)
  4. Compare unit tests against the code under test (all code should be tested)
  5. Review the unit tests as an ensemble (to look for weaknesses, ambiguities, or gaps)
  6. Is each unit test named well? (unambiguous, accurate, complete)
  7. Does each unit test evaluate only one thing?
  8. Do the unit tests have strong coverage? (equivalence class and boundary value analysis)
  9. Is each unit test as simple as possible? (ideally cyclomatic complexity === 1)
  10. Does the code under test follow best practices? (SOLID principles, no magic numbers, etc.)
  11. Can you get by with less code? (is there a simpler way?)
  12. Look beyond the changes, from the low-level (if FooBar is changed to FooBaz, are there instances of Foo-Bar as well?) to the high-level (was the README updated correspondingly?)
  13. Is the code self-documenting? (that is the code itself, minimizing comments)

References

My Zen of Code Review series:


👍 Definition of Done

For this particular PR "Done" means we've effectively begun a cleanup as well as communicated the need for further review.

👟 How to Build and Test the Change

in hab studio
build components/automate-ui-devproxy && start_all_services

in Automate/components/automate-ui folder
make serve

✅ Checklist

📷 Screenshots, if applicable

While many of the fixes are code-based only, much has been showing up in the UI as added white spaces, missing focus rings, 5 to 10 pixel off alignments, etc.
Below is one example

Before
Search button sits outside the Search container with extra white space at the bottom. Create environment button sits below the place of the search bar.
Screen Shot 2021-03-25 at 5 02 23 PM

After
Screen Shot 2021-03-25 at 5 03 04 PM

After
Accessibility rings for the input and search button, Text visible even when screen very condensed.
SearchBarAfter

msorens and others added 22 commits March 25, 2021 09:47
Signed-off-by: michael sorens <[email protected]>
Best way to see the consistency/inconsistency is to search
for all occurrences of "message:" in *.effects.ts.

Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
…ough

These should really get worked through in a more global sense.
I'll connect with UX about how these will look in the future

Signed-off-by: seajamied <[email protected]>
Signed-off-by: seajamied <[email protected]>
I mostly reworked the search bar first so that it is accessible and
next to get all the pixels in the right place.  It could likely be
cleaned up more as well but I think this is a great start

Signed-off-by: seajamied <[email protected]>
Signed-off-by: seajamied <[email protected]>
@netlify
Copy link

netlify bot commented Mar 25, 2021

Deploy preview for chef-automate processing.

Building with commit 27a81ec

https://app.netlify.com/sites/chef-automate/deploys/605d43daa01e330008617248

Copy link
Contributor

@msorens msorens left a comment

Choose a reason for hiding this comment

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

Lots of author notes below. You will see a high correlation between these types of fixes and the new suggested PR template in #4874

@@ -114,7 +114,7 @@ export class CdsEffects {
map((action: DownloadContentItemSuccess) => {
return new CreateNotification({
type: Type.info,
message: `Content Item "${action.payload.name}" was download`
message: `Content Item "${action.payload.name}" was downloaded`
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: grammar

@@ -119,7 +119,7 @@ export class ClientEffects {
map(({ payload: { name } }: DeleteClientSuccess) => {
return new CreateNotification({
type: Type.info,
message: `Successfully Deleted Client - ${name}.`
message: `Successfully deleted client - ${name}.`
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: case consistency -- only the first word should be capitalized.

@@ -51,7 +51,7 @@ export class DataBagItemsEffects {
const msg = payload.error.error;
return new CreateNotification({
type: Type.error,
message: `Could not get infra data bag items: ${msg || payload.error}`
message: `Could not get data bag items: ${msg || payload.error}`
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: consistency -- majority of uses omit the "infra" so several occurrences changed.

@@ -64,7 +64,7 @@ export class DataBagsEffects {
map(({ payload: { databag: dataBag } }: CreateDataBagSuccess) => {
return new CreateNotification({
type: Type.info,
message: `Successfully Created Data Bag ${dataBag.name}.`
message: `Successfully created data bag - ${dataBag.name}.`
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: consistency -- this new pattern is supposed to also include the hyphen.

@@ -130,7 +130,7 @@ export class EnvironmentEffects {
filter(({ payload }: CreateEnvironmentFailure) => payload.status !== HttpStatus.CONFLICT),
map(({ payload }: CreateEnvironmentFailure) => new CreateNotification({
type: Type.error,
message: `Could not create notification: ${payload.error.error || payload}.`
message: `Could not create environment: ${payload.error.error || payload}.`
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: copy/paste error

Comment on lines 32 to 40
[jsonText]="jsonText"
[openEvent]="openEnvironmentModal"
[serverId]="serverId" [orgId]="orgId"
[name]="name" [environment]="environment"
[serverId]="serverId"
[orgId]="orgId"
[name]="name"
[environment]="environment"
[label]="label"
[cookbookConstraints]="cookbookConstraints"
[cookbookVersions]="cookbookVersions">
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: clarity -- do not hide some attributes by putting two on a line just in a couple cases. If short enough, OK to put all on one line. Otherwise, each on a line by itself.

Comment on lines -50 to +52
<img alt="Edit" src="/assets/img/content and icon.png" />
<img alt="Edit" src="/assets/img/content-and-icon.png" />
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: consistency -- no other file uses spaces in the name. (Besides, having spaces in a filename is asking for maintenance headaches.)

Comment on lines -86 to +88
<chef-button class="add-circle" primary (click)="tre.expand()">
<chef-button class="add-circle" primary (click)="tree.expand()">
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: typo -- running make spell would have caught this.

color: #000000;
color: $chef-black;
Copy link
Contributor

Choose a reason for hiding this comment

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

Author note: Do not use color literals in CSS files; always use the provided named constants.

[(ngModel)]="leftFilterText" [disabled]="disabled" placeholder="Search.." />
[(ngModel)]="leftFilterText" [disabled]="disabled" placeholder="Search.." /> <!-- TODO: do not use two-way binding! -->
Copy link
Contributor

Choose a reason for hiding this comment

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

A key tenet of automate design is One-Way Binding. The [(ngModel)] uses two-way binding and needs fixing; just have not done it here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed, will fix these changes in #4540.

seajamied added 6 commits March 25, 2021 13:09
Signed-off-by: seajamied <[email protected]>
Signed-off-by: seajamied <[email protected]>
Signed-off-by: seajamied <[email protected]>
@SEAjamieD SEAjamieD assigned SEAjamieD and msorens and unassigned SEAjamieD Mar 25, 2021
@SEAjamieD SEAjamieD marked this pull request as ready for review March 25, 2021 23:52
@SEAjamieD
Copy link
Contributor Author

Another discovery I came across during this exercise that will need to be examined is the way we are choosing to filter within the infra-search-bar, as we are not catching upper vs lowercase.
Limited Search

@msorens msorens force-pushed the jamie/ms-infra-cleanup-copy branch from 9fdbec6 to 27a81ec Compare March 26, 2021 02:15
@msorens msorens changed the title Infra UI cleanup Infra UI cleanup -- and learning resource! Mar 26, 2021
@@ -48,7 +48,7 @@ export class InfraRoleEffects {
const msg = payload.error.error;
return new CreateNotification({
type: Type.error,
message: `Could not get infra roles: ${msg || payload.error}`
message: `Could not get roles: ${msg || payload.error}`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would infra roles make more sense, as just roles might be confused with internal roles ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Good question! I considered that, but decided against it for two reasons.

  1. Omitting it is more consistent with the rest of the infra pages.
  2. More importantly, the context makes it clear which type of role.
    That said, if you have a strong preference I am fine to change it because your point is valid.

@@ -118,7 +118,7 @@ export class OrgEffects {
map(({ payload: { name } }: DeleteOrgSuccess) => {
return new CreateNotification({
type: Type.info,
message: `Successfully Deleted Organization ${name}.`
message: `Successfully deleted organization ${name}.`
Copy link
Collaborator

Choose a reason for hiding this comment

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

is - needed before ${name}

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes! Good eye! 🔍

@@ -147,7 +147,7 @@ export class OrgEffects {
ofType(OrgActionTypes.UPDATE_SUCCESS),
map(({ payload: { org } }: UpdateOrgSuccess) => new CreateNotification({
type: Type.info,
message: `Successfully Updated Organization ${org.name}.`
message: `Successfully updated organization ${org.name}.`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is - needed before ${org.name} ?

@@ -97,7 +97,7 @@ export class PolicyEffects {
const removeStr = removed.length === 1 ? removed[0].displayName : `${removed.length} members`;
return new CreateNotification({
type: Type.info,
message: `Removed ${removeStr}.`
message: `Removed member(s) ${removeStr}.`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is - needed before ${removeStr} ?

Copy link
Contributor

Choose a reason for hiding this comment

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

OK, the answer here is "no". This is still the old format, the difference is the word "Successfully" is not present here. Jon from UX is well aware of the inconsistencies--I spoke to him about it a couple days ago. Apparently, new code we want to go in with "Successfully - " but I purposely did not change this one because it is "old" code.

@@ -192,7 +192,7 @@ export class ScannerEffects {
}),
map(() => new CreateNotification({
type: Type.info,
message: 'Deleted a scan job.'
message: 'Deleted scan job.'
Copy link
Collaborator

Choose a reason for hiding this comment

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

is ID of Deleted scan job needed here ? if yes, we can add a todo for later, here also.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, should mark with TODO. Every such message should have an ID.

Copy link
Collaborator

@kalroy kalroy left a comment

Choose a reason for hiding this comment

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

Thanks for this detailed information.

Copy link
Collaborator

@vinay033 vinay033 left a comment

Choose a reason for hiding this comment

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

Greate work @SEAjamieD , Thanks for these changes. :)

Copy link
Contributor

@himanshi-chhabra himanshi-chhabra left a comment

Choose a reason for hiding this comment

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

Changes Look good to me.
Just one opinion, as per new Notification UX in success/update notifications we have added Successfully text, and in some cases, it's not added.
eg: In infra-role: L88 : message: `Created role ${name}
and in databag-item: L71: message: Successfully created data bag item ${id}.

we can make these changes in this issue: #4873

@himanshi-chhabra
Copy link
Contributor

Another discovery I came across during this exercise that will need to be examined is the way we are choosing to filter within the infra-search-bar, as we are not catching upper vs lowercase.
Limited Search

@SEAjamieD According to chef-manage, we have a case-sensitive filter within infra-search-bar through API. I have shared a scenario below files.

G-search-keyword
go-search-keyword
g-search-keyword

@SEAjamieD SEAjamieD merged commit 239f829 into master Apr 5, 2021
@SEAjamieD SEAjamieD deleted the jamie/ms-infra-cleanup-copy branch April 5, 2021 15:52
@SEAjamieD
Copy link
Contributor Author

Another discovery I came across during this exercise that will need to be examined is the way we are choosing to filter within the infra-search-bar, as we are not catching upper vs lowercase.

Thanks @himanshi-chhabra - Is this by design? or should we update this to catch both upper and lowercase?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants