Sent all the panel sizes via onPanelWidthChange in EuiResizableComponent rather than just the 2 panel sizes

[shrey]

Summary

Sending all the panel sizes via the onPanelWidthChange function in EuiResizableComponent rather than just the size for the 2 panels.

Checklist

• [ ] Check against all themes for compatibility in both light and dark modes
• [ ] Checked in mobile
• [ ] Checked in IE11 and Firefox
• [ ] Props have proper autodocs
• [ ] Added documentation
• [ ] Checked Code Sandbox works for the any docs examples
• [ ] Added or updated jest tests
• [ ] Checked for breaking changes and labeled appropriately
• [ ] Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately
  @thompsongl @chandlerprall the onPanelWIdthChange function does return all the values, you can check it by logging it in the 3 panel example, but there's some issue with the value, what do you suggest?
  onPanelWidthChange for EuiResizeableContainer only provides sizes for two panels #3466

[kibanamachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[chandlerprall]

but there's some issue with the value, what do you suggest?

You're adding the size of the panels as pixels, where the existing onPanelWidthChange callback specifies the values in percentages.

Also,

• When adding onPanelWidthChange={console.log} to the three panel example, the panels should continue to be resizable. This change between controlled/uncontrolled should be determined by the existence of the size prop, but is currently solely based on onPanelWidthChange (https://github.com/elastic/eui/pull/3630/files#diff-021245ddce286351697a251b107f2c72R150)
• there are a few lint errors, please run yarn test locally to identity them and clean them up. There is a commit hook in place that is supposed to validate changes before they can be committed; I'm curious what you're using to commit your changes, that doesn't seem to be running the hook? (git cli, tower, etc)

[shrey]

@chandlerprall Yeah, I forgot to fix the lint errors, sorry, I used git commit -m "" -n as the usual commit used to take too much time

if (prevPanelSize!==nextPanelSize && onPanelWidthChange), will this suffice?

[shrey]

@chandlerprall I've fixed the lint error and the percentages, could you review it

[thompsongl]

This point still needs to be addressed

When adding onPanelWidthChange={console.log} to the three panel example, the panels should continue to be resizable. This change between controlled/uncontrolled should be determined by the existence of the size prop, but is currently solely based on onPanelWidthChange (https://github.com/elastic/eui/pull/3630/files#diff-021245ddce286351697a251b107f2c72R150)

When setting onPanelWidthChange and not setting size on the panels, no resize changes actually occur.

[shrey]

@thompsongl Yeah, I did notice that, but I think when user uses the onPanelWidthChange property, the size change is orchestrated by the user itself in the examples, because I even checked in the original docs example, if I solely have a onPanelWidthChange property and console.log the sizes, the draggable panel continues to be non-responsive

[thompsongl]

I think when user uses the onPanelWidthChange property, the size change is orchestrated by the user itself

This is how the component currently works, but the goal of the issue is to change that behavior. When onPanelWidthChange is in use and the consumer is not orchestrating the panel sizes with the size prop, the panels should resize as though onPanelWidthChange is not set. The size prop should be used to determine controlled vs. uncontrolled behavior, not the onPanelWidthChange prop.

The use case is that a consumer might want to perform a side effect with the panel width values (provided by the onPanelWidthChange callback), but have the component automatically adjust sizes while dragging.

[shrey]

@thompsongl Okay, on it :)

[shrey]

@thompsongl Done, Is this what was needed?

[shrey]

@thompsongl size prop would always be present, right?

[thompsongl]

size prop would always be present, right?

No, the initialSize prop can be used instead for uncontrolled components. Looks like the logic was already in place for size to guard against unnecessary state updates.

[shrey]

size prop would always be present, right?

No, the initialSize prop can be used instead for uncontrolled components. Looks like the logic was already in place for size to guard against unnecessary state updates.

Yeah, So Do I need to make any changes now?

[thompsongl]

About ready! Still needs a changelog entry

[shrey]

@thompsongl Done :)

[thompsongl]

jenkins test this

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_3630/

[shrey]

@thompsongl tests passed :)

[shrey]

@thompsongl any updates?