#2137 Resize Right Flyout using drag

[srikant-ch5]

Fixes: #2137

Developer's Certificate of Origin 1.1

   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

[srikant-ch5]

Old PR: #2138

[srikant-ch5]

Hi @matthoward366 Is it ok to include properties-right-flyout-container the way I included it in this PR or will it break any functionality in the consuming applications ?
I included it to align the resize button so that content spreads out in the properties-panel.
( I will include comments and will refactor the code in following commits)

[matthoward366]

@nmgokhale can you have a look?

[srikant-ch5]

@tomlyn Could you please let me know whether cc-rightflyout code is ok ? I have tried to keep it just like cc-bottompanel with few changes like using ref to limit panel to 70%.

[tomlyn]

Can't this code be structured the same way as we do it for left flyout below? That is, package it in a function; return null if the panel is not open etc. I'd like the code that handles the left flyout and the code that handles the right flyout be as much as possible structured in the same way.

[srikant-ch5]

Updated to include isRightPanelOpen also updated common-canvas-test.js as the condition { showRightFlyout: false } was failing because of the change.

[tomlyn]

If you look at the comments this is in a section for 'Bottom panel methods'. There is a section above for 'Right flyout methods' where this code should go.

Also in the 'Right flyout methods' can we add a isRightFlyoutOpen() method to keep things consistent?

[srikant-ch5]

I have updated as per above comment.

[tomlyn]

Well if it works I suppose it's OK but it isn't the same as the way bottom panel is structured which is what I was looking for or -- as I said previously -- if the way you have written the new code is somehow better than the way bottom panel is done then we should discuss making bottom panel work the same way. I probably haven't looked at it closely enough but I'm not sure why you are using the ref

Also, if we are going to use refs, I thought the appropriate way to create them is to use the createRef() function
https://react.dev/reference/react/createRef At least that is how I have created them in other class components that we have in Common Canvas.

[tomlyn]

Also, don't forget we will need a few Cypress tests for this new function.

[srikant-ch5]

Well if it works I suppose it's OK but it isn't the same as the way bottom panel is structured which is what I was looking for or -- as I said previously -- if the way you have written the new code is somehow better than the way bottom panel is done then we should discuss making bottom panel work the same way. I probably haven't looked at it closely enough but I'm not sure why you are using the ref

I have updated the code to be pretty much like bottom-panel apart from the limitWidth function because as per requirement panel should should extend upto 70% leaving 30% width for canvas. Unlike bottom-panel right-panel is a part of a grid.

Also, if we are going to use refs, I thought the appropriate way to create them is to use the createRef() function https://react.dev/reference/react/createRef At least that is how I have created them in other class components that we have in Common Canvas.

I have removed refs. Thanks.

Also, don't forget we will need a few Cypress tests for this new function.

I have included some Cypress Tests for the new function. In the build I can see the few Cypress Tests are failing which when I test in my local (even in local prod env) they are passing, so will look into this issue.

[tomlyn]

@srikant-ch5 Looks good so far. I added a few comments.

[tomlyn]

This is creating a dependency from Common Properties on Common Canvas. You could discuss with @matthoward366 @nmgokhale and @caritaou but I don't think we should be doing that. Common Properties and Common Canvas should remained decoupled, so each can always be used independently of the other.

[srikant-ch5]

@nmgokhale Would appreciate your feedback on above I can see similar common properties dependancy on common canvas over here

Without enforcing width to right-flyout in properties it will look something like below, where the properties content width is set as per custom classnames but flyout width is not reset.

[tomlyn]

What is this for - is it necessary? I took it out and the right flyout seems to size OK. If this is needed to get Common Properties to display correctly? If so it ought to be part of the Common Properties CSS, not here.

[srikant-ch5]

I have updated above to include spacing-01 in right-flyout-drag.

But the problem with above spacing is that when a common properties Accordion is highlighted on click there is a small gap between right flyout left border and common properties.

I tried to resolve this using common properties css but this is visible in canvas so initially I set the width to 0.5px so that the gap isn't visible and on hover it will take up 1px width to match with bottom panel, but I have reverted it now and kept spacing-01 for the right-flyout-drag.

Screen.Recording.2024-11-12.at.10.42.51.PM.mov

[tomlyn]

If you are concerned about the visual appearance of the UI after you've implemented a change you should be asking @Analuisa-Del-Rivero1 for her decision on how she wants it to appear. Unfortunately your video doesn't show what it looks like with the accordion highlighting.

[tomlyn]

BTW It's probably best to ask question to Ana in the issue to keep all the design information discussion together in one place.

[tomlyn]

Perhaps you could do a video (or two?) that shows both approaches and what the accordion looks like in each case and explain to her about the difficulty in hovering over the drag area ... and see what she decides.