fix: use passed size in pixel without waiting for resizeObserver

[markov00]

Summary

This change bypasses the need for one ResizeObserver event when passing chart size in pixel.
This avoid double re-renders with different sizes in the case of a datum + size change from the caller component.

Issues

fix #2238
fix #909

Checklist

• The proper chart type label has been added (e.g. :xy, :partition)
• The proper feature labels have been added (e.g. :interactions, :axis)
• All related issues have been linked (i.e. closes #123, fixes #123)
• Unit tests have been added or updated to match the most common scenarios
• The code has been checked for cross-browser compatibility (Chrome, Firefox, Safari, Edge)

[markov00]

buildkite test this

[drewdaemon]

Hmm, I still see the text bounce... did I miss something?

Screen.Recording.2023-12-07.at.8.29.31.AM.mov

[markov00]

Hmm, I still see the text bounce... did I miss something?

Correct, I may have messed up with something here, let me check again thanks for the heads up

[markov00]

buildkite update screenshots

[markov00]

@drewdaemon ok so I've adjusted the example in Storybook, it works fine now:

• if the chart is resizable (like a panel in a dashboard) external container and the Chart size should be configured at 100% width/height
• if the sizing is constrained then both the container and the Chart size need to be configured in pixels

[drewdaemon]

The changes to the storybook may mark a departure from how this will be used in Kibana.

The way we have things set up creates a delay between when we apply the new CSS to the parent container and when we find out the true container dimensions the browser assigned.

For example, I could set the CSS on the parent container to the following

    height: 100%;
    width: 100%;
    max-width: 200px;
    max-height: 1200px 

Here I'm requesting a width of 200px and a height of 1200px. But, the parent of the parent container may only be 600px tall.

So, the application code would be telling Elastic charts that the text size should be based on a 200x1200 container when it's really in a 200x600 container.

If the client detects that the true size is 200x600 and tells Elastic charts, the text size will be corrected. But this just leads to the same bouncing behavior as we see today.

This is the reason I wondered about using CSS container queries to decouple the text size from the React render cycle.

As far as I can see, forcing the client to choose between "resizable" mode and "static" mode doesn't fit the experience we're trying to deliver.

Might be easiest to sync on this problem. Maybe there's some change I can make on my end as well.

[markov00]

The changes to the storybook may mark a departure from how this will be used in Kibana.

The way we have things set up creates a delay between when we apply the new CSS to the parent container and when we find out the true container dimensions the browser assigned.

For example, I could set the CSS on the parent container to the following

    height: 100%;
    width: 100%;
    max-width: 200px;
    max-height: 1200px 

Here I'm requesting a width of 200px and a height of 1200px. But, the parent of the parent container may only be 600px tall.

So, the application code would be telling Elastic charts that the text size should be based on a 200x1200 container when it's really in a 200x600 container.

If the client detects that the true size is 200x600 and tells Elastic charts, the text size will be corrected. But this just leads to the same bouncing behavior as we see today.

This is the reason I wondered about using CSS container queries to decouple the text size from the React render cycle.

As far as I can see, forcing the client to choose between "resizable" mode and "static" mode doesn't fit the experience we're trying to deliver.

Might be easiest to sync on this problem. Maybe there's some change I can make on my end as well.

@drewdaemon let's sync on this together, I'm not fully sure I'm aligned with how you are currently handing this in Kibana

[markov00]

just waiting on elastic/kibana#173772 to be merged

[markov00]

@nickofthyme can you review this please?

[nickofthyme]

Looks good to me, I don't see any issues with these change in code or in storybook.