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

compents width is not right #460

Closed
WeiShengv99 opened this issue Nov 2, 2021 · 5 comments
Closed

compents width is not right #460

WeiShengv99 opened this issue Nov 2, 2021 · 5 comments

Comments

@WeiShengv99
Copy link

WeiShengv99 commented Nov 2, 2021

version : 3.0.2

In my case when compents render , the compents width is not right ,it get window width ,not parents width,It contains slider width.

in doc demo ,i also find the same problem
first
open https://git.hust.cc/echarts-for-react/
second
go to demo page, you can see cmp width also not right,
but if you change the window size, the resize is working right.

i change version to 3.0.0, the problem is reslove, it seem like getBoundingClientRect not right in flex element or something, ..or get the error wrapper width,

here is demo for codesandbox

ps: sorry my english is bad, i hope you can understand what i mean...
image
image

@hustcc
Copy link
Owner

hustcc commented Nov 3, 2021

@mobeigi Your pull request may have caused this problem.

@WeiShengv99 You can lock version @3.0.1

@mobeigi
Copy link
Collaborator

mobeigi commented Nov 3, 2021

This changed behaviour is caused by: #458

This problem is only caused when there is no defined width or height.

Previously there would a resize after the first render which would make echarts fit its parent container. When that PR stopped the resize from happening to let animation work it prevented this auto resizing.

From the echarts documentation:
https://echarts.apache.org/en/api.html#echarts.init

Attention: If div is hidden, ECharts initialization tends to fail due to the lack of width and height information. In this case, you can explicitly specify style.width and style.height of div, or manually call echartsInstance.resize after showing div.

Some solutions would be:

  • Have library do: render → init → resize → init (but make sure that animations still work on the final init)
  • Figure out the final width / height of echarts prior to initial init and pass through width and height through opts on first init (render -> init)

I will try to investigate later to see if there is a nice fix for this.

@mobeigi
Copy link
Collaborator

mobeigi commented Nov 7, 2021

I did some investigation.

It looks like internally echarts will change the size of this.ele (the element) after calling init after some time. I'm not sure but maybe the animation code of zrender changes the size after 1 frame?

There are two solutions.

Method 1

The best solution is to know the width and height before the first init but because echarts seems to change the element size. The size of element is changed after init and as initial animations start.
It looks like its impossible to know the size unless you mimic internal echarts package sizing code.

Method 2

The second way is to do a temporary render to get the correct size and then dispose temporary echarts and init again.

I have an example branch here with these changes:
mobeigi@bf7f9a7

The lifecycle looks like this:

render
componentDidMount
renderNewEcharts
initEchartsInstance
dispose
updateEChartsOption
bindEvents
bindResize
resize

Unfortunately, we cannot just call resize() because it will interrupt animations which is what #458 fixed in 3.0.2.

With this commit:

  • Initial size is correct for no width specified + custom width specified
  • Further resizing works normally
  • Initial loading animations work as expected

The problems with this method:

  • There can be scrollbars showing for a small amount of time (also problem with 3.0.1)
  • There is warning from size sensor because we try to clear when we have not bound resizing yet for temporary element. (can be fixed if we use class to track binding)

Video

JEjFOepgm2.mp4

Conclusion

Method 2 isn't very nice but with the above changes it will behave closer to 3.0.1 but with animations working. However, I did not do extensive testing with many different width/height combinations.

If we could get the correct final size from echarts library and do only 1 init that would be the ideal solution.

@mobeigi
Copy link
Collaborator

mobeigi commented Dec 22, 2021

After some more investigation, I believe Method 2 is our only option. It will behave very similarly to v3.0.1 but with initial animations working. I put up a PR (#464) and if it looks good we can probably release v3.0.3.

@hustcc @WeiShengv99

@financialtugas
Copy link

Hi, very nice work for solving this issue, it was causing me trouble, it would be great if it was ready in production soon.🙌

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

No branches or pull requests

4 participants