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 https://github.com/facebook/flow/issues/380#issuecomment-224380551 works well
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');
}
}
});
Number literals are annoying, since we need to canonicalize them. We should probably just bite the bullet and implement the algorithm. CC @mroch
Any update on this issue?
:+1: Is there any progress with this issue? I really need this one :)
As a really awful hack:
var x = {
[1234]:"a",
[5678]:"b"
}
ugh. I too need this.
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.
Any progress?
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
Any plans to fix this? This should't throw an error
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]);
We've internally decided to move away from flow. @jgrund 's array hack works well
@Niggler, please, reopen the ticket. There're plenty of people who still interested in this. Let maintainers see the interest.
@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
@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' }
@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.
this would be fantastic if it was supported.
Still not supported?
@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"
}
If there is a fundamental issue in the flow that prevents this?
Hey why isn't this addressed yet?
this isn't as trivial as it seems, as @gabelevi and @szdavid92 point out above. to support numeric keys, we need to implement ecmascript's NumberToString, which is highly complicated: https://tc39.github.io/ecma262/#sec-tostring-applied-to-the-number-type
I published ocaml-dtoa a while back which we can use for this, so I'd say the major blocker to supporting numbers is fixed (and we don't intend to support other objects as keys).
I'm writing a flow type definition for the mui-org/material-ui and I am hitting this issue as well.
@wcandillon is this open source?
@jgcmarins Thank you so much for asking 🙌🏻
I've put the current state in the following repository: https://github.com/wcandillon/material-ui-flow
I could really use some help as I'm not sure how to translate of the utility types from TypeScript to Flow
cc: @mastertinner @nathantalewis @bugzpodder
Use a Map
@hcatlin this is shorter notation:
{ 0: 'aaa', 1: 'bbb' }
than this:
new Map([[0, 'aaaa'], [1, 'bbbb']])
so IMHO it should be supported
This has been open since 2015, this is a tad ridiculous - why is this still not supported?
I opened PR for this #7593 using library ocaml-dtoa that @mroch suggested
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 }],
I've upgraded prettier which prompted me to drop the quotes const X = { 2: "1" }, but flow is complaining. any advice?
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
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]: {
It's kind of ridiculous that this issue is still present in 2021...
Most helpful comment
@Niggler, please, reopen the ticket. There're plenty of people who still interested in this. Let maintainers see the interest.