Version
@visactor/taro-vchart on develop at 0750d74cd6ea734e66897876506c78ca12680676
Link to Minimal Reproduction
The update guards in both of these components reproduce the comparison behavior directly:
packages/taro-vchart/src/components/general-chart/index.tsx
packages/taro-vchart/src/components/web-chart/index.tsx
For example, JSON.stringify({ formatter: () => 'old' }) and JSON.stringify({ formatter: () => 'new' }) are both {}. A cyclic object throws from JSON.stringify.
Steps to Reproduce
- Render a Taro VChart with a spec containing a formatter or another supported callback.
- Update the component with a new callback while leaving the serializable fields unchanged.
- Alternatively, update with a spec containing a circular reference.
Current Behavior
Both componentDidUpdate implementations use JSON.stringify to decide whether the spec changed. Function-only changes compare equal, so updateSpec is not called. Circular specs throw during the lifecycle method instead of reaching VChart.
Expected Behavior
Spec updates should use a comparison strategy that supports VChart's valid function-valued options and does not throw on cyclic input.
Environment
- OS: Windows 11
- Node.js: 20.20.2 and 24.14.1
- Package:
@visactor/taro-vchart
Any additional comments?
The comparison has existed since the component's initial implementation, and this package currently has no unit tests covering update behavior. A fix should choose and test the intended function-diff and cyclic-object semantics rather than replacing the guard without measuring update cost.
Related: #4254 reports that serializable spec updates do not refresh under Taro 4.x. This report isolates two comparator behaviors that are present in the wrapper code independent of Taro version: function-only changes compare equal and cyclic input throws. #4254 has no linked PR or commit and does not mention either comparator case.
I searched all 4,627 open/closed issues and pull requests locally after fetching their current metadata, including Taro spec updates, JSON.stringify, function specs, circular specs, and general-chart; I also reviewed the file history and repository Discussions (none). Apart from the broader #4254 above, I did not find an existing report or fix for these two cases.
Version
@visactor/taro-vchartondevelopat0750d74cd6ea734e66897876506c78ca12680676Link to Minimal Reproduction
The update guards in both of these components reproduce the comparison behavior directly:
packages/taro-vchart/src/components/general-chart/index.tsxpackages/taro-vchart/src/components/web-chart/index.tsxFor example,
JSON.stringify({ formatter: () => 'old' })andJSON.stringify({ formatter: () => 'new' })are both{}. A cyclic object throws fromJSON.stringify.Steps to Reproduce
Current Behavior
Both
componentDidUpdateimplementations useJSON.stringifyto decide whether the spec changed. Function-only changes compare equal, soupdateSpecis not called. Circular specs throw during the lifecycle method instead of reaching VChart.Expected Behavior
Spec updates should use a comparison strategy that supports VChart's valid function-valued options and does not throw on cyclic input.
Environment
@visactor/taro-vchartAny additional comments?
The comparison has existed since the component's initial implementation, and this package currently has no unit tests covering update behavior. A fix should choose and test the intended function-diff and cyclic-object semantics rather than replacing the guard without measuring update cost.
Related: #4254 reports that serializable spec updates do not refresh under Taro 4.x. This report isolates two comparator behaviors that are present in the wrapper code independent of Taro version: function-only changes compare equal and cyclic input throws. #4254 has no linked PR or commit and does not mention either comparator case.
I searched all 4,627 open/closed issues and pull requests locally after fetching their current metadata, including Taro spec updates,
JSON.stringify, function specs, circular specs, andgeneral-chart; I also reviewed the file history and repository Discussions (none). Apart from the broader #4254 above, I did not find an existing report or fix for these two cases.