fix(custom): resolve api.value() NaN issue for key-value data format

[Srajan-Sanjay-Saxena]

• Fixed CustomView.ts value() function to handle key-value data [{x:100, y:200}]
• Enhanced fallback mechanism: store access → raw data access when dimension mapping fails
• Maintains backward compatibility with array format [[100, 200]]
• Supports both string ('x') and numeric (0) dimension access for key-value data
• Added comprehensive test coverage for 10 edge cases and data formats

Resolves critical issue where api.value() returned NaN for object-based data while array-based data worked correctly in custom series renderItem function.

Brief Information

This pull request is in the type of:

• bug fixing
• new feature
• others

What does this PR do?

Fixes api.value() function in custom series to properly handle key-value data format [{x:100, y:200}] by adding fallback to raw data access when internal store access fails.

Fixed issues

Critical bug where custom series api.value() returned NaN for key-value object data format while array format worked correctly.

Details

Before: What was the problem?

Root Cause: The value function in src/chart/custom/CustomView.ts (lines 755-783) only attempted to access ECharts' internal data store via data.getItemModel(dataIndex).get(dim). For key-value data format [{x: 100, y: 200}], the dimension mapping failed in the store, causing api.value('x') and api.value(0) to return NaN.

Technical Issue:

• ECharts uses dual storage: raw data (user input) + data store (optimized internal format)
• Key-value objects {x: 100, y: 200} weren't properly mapped to store dimensions
• Only store access was attempted, no fallback to raw data
• Array format [[100, 200]] worked because store mapping succeeded

Impact:

• api.value('x') returned NaN instead of 100
• api.value(0) returned NaN instead of 100
• Custom series renderItem functions failed for key-value data
• Forced users to use less intuitive array format

After: How does it behave after the fixing?

Solution: Enhanced the value function with intelligent fallback mechanism:

1. Primary: Try optimized store access data.getItemModel(dataIndex).get(dim)
2. Fallback: If store returns invalid result, access raw data directly
3. String Access: api.value('x') → searches raw object keys
4. Numeric Access: api.value(0) → maps to dimension order for objects
5. **The result of the testing html file that i created

Technical Implementation:

// Before (lines 755-783)
value(dim: DimensionLoose): ParsedValue {
    return data.getItemModel(dataIndex).get(dim, true);
}

// After (enhanced with fallback)
value(dim: DimensionLoose): ParsedValue {
    const storeValue = data.getItemModel(dataIndex).get(dim, true);
    if (storeValue != null && !isNaN(storeValue as number)) {
        return storeValue;
    }
    
    // Fallback to raw data access for key-value format
    const rawItem = data.getRawDataItem(dataIndex);
    if (rawItem && typeof rawItem === 'object' && !Array.isArray(rawItem)) {
        if (typeof dim === 'string') {
            return rawItem[dim];
        } else if (typeof dim === 'number') {
            const dimensions = data.getDimensionsOnCoord();
            const dimName = dimensions[dim];
            return dimName ? rawItem[dimName] : undefined;
        }
    }
    return storeValue;
}

[echarts-bot]

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.

To reviewers: If this PR is going to be described in the changelog in the future release, please make sure this PR has one of the following labels: PR: doc ready, PR: awaiting doc, PR: doc unchanged

This message is shown because the PR description doesn't contain the document related template.