Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@dojo/framework/stores/Store should not treat strings like "123" as numbers #645

Open
sputnyq opened this issue Jan 14, 2020 · 1 comment
Assignees
Labels
area: stores Stores bug Something isn't working

Comments

@sputnyq
Copy link

sputnyq commented Jan 14, 2020

Bug

The dojo store treats strings like "1234" as numbers and uses it as index for an array

Package Version: 6.0.3

Code

// inside of command
add(path("data", "1234", "foo", "baz"), "A")

interface State {
    data: IndexedData
}


interface IndexedData {
    [id: string]: Data
}

Expected behavior:

data should not be Array

Actual behavior:

data is an array with 1234 undefined Entries

Example is here:
https://github.com/nikkabi/store-example

@matt-gadd matt-gadd added bug Something isn't working area: stores Stores labels Jan 29, 2020
@maier49 maier49 self-assigned this Feb 3, 2020
@maier49
Copy link
Contributor

maier49 commented Feb 3, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: stores Stores bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants