apache/echarts · error

Data view format error {}

Error message

Data view format error {}

What it means

Runtime (NOT dev-only) error in the toolbox DataView feature: when an end user edits data in the DataView textarea and clicks save, the text is parsed back into an option (via parseContents or a custom contentToOption). If parsing throws, the original error is wrapped and re-thrown as 'Data view format error'. Fires in production.

Source

Thrown at src/component/toolbox/feature/DataView.ts:420

                    // eslint-disable-next-line
                    warn('It seems you have just provided one of `contentToOption` and `optionToContent` functions but missed the other one. Data change is ignored.')
                }
                close();
                return;
            }

            let newOption;
            try {
                if (zrUtil.isFunction(contentToOption)) {
                    newOption = contentToOption(viewMain, api.getOption());
                }
                else {
                    newOption = parseContents(textarea.value, blockMetaList);
                }
            }
            catch (e) {
                close();
                throw new Error('Data view format error ' + e);
            }
            if (newOption) {
                api.dispatchAction({
                    type: 'changeDataView',
                    newOption: newOption
                });
            }

            close();
        });

        closeButton.innerHTML = lang[1];
        refreshButton.innerHTML = lang[2];
        refreshButton.style.cssText =
        closeButton.style.cssText = buttonStyle;

        !model.get('readOnly') && buttonContainer.appendChild(refreshButton);
        buttonContainer.appendChild(closeButton);

View on GitHub (pinned to 30076aedcd)

Solutions

  1. Correct the textarea content to the format expected by parseContents (rows of name + tab + value, or valid option structure)
  2. Provide a robust contentToOption function that sanitizes input
  3. Document the expected data format for end users

Example fix

// before: user pastes malformed rows in the DataView textarea

// after: provide a lenient custom parser
toolbox: { feature: { dataView: {
  contentToOption: (view, opt) => safeParse(view.querySelector('textarea').value)
} } }
Defensive patterns

Strategy: try-catch

Validate before calling

// provide a robust custom contentToOption so end-user input cannot throw
toolbox: { feature: { dataView: {
  contentToOption: (view, opt) => {
    try { return safeParse(view.querySelector('textarea').value); }
    catch { return null; }
  }
} } }

Try / catch

try {
  chart.setOption(optionWith DataView);
} catch (e) {
  if (/Data view format/.test((e as Error).message)) {
    alert('Please fix the data format in the DataView editor');
  } else {
    throw e;
  }
}

Prevention

When it happens

Trigger: End user types malformed text into the DataView textarea (invalid array/row syntax) and triggers the save/refresh action; a custom contentToOption throws.

Common situations: Manual data editing in the data view tool; pasting broken/tab-misaligned data; a custom contentToOption returning invalid output.

Related errors


AI-assisted analysis of apache/echarts@30076aedcd (2026-08-12). Data as JSON: /api/errors/763b6508832176b2. Report an issue: GitHub.