"non-string literal property keys not supported"

[redchair123]

var x = {
    1234:"a",
    5678:"b"
}

Flow generates an error per integer key.

According to 11.1.5 of ECMA-262 this is a perfectly valid construct.

EDIT: @jgrund 's solution in #380 (comment) works well

[fatboysuns]

I get the same error when I when I run it on a jquery javascript.
$.ajax({
url: url,
dataType: 'html',
success: function(data) {
//do something
},
error: function(data) {
// something else
},
// This is the line Flow complains
statusCode: {
404: function() {
alert('404');
}
}
});

[gabelevi]

Number literals are annoying, since we need to canonicalize them. We should probably just bite the bullet and implement the algorithm. CC @mroch

[julianacipa]

Any update on this issue?

[Zaba999]

👍 Is there any progress with this issue? I really need this one :)

[jgrund]

As a really awful hack:

var x = {
    [1234]:"a",
    [5678]:"b"
}

[rosskevin]

ugh. I too need this.

[StreetStrider]

The issue still bothers. Tried to typecast to something like {[n: number]: mixed} — not working. Even if it did, it's such a crazy workaround for such a small thing.

[redchair123]

Any progress?

[punmechanic]

Playing devils advocate here: All keys on an object will be implicitly converted to a string. I like that this error is explicit about that behaviour (even if the error is not very well defined).

EDIT: 2016 me was an idiot and incorrect. This behaviour is surprising and unintuitive

[lenovouser]

Any plans to fix this? This should't throw an error

[arhtudormorar]

This is working for me:

type PropsType = {
	[key: string]: string
}

let currencyId = 1,
    currencyCode = "RON";

let currencies: PropsType = {
	[currencyId.toString()]: currencyCode
}

console.log(currencies[1]);

[redchair123]

We've internally decided to move away from flow. @jgrund 's array hack works well

[StreetStrider]

@Niggler, please, reopen the ticket. There're plenty of people who still interested in this. Let maintainers see the interest.

[redchair123]

@StreetStrider it's nearly 2 years since this issue was first raised. Contributor first commented 22 months ago, so there's definitely nonzero awareness of the issue. But at this point, you're better off switching to another typed JS alternative

[dszakallas]

@Niggler if this were valid:

type Obj = {
  '0': number,
  56e-13214125: string
};

would you expect

const x: Obj = { '0': 0, 56e-13214125: 'hello' };
(x['0']: number);

to pass or fail?

Note, that

> { '0': 0, 56e-13214125: 'hello' }
{ '0': 'hello' }

[ndbroadbent]

@szdavid92 I would expect Flow to just understand that all object keys are strings.

a = {
  56e-13214125: 'abc'
}
// => Object {0: "abc"}

a[0]
// => "abc"

a['0']
// => "abc"

That seems pretty straightforward to me. Flow should just understand that { 0: 'abc' } is an object with a type of { string: string }. If you need integers as keys, then you have to use a Map (or an array).

I can see how this might trip up some people who are new to JS, but I think there should be an option to disable this warning when you are familiar with JS objects.

For now, I've disabled my quote-props rule in eslint, but I would love to turn that back on and disable the warning in Flow.

[itsdouges]

this would be fantastic if it was supported.

[bradennapier]

Still not supported?

[redchair123]

@szdavid92 @ndbroadbent your points are well taken, but it's clear this issue isn't a priority for flow devs. In that situation it's better to either move away from flow or find a workaround. The array trick works, and combined with the comment form you can do the trick without affecting the resulting JS code:

var x = {
    /*::[*/ 1234 /*::]*/:"a",
    /*::[*/ 5678 /*::]*/:"b"
}

[chyzwar]

If there is a fundamental issue in the flow that prevents this?

[goodmind]

I opened PR for this #7593 using library ocaml-dtoa that @mroch suggested

[Brianzchen]

Still not supported as of v0.122.0. I'm just getting into flow and I'm enjoying the soundness but random issues like these that haven't been resolved or been given work around recommendations by flow maintainers makes it rather annoying.

Edit: If using numbers as keys are considered non-sound then it seems fine to leave the issue there and instead encourage string only values as keys which falls under a similar boat as another issues I previously had which I solved with converting it to an explicit string with string literals.

{
 [`${verticalPos === pos ? 'top' : 'bottom'}`]: ...
}

As for simple numbers, I opted for simply using them as strings

'123': 123,

This caused me an eslint error which I solved with this, which still keeps the rules enabled for regular cases.

'quote-props': ['error', 'as-needed', { keywords: false, unnecessary: true, numbers: true }],

[dominikabieder]

I've upgraded prettier which prompted me to drop the quotes const X = { 2: "1" }, but flow is complaining. any advice?

[Brianzchen]

I've upgraded prettier which prompted me to drop the quotes const X = { 2: "1" }, but flow is complaining. any advice?

Given that prettier doesn't have an option to configure this, probably the easiest solution to to write your obj as the following to retain the key as a string value.

const X = { ['2']: '1' }

I'd actually consider taking this up with the prettier team, since on their homepage they apparently support Flow

[nemoDreamer]

Making it a Map does seem like the more modern approach. Worked nicely for me because I had fixed integer keys and nothing else:

@@ -20,24 +25,24 @@ describe("utils", () => {
     describe("resolveDiceRoll", () => {
       const specs = {
         [PLAYER_0]: {
-          near: {
-            1: 4,
-            6: 9,
-          },
-          far: {
-            1: 0,
-            6: 5,
-          },
+          near: new Map([
+            [1, 4],
+            [6, 9],
+          ]),
+          far: new Map([
+            [1, 0],
+            [6, 5],
+          ]),
         },
         [PLAYER_1]: {

[jamesqo]

It's kind of ridiculous that this issue is still present in 2021...

[ayroblu]

Hey, I encountered this and tried it out:

> var a = { 1: 'hi'}
undefined
> a['1']
'hi'
> a[1]
'hi'
> var a = { 1: 'hi', '1': 'bye' }
undefined
> a
{ '1': 'bye' }

I think flow's decision here is correct? Perhaps inconvenient, but knowing the above I wouldn't use number types