You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@echarts.apache.org by SHUANG SU <su...@gmail.com> on 2019/09/18 18:24:49 UTC
[DISCUSS] How to trade the prop that needed to be calcluated and set back?
Currently, I gradually think we have to make some change
about the practice that we have been trading the props
that needed to be normalized or calculated inside.
The way that I've been using is not a good practice:
Set the calculated value to the original prop directly
and erase the original value.
Use some pseudocode to describe it clearly:
Suppose `clac` is the function that normalizes/calculates the
original value specified and get the result.
When `chart.setOption` or `chart.dispatchAction`, we need to:
`option[propForAssigning] = specifiedValue;`
When `chart.setOption` or `chart.dispatchAction` or go though the main
process, we need to:
`option[propForCalculating] = calc( option[propForAssigning] );`
If we make `propForCalculating === propForAssigning`,
and `calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
we will lose the original value but get result not expected.
There is one example we meet just now:
`dataZoom` has props `start` `end` `startValue` `endValue`,
These four props can be set by user (via `chart.setOption` or
`chart.dispatchAction`)
or by components (via `api.dispatchAction`).
But the specified value needs to be calculated and get the final value,
which is usually not the same as the original specified value, but in
most cases, not different so much.
(The calculation depends on the data extent, `dataZoom.minSpan`,
`dataZoom.maxSpan`
and some other factors)
Users need to read the final value, so I write the final value to
these props, erasing the original value.
But some bad case occurs:
If the user uses `toolbox.dataZoom` to zoom Y-axis, and then click
the `legend`, and then click the `legend` again, the chart can not
return to the original state.
The reason is:
The original value of `dataZoom.startValue` and `dataZoom.endValue`
is erased by the value that calculated in the main process triggered
by clicking legend.
There were some other similar cases.
CSS distinguish the "style" and "computed style".
We probably also need to settle a best practice for that.
For example:
If a calculated prop need to be set to `option` and the
normalizer/calculater
(say, `calc`) do not meet the condition:
`calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
we should not use the original prop, but use a new prop, like:
`dataZoom.calculatedStartValue`, `dataZoom.calculatedEndValue`...
(An example that meets the condition:
canvas.font = 'xxx';
)
But that would be a little break change...
Any idea about all the issue and possible solution above?
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
Re: [DISCUSS] How to trade the prop that needed to be calcluated and
set back?
Posted by SHUANG SU <su...@gmail.com>.
OK, fixed it with the compat way:
[image: WechatIMG1.jpeg]
in
https://github.com/apache/incubator-echarts/pull/11303/commits/d80dc0b9ed1642232c03486c42b397ac0ca8e81e
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
On Thu, 19 Sep 2019 at 04:14, SHUANG SU <su...@gmail.com> wrote:
>
> Another solution for this issue is caching the raw assigned values,
> since we have only certain several entries that option can be changed
> (chart.setOption and chart.dispatchAction)
>
> This solution will not result in break change, because it is what we have
> been using all the time,
> especially in the props of `left`, `top`, `right`, `bottom`, `width`,
> `height` of each component.
>
> Suppose we name this approach "EraseOrigin", and the solution that making
> `calculatedProp` is "SetCalculatedProp".
> In contrast, "EraseOrigin" might not be totally correct in logic, and
> bring some messy job in implementation,
> but easy to understand for rookie users, and no break change,
> and "SetCalculatedProp" would be on the contrary.
>
>
> Thanks,
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> On Thu, 19 Sep 2019 at 02:35, SHUANG SU <su...@gmail.com> wrote:
>
>> About the `dataZoom` issue, check the code:
>>
>>
>> https://github.com/apache/incubator-echarts/blob/master/src/component/dataZoom/AxisProxy.js#L253
>>
>>
>> > canvas.font = 'xxx';
>> Typo. should be:
>> canvasCtx.font = 'xxx';
>>
>>
>> Thanks,
>> ------------------------------
>> Su Shuang (100pah)
>> ------------------------------
>>
>>
>>
>> On Thu, 19 Sep 2019 at 02:24, SHUANG SU <su...@gmail.com> wrote:
>>
>>>
>>> Currently, I gradually think we have to make some change
>>> about the practice that we have been trading the props
>>> that needed to be normalized or calculated inside.
>>> The way that I've been using is not a good practice:
>>>
>>> Set the calculated value to the original prop directly
>>> and erase the original value.
>>>
>>> Use some pseudocode to describe it clearly:
>>>
>>> Suppose `clac` is the function that normalizes/calculates the
>>> original value specified and get the result.
>>>
>>> When `chart.setOption` or `chart.dispatchAction`, we need to:
>>> `option[propForAssigning] = specifiedValue;`
>>>
>>> When `chart.setOption` or `chart.dispatchAction` or go though the main
>>> process, we need to:
>>> `option[propForCalculating] = calc( option[propForAssigning] );`
>>>
>>> If we make `propForCalculating === propForAssigning`,
>>> and `calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
>>>
>>> we will lose the original value but get result not expected.
>>>
>>>
>>> There is one example we meet just now:
>>>
>>> `dataZoom` has props `start` `end` `startValue` `endValue`,
>>> These four props can be set by user (via `chart.setOption` or
>>> `chart.dispatchAction`)
>>> or by components (via `api.dispatchAction`).
>>>
>>> But the specified value needs to be calculated and get the final value,
>>> which is usually not the same as the original specified value, but in
>>> most cases, not different so much.
>>> (The calculation depends on the data extent, `dataZoom.minSpan`,
>>> `dataZoom.maxSpan`
>>> and some other factors)
>>> Users need to read the final value, so I write the final value to
>>> these props, erasing the original value.
>>>
>>> But some bad case occurs:
>>> If the user uses `toolbox.dataZoom` to zoom Y-axis, and then click
>>> the `legend`, and then click the `legend` again, the chart can not
>>> return to the original state.
>>> The reason is:
>>> The original value of `dataZoom.startValue` and `dataZoom.endValue`
>>> is erased by the value that calculated in the main process triggered
>>> by clicking legend.
>>>
>>> There were some other similar cases.
>>> CSS distinguish the "style" and "computed style".
>>> We probably also need to settle a best practice for that.
>>>
>>> For example:
>>> If a calculated prop need to be set to `option` and the
>>> normalizer/calculater
>>> (say, `calc`) do not meet the condition:
>>>
>>> `calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
>>>
>>> we should not use the original prop, but use a new prop, like:
>>>
>>> `dataZoom.calculatedStartValue`, `dataZoom.calculatedEndValue`...
>>>
>>> (An example that meets the condition:
>>> canvas.font = 'xxx';
>>> )
>>>
>>> But that would be a little break change...
>>>
>>> Any idea about all the issue and possible solution above?
>>>
>>>
>>>
>>>
>>> Thanks,
>>> ------------------------------
>>> Su Shuang (100pah)
>>> ------------------------------
>>>
>>>
Re: [DISCUSS] How to trade the prop that needed to be calcluated and
set back?
Posted by SHUANG SU <su...@gmail.com>.
Another solution for this issue is caching the raw assigned values,
since we have only certain several entries that option can be changed
(chart.setOption and chart.dispatchAction)
This solution will not result in break change, because it is what we have
been using all the time,
especially in the props of `left`, `top`, `right`, `bottom`, `width`,
`height` of each component.
Suppose we name this approach "EraseOrigin", and the solution that making
`calculatedProp` is "SetCalculatedProp".
In contrast, "EraseOrigin" might not be totally correct in logic, and bring
some messy job in implementation,
but easy to understand for rookie users, and no break change,
and "SetCalculatedProp" would be on the contrary.
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
On Thu, 19 Sep 2019 at 02:35, SHUANG SU <su...@gmail.com> wrote:
> About the `dataZoom` issue, check the code:
>
>
> https://github.com/apache/incubator-echarts/blob/master/src/component/dataZoom/AxisProxy.js#L253
>
>
> > canvas.font = 'xxx';
> Typo. should be:
> canvasCtx.font = 'xxx';
>
>
> Thanks,
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> On Thu, 19 Sep 2019 at 02:24, SHUANG SU <su...@gmail.com> wrote:
>
>>
>> Currently, I gradually think we have to make some change
>> about the practice that we have been trading the props
>> that needed to be normalized or calculated inside.
>> The way that I've been using is not a good practice:
>>
>> Set the calculated value to the original prop directly
>> and erase the original value.
>>
>> Use some pseudocode to describe it clearly:
>>
>> Suppose `clac` is the function that normalizes/calculates the
>> original value specified and get the result.
>>
>> When `chart.setOption` or `chart.dispatchAction`, we need to:
>> `option[propForAssigning] = specifiedValue;`
>>
>> When `chart.setOption` or `chart.dispatchAction` or go though the main
>> process, we need to:
>> `option[propForCalculating] = calc( option[propForAssigning] );`
>>
>> If we make `propForCalculating === propForAssigning`,
>> and `calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
>>
>> we will lose the original value but get result not expected.
>>
>>
>> There is one example we meet just now:
>>
>> `dataZoom` has props `start` `end` `startValue` `endValue`,
>> These four props can be set by user (via `chart.setOption` or
>> `chart.dispatchAction`)
>> or by components (via `api.dispatchAction`).
>>
>> But the specified value needs to be calculated and get the final value,
>> which is usually not the same as the original specified value, but in
>> most cases, not different so much.
>> (The calculation depends on the data extent, `dataZoom.minSpan`,
>> `dataZoom.maxSpan`
>> and some other factors)
>> Users need to read the final value, so I write the final value to
>> these props, erasing the original value.
>>
>> But some bad case occurs:
>> If the user uses `toolbox.dataZoom` to zoom Y-axis, and then click
>> the `legend`, and then click the `legend` again, the chart can not
>> return to the original state.
>> The reason is:
>> The original value of `dataZoom.startValue` and `dataZoom.endValue`
>> is erased by the value that calculated in the main process triggered
>> by clicking legend.
>>
>> There were some other similar cases.
>> CSS distinguish the "style" and "computed style".
>> We probably also need to settle a best practice for that.
>>
>> For example:
>> If a calculated prop need to be set to `option` and the
>> normalizer/calculater
>> (say, `calc`) do not meet the condition:
>>
>> `calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
>>
>> we should not use the original prop, but use a new prop, like:
>>
>> `dataZoom.calculatedStartValue`, `dataZoom.calculatedEndValue`...
>>
>> (An example that meets the condition:
>> canvas.font = 'xxx';
>> )
>>
>> But that would be a little break change...
>>
>> Any idea about all the issue and possible solution above?
>>
>>
>>
>>
>> Thanks,
>> ------------------------------
>> Su Shuang (100pah)
>> ------------------------------
>>
>>
Re: [DISCUSS] How to trade the prop that needed to be calcluated and
set back?
Posted by SHUANG SU <su...@gmail.com>.
About the `dataZoom` issue, check the code:
https://github.com/apache/incubator-echarts/blob/master/src/component/dataZoom/AxisProxy.js#L253
> canvas.font = 'xxx';
Typo. should be:
canvasCtx.font = 'xxx';
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
On Thu, 19 Sep 2019 at 02:24, SHUANG SU <su...@gmail.com> wrote:
>
> Currently, I gradually think we have to make some change
> about the practice that we have been trading the props
> that needed to be normalized or calculated inside.
> The way that I've been using is not a good practice:
>
> Set the calculated value to the original prop directly
> and erase the original value.
>
> Use some pseudocode to describe it clearly:
>
> Suppose `clac` is the function that normalizes/calculates the
> original value specified and get the result.
>
> When `chart.setOption` or `chart.dispatchAction`, we need to:
> `option[propForAssigning] = specifiedValue;`
>
> When `chart.setOption` or `chart.dispatchAction` or go though the main
> process, we need to:
> `option[propForCalculating] = calc( option[propForAssigning] );`
>
> If we make `propForCalculating === propForAssigning`,
> and `calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
>
> we will lose the original value but get result not expected.
>
>
> There is one example we meet just now:
>
> `dataZoom` has props `start` `end` `startValue` `endValue`,
> These four props can be set by user (via `chart.setOption` or
> `chart.dispatchAction`)
> or by components (via `api.dispatchAction`).
>
> But the specified value needs to be calculated and get the final value,
> which is usually not the same as the original specified value, but in
> most cases, not different so much.
> (The calculation depends on the data extent, `dataZoom.minSpan`,
> `dataZoom.maxSpan`
> and some other factors)
> Users need to read the final value, so I write the final value to
> these props, erasing the original value.
>
> But some bad case occurs:
> If the user uses `toolbox.dataZoom` to zoom Y-axis, and then click
> the `legend`, and then click the `legend` again, the chart can not
> return to the original state.
> The reason is:
> The original value of `dataZoom.startValue` and `dataZoom.endValue`
> is erased by the value that calculated in the main process triggered
> by clicking legend.
>
> There were some other similar cases.
> CSS distinguish the "style" and "computed style".
> We probably also need to settle a best practice for that.
>
> For example:
> If a calculated prop need to be set to `option` and the
> normalizer/calculater
> (say, `calc`) do not meet the condition:
>
> `calc( calc( propForAssigning ) ) !== calc( propForAssigning )`
>
> we should not use the original prop, but use a new prop, like:
>
> `dataZoom.calculatedStartValue`, `dataZoom.calculatedEndValue`...
>
> (An example that meets the condition:
> canvas.font = 'xxx';
> )
>
> But that would be a little break change...
>
> Any idea about all the issue and possible solution above?
>
>
>
>
> Thanks,
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>