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

Mapping over same objects and overwriting values #6942

Closed
HenriBeck opened this issue Sep 27, 2018 · 5 comments
Closed

Mapping over same objects and overwriting values #6942

HenriBeck opened this issue Sep 27, 2018 · 5 comments

Comments

@HenriBeck
Copy link

HenriBeck commented Sep 27, 2018

When mapping over the same objects, flow doesn't allow to overwrite the values of the objects even though they are the same.
I'm assuming that flow checks merely all of the values of an object and checks if there is only one type as the value and if it's the same.

I guess this is a particular case. I think flow should only compare the types of the same keys and the structure of the object.

type Test = {
	key1: boolean,
	key2: string,
	key4: number,
	key6: Array<{}>,
};

function merge(obj1: Test, obj2: Test) {
	const keys = Object.keys(obj2);

	for (const key of keys) {
		obj1[key] = obj2[key];
	}

	return obj1;
}

Try Flow

@lll000111
Copy link
Contributor

lll000111 commented Sep 30, 2018

What I find strange is that Object.keys' return value is defined as Array<string>, but when I change the assignment in your example to...

const keys: Array<string> = Object.keys(obj2);

..., i.e. just adding a type that is already there according to how the type of Object.keys() is declared, the errors disappear.

Does Flow have some invisible hard-coded logic for Object.keys?

@goodmind
Copy link
Contributor

It has, for reference #6927

@lll000111
Copy link
Contributor

lll000111 commented May 31, 2019

@goodmind Could it be declared using a generic (object) type of the keys of the object? There are similar discussions and issues in TypeScript, and TS's ahejlsberg wrote that's not possible (but I don't buy the argument he gives, his example just looks to me like somebody used the wrong type and not a fundamental issue).

@goodmind
Copy link
Contributor

I think it should work like this, but without two generics

@SamChou19815
Copy link
Contributor

This pattern will not be supported as it's too dynamic

@SamChou19815 SamChou19815 closed this as not planned Won't fix, can't repro, duplicate, stale Aug 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants