Exact fails when doing es6 object spread

[MarcoPolo]

This fails:

// @flow

type A = {|
  foo: number
|}

const foo: A = {foo: 3}
const bar: A = {...foo}

With error:

demo.js:8
  8: const bar: A = {...foo}
                    ^^^^^^^^ object literal. Inexact type is incompatible with exact type
  8: const bar: A = {...foo}
                ^ exact type: object type

This pattern is pretty common in redux style reducers where you return the old state merged with new values (e.g.{...foo, foo: 4})

[samwgoldman]

Yeah, I think your expected behavior is reasonable here. There are quite a few issues surrounding object spread (which is why it has its own issues tag), so we should probably take another look at the entire spread implementation with this and other issues in mind.

Thanks for the report with simple repro code!

[pbomb]

@samwgoldman I'm curious if I should expect any activity on this issue and what a good workaround in the meantime might be.

[jfmengels]

I discovered the same problem and noticed the same error applies when using Object.assign

type Foo = {
  a: string,
  b: string
};

const baseFoo: Foo = {
  a: 'a',
  b: 'b'
};

const extendedFoo: Foo = Object.assign(
  {},
  baseFoo,
  { a: 'c' }
);

[dchambers]

@samwgoldman I'm curious if I should expect any activity on this issue and what a good workaround in the meantime might be.

@pbomb, the work around I'm using is to not start making use of exact types until spread support improves. I rely heavily on object rest/spread so I can write pure functional JavaScript.

OTOH, exact types seem like more of a nice to have feature. For example, there's a good chance my app will work after doing a large refactor once Flow's happy, but the tests may still fail if I have some extra properties left round that would cause any deep object comparisons to fail. It would be great if Flow caught that stuff too, but it's not the end of the world if it doesn't.

At least that's how it's working out for me anyway...

[guicar]

@pbomb A workaround we use:

type Foo_ = {
  a: string,
  b: string
};

type Foo = Foo_ & $Shape<Foo_>;

The type $Shape<Foo_> represents the objects which have a subset of the keys {a, b}. An object of type Foo cannot contain other fields than a and b, and the spread mechanism (seems to) works.

[dralletje]

@guicar 's solution works perfect for me!
I now use type Exact<T> = T & $Shape<T>; everywhere and it works :o

[i-manolov]

is there currently any activity on resolving this issue?

[steida]

As for custom Exact type, it breaks autocomplete in Atom. Just saying.

[ferrannp]

This is quite a missing key feature when using Redux where you probably use spread operator everywhere in your reducers. If you define an exact state type, flow will report errors when using the spread operator (Inexact type is incompatible with exact type). If you do not define exact type for your state, then you're app state is not safe anymore. Example:

type TAppState = {|
  auth: TLoginState;
  ...
|}

type TLoginState = {|
  isLoading: string;
  token: string;
|}

...
// Login reducer:

...
return { ...state, isLoading: true }
// Flow error: object literal. Inexact type is incompatible with exact type

[dsimmons]

Just echoing @ferrannp. Ran into this in the same exact context (Redux reducers).

Specifically, I have a function (reducer) that accepts a param of an exact object type (let's call it SomeType). SomeType has two attributes, each of type AnotherType. I've annotated the function to return SomeType.

I'm attempting to do something like the following:

const (anotherType: AnotherType) = { k: v };

// Copy a `SomeType` with one of the two `AnotherType` fields changed.
return ({
  ...(someType: SomeType),
  attrTwo: anotherType,
}: SomeType)