You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure this is a bug. Ultimately whether it's passed as a number or a string, any numeric value will end up as a string in our internal JSON pointer representation. Given this, the only way we know whether it was intended to be an array index or object member name is because the object/array being accessed already exists, or by inferring it based on the key.
So in the first example where "data", "we_use_strings" is passed before "data", "1234", it can only be an object property so we create an object. When "1234" is used to access this object, we therefore treat it as an object key.
In the other example "data", "1234" is the first thing passed, so the code assumes that it is an array index rather than an object name. Without reworking the code to track throughout whether a value was initially provided as a number or a string we have to make that assumption, or else the user would be forced to always add "data" as an array explicitly before accessing its indices.
To avoid the code making that assumption "data" could be initialized as an object before accessing "1234". Absent a larger change that moves further away from a JSON pointer-like implementation, this is the less surprising of the two options in my opinion.
Bug
The dojo store treats strings like "1234" as numbers and uses it as index for an array
Package Version: 6.0.3
Code
Expected behavior:
data should not be Array
Actual behavior:
data is an array with 1234
undefined
EntriesExample is here:
https://github.com/nikkabi/store-example
The text was updated successfully, but these errors were encountered: