LWC autoconverting decimal into string. SF Bug?

Question

I am trying to send key-value pair Map from Apex to JS.

But I can see aura auto converting the decimal to string.

Minimum Viable Code to reproduce:

Apex:

public with sharing class AuraPOC {

    @AuraEnabled(Cacheable=true)
    public static Map<String, Object> getValue(){
        return new Map<String,Object>{ 'key'=>3530.7666666666664};
    }
}

LWC JS:

import { LightningElement,api,wire,track } from 'lwc';
import getLatestValues from '@salesforce/apex/AuraPOC.getValue';

    export default class LwcCmp extends LightningElement {
            @wire(getLatestValues)
                     callBack({ data, error }) {
                         if(data){
                            console.log(data);
                         }
                    };
    
    }

Debug:

Answer 1

I initially assumed, given that you're sending back a Map<String, Object>, the parser is not intelligent enough to try to map an Object to the appropriate type. Couple that with not all Apex primitives being given a representation in JSON (Dates and DateTimes for example are ISO timestamps as strings) and you're going to run into some limitations quickly.

I wasn't sure of how the parser would handle these "generic" Object types so I recreated your code. You can see how types are parsed with a simple experiment:

public with sharing class AuraPOC {

    @AuraEnabled(Cacheable=true)
    public static Map<String, Object> getValue(){
        return new Map<String,Object>{ 
            'decimal' => 3530.7666666666664,
            'integer' => 350,
            'string' => 'something',
            'bool' => false,
            'date' => Date.newInstance(2020, 11, 24),
            'datetime' => DateTime.newInstance(2020, 11, 24, 15, 55, 12)
        };
    }
}

import { LightningElement,api,wire,track } from 'lwc';
import getLatestValues from '@salesforce/apex/AuraPOC.getValue';

export default class dataConvert extends LightningElement {

    @wire(getLatestValues)
    callBack({ data, error }) {
        if(data){
            console.log(data);
        }
    };

}

You will get:

{
    bool: false
    date: "2020-11-24"
    datetime: "2020-11-24T20:55:12.000Z"
    decimal: "3530.7666666666664"
    integer: 350
    string: "something"
}

Which shows me that the parser is smart enough to convert the primitives appropriately, but it's being cautious about floating point numbers. It is a good practice to use strings to represent decimal/double values so as not to lose any accuracy or precision that might happen when passing the JSON through middleware because the JSON standard doesn't define rules about precision and encoding. I can imagine a scenario where a client's browser represents a decimal in a different way when its parsed into a decimal.

I would conclude that sending it as a string is a feature and not a bug.