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

Extent filtered by other axis #12832

Merged
merged 3 commits into from
Jun 20, 2020
Merged

Extent filtered by other axis #12832

merged 3 commits into from
Jun 20, 2020

Conversation

100pah
Copy link
Member

@100pah 100pah commented Jun 19, 2020

Brief Information

This pull request is in the type of:

  • bug fixing
  • new feature
  • others

What does this PR do?

fix: some refactor about dataZoom and axis scale extent calculation:

  • The "scale extent calculation" is depended by both coord sys and "dataZoom".
    So it need to be performed in different stage of workflow and should avoid to call it repleatly or implement it repeatly.
    But previously, the "scale extent calculation" is implemented both in axisHelper.ts and dataZoom/AxisProxy.ts,
    where different code implements similar logic.
    "Scale extent calculation" is based on input of:
    (I) option specified min/max/scale (including callback) and
    (II) dataExtent and
    (III) some filter related components like dataZoom.
    Currently we need add more filters depends on that axis scale calculation.
    e.g.,
    (I) one axis min max effect the other axis extent
    (II) custom filter.
    So we refactor that "Scale extent calculation" as a reusable module (see scaleRawExtentInfo.ts).

  • Based on (1), make the callback of axis.min/axis.max consistent whatever it is called in
    "data processing stage" or "coord sys updating stage"

  • Based on (1), fix some "inconsistent" flaw in dataZoom when handling stacked series.

  • Fix the type of axis.min/max to ScaleDataValue. And enable the callback of axis.min/max to return ScaleDataValue.

  • Remove some code that never used.

  • Make the "data filter", which will "block stream", not as the default data processor in the register API.

feature: Enable category axis min/max to shrink the other axis extent in cartesian.

After this modification, if some data if out of the range of a category axis,
the data item will not be filtered, but the extent of the other axis will be calculated
based on the filtered data.
If dataZoom is used in either of the xAxis or yAxis in that cartesian, the shrink will not be performed.

(1) The "scale extent calculation" is depended by both coord sys and "dataZoom".
So it need to be performed in different stage of workflow and should avoid to call it repleatly or implement it repeatly.
But previously, the "scale extent calculation" is implemented both in `axisHelper.ts` and `dataZoom/AxisProxy.ts`,
where different code implements similar logic.
"Scale extent calculation" is based on input of:
    (I) option specified min/max/scale (including callback) and
    (II) dataExtent and
    (III) some filter related components like dataZoom.
Currently we need add more filters depends on that axis scale calculation.
e.g.,
    (I) one axis min max effect the other axis extent
    (II) custom filter.
So we refactor that "Scale extent calculation" as a reusable module (see `scaleRawExtentInfo.ts`).

(2) Based on (1), make the callback of axis.min/axis.max consistent whatever it is called in
"data processing stage" or "coord sys updating stage"

(3) Based on (1), fix some "inconsistent" flaw in dataZoom when handling stacked series.

(4) Fix the type of axis.min/max to `ScaleDataValue`. And enable the callback of axis.min/max to return `ScaleDataValue`.

(5) Remove some code that never used.

(6) Make the "data filter", which will "block stream", not as the default data processor in the register API.
… in cartesian.

After this modification, if some data if out of the range of a category axis,
the data item will not be filtered, but the extent of the other axis will be calculated
based on the filtered data.
If dataZoom is used in either of the xAxis or yAxis in that cartesian, the shrink will not be performed.
@echarts-bot
Copy link

echarts-bot bot commented Jun 19, 2020

Thanks for your contribution!
The community will review it ASAP. In the meanwhile, please checkout the coding standard and Wiki about How to make a pull request.

The pull request is marked to be PR: author is committer because you are a committer of this project.

@@ -1,6 +1,6 @@
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* or more contributor license agreements. See theICE file
* distributed with this work for additional information
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to be an unexpected modification. Also has the same issue in the newly added files

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

Successfully merging this pull request may close these issues.

None yet

2 participants