Change location of copy to clipboard button

[filiprejmus]

Change the location of the copy to clipboard button

Description

This PR moves the copy to clipboard button to a location where it doesn't cause other elements to move in the operation summary bar. It addresses this issue and is providing the exact same change as this PR which unfortunately seems to be abandoned.
Credit to @almirus

Motivation and Context

Fixes #8153 and #8131

How Has This Been Tested?

I built and ran the changed code locally and confirmed that the button now has improved behaviour.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[ponelat]

Thanks for the PR. @filiprejmus would you mind taking a screenshot of the new location, so we can expedite the review? I know we've had several requests to move it around, and honestly not sure which is best.

[filiprejmus]

The button still shows up on hover

[romanblanco]

The button still shows up on hover

I think the important is that the icon to expand the detail stays on it's place.

[char0n]

Hi everybody,

To get a guidance how to solve this problem properly, we can look into Material Design Specification. Specifically looking at Angular reference implementation of Material Design, we can learn what is the most appropriate placing of icons in expandable like component.

Expandable component has a concept of Action Bar. If Action Bar is used, it's located on the right side of expandable component. "chevron" icon is always placed as the right-most icon. Additional fixed icons are placed left to the "chevron" icon. Icons that are appearing on hover must be placed left of fixed icons, so that no horizontal component shifts happen.

---

I would suggest the icons on our expandable Operation component will have following placing:

--------------------------------------------------------------------------------------------------------
[ POST ]    /pet   Add a new pet to the store                                  {copy}  [lock]  [chevron]
--------------------------------------------------------------------------------------------------------

• {<label>} notation represents icons appearing on hover
• [<label>] notation represents fixed icons

[char0n]

@romanblanco if you agree with the suggestion, please redo the PR according to Material Design spec.

If you do not agree, let's discuss further.

[filiprejmus]

@char0n so you suggest to switch chevron and lock?

[romanblanco]

diff --git a/src/core/components/operation-summary.jsx b/src/core/components/operation-summary.jsx
index fd61c0d2..702ceb04 100644
--- a/src/core/components/operation-summary.jsx
+++ b/src/core/components/operation-summary.jsx
@@ -80,8 +80,8 @@ export default class OperationSummary extends PureComponent {
             </div>
           }

-          {displayOperationId && (originalOperationId || operationId) ? <span className="opblock-summary-operation-id">{originalOperationId || operationId}</span> : null}
           <CopyToClipboardBtn textToCopy={`${specPath.get(1)}`} />
+          {displayOperationId && (originalOperationId || operationId) ? <span className="opblock-summary-operation-id">{originalOperationId || operationId}</span> : null}
           <svg className="arrow" width="20" height="20" aria-hidden="true" focusable="false">
             <use href={isShown ? "#large-arrow-up" : "#large-arrow-down"} xlinkHref={isShown ? "#large-arrow-up" : "#large-arrow-down"} />
           </svg>

[char0n]

Hi @filiprejmus,

Yes I would suggest that, given it's a Material Design recommendation and will allow us to extend the Action bar in consistent way in future. What do you think?

PS: Sorry I confused the ownership of this PR and asked @romanblanco to redo the PR, but you're the author obviously.

[filiprejmus]

@char0n Sounds good, seems way more natural now that I think about it. I will push it sometime next week!

[char0n]

@char0n Sounds good, seems way more natural now that I think about it. I will push it sometime next week!

Yeah I agree, Material Design was created by learning from natural human interaction patterns. They did a great job in Google on it.

[filiprejmus]

@char0n changing the location of the lock is a bit more tricky. So right now we have the lock on the very right that opens a modal on click and everything on the left of it which collapses/uncollapses the expanded view on click. Now moving the lock in the middle would mess with this clear separation. On the other hand it doesn't make sense that clicking the copy to clipboard button also uncollapses the operation component. My suggestion would be to only collapse/uncollapse when clicking on the chevron but since that behaviour has been around since the beginning of Swagger UI, I feel it could confuse a lot of users.

Another Option could be to collapse when clicking anywhere but the lock and the copy button. Honestly I feel like we should go with that. Do you have any other idea how to proceed with this?

[filiprejmus]

Here my new suggestion with the last commit! Unfortunately I had to remove the black outline that appears on focus for the moment as the shifting around made it complicated to keep. Thoughts on this look? @char0n

[filiprejmus]

@char0n ping since there was no follow up in a minute

[filiprejmus]

@char0n ping :) don't want this to die

[dinbtechit]

Someone, please approve this PR!!!!

[char0n]

@filiprejmus sorry for delays. Looking at this now again.

[char0n]

@filiprejmus I would agree with the visual representation. But what we lost is a keyboard navigation indicator. The "black outline that appears on focus" was very important as it focused the entire operation row and it was clear we could press enter to expand it, when focused.

Before

swagger-ui-before-keybord-navigation.mp4

After

swagger-ui-after-keyword-navigation.mp4

---

In the After video, when I navigate with keyboard (Tab key), I've expanded one operation by pressing Enter. But we're missing indicator what's currently focused. We have to think now, how to solve this.

[char0n]

@filiprejmus I've issued #9111 which supersedes this PR. PR contains explanation and video how the keyboard navigation and elements now behave. Let me know what you think.

[char0n]

Closing in favor of #9111. Thank you very much @filiprejmus for pushing this forward.