Partial does not solve React.setState

[AlexGalays]

Traditionally in TS, the absence of value or an explicit undefined value was exactly the same thing.
Perhaps it still even makes sense for Partial, but I thought Partial was meant to solve the React setState problem; and I believe it's still not solved today.

TypeScript Version: 2.1.4

Code

type State = { veryImportant: number }

// This compiles fine with all the mandatory flags (strictNullChecks, etc)
// if setState uses Partial<State>
// This is a huge invariant violation and can happen very easily for instance
// by setting `veryImportant` to a nullable variable.
this.setState({ veryImportant: undefined })

Expected behavior:
A non nullable property should not be updatable with null/undefined with strictNullChecks.

We need to be able to say "give me an object that

1. Either do not declare a property I have
2. Or if it does, must have the same exact type (not nullable)

By the way, I don't even use React, but this is a fairly common and useful behavior to have.

[ahejlsberg]

I believe this is what you're looking for:

function setState<T, K extends keyof T>(obj: T, state: Pick<T, K>) {
    for (let k in state) {
        obj[k] = state[k];
    }
}

interface Foo {
    a: string;
    b: number;
}

let foo: Foo = { a: "hello", b: 42 };
setState(foo, { a: "test", b: 43 })
setState(foo, { a: "hi" });
setState(foo, { b: 27 });
setState(foo, { });
setState(foo, { a: undefined });  // Error
setState(foo, { c: true });  // Error

[AlexGalays]

Looks good! Thanks.

PS: You don't happen to have something like that, but for a recursive structure do you? :)

[ericanderson]

@ahejlsberg Thanks for the post. However, the following situation then creates an issue:

interface FooState {
  bar: string;
  foo?: string;
}

const defaultFooState: FooState = {
  bar: "Hi",
  foo: undefined,
};

class Foo extends React.Component<{}, FooState> {
  public doStuff() {
    this.setState(defaultFooState);
  }
}

And updating setState as follows:

        setState<K extends keyof S>(f: (prevState: S, props: P) => Pick<S, K>, callback?: () => any): void;
        setState<K extends keyof S>(state: Pick<S, K>, callback?: () => any): void;

You get the error:

severity: 'Error'
message: 'Argument of type 'FooState' is not assignable to parameter of type 'Pick<FooState, "bar" | "foo">'.
  Property 'foo' is optional in type 'FooState' but required in type 'Pick<FooState, "bar" | "foo">'.'
at: '37,19'
source: 'ts'

Updating the state to explicitly allow the optional to be undefined also produces the same error.

interface FooState {
  bar: string;
  foo?: string | undefined;
}

[RyanCavanaugh]

@ericanderson question: in your opinion, should setState({ foo: undefined }) be an error, or not?

[ericanderson]

Ive been kicking it around in my head. If foo is allowed to be undefined (either because its optional or explicitly allowed), then that should not be an error for setState(), ignoring how TS is implemented.

If you implement setState with Partial, it works as intended for this case but breaks because it allows you to set undefined where its not allowed.

[masonk]

interface TState = {  foo?: string; }
let state: TState = { foo: "initial" };

Now I want state to become { foo: undefined }, how am I to do that if I can't call setState({ foo: undefined })?

I prefer the Partial to the Pick in this case. Partial allows some invalid behavior, but Pick prohibits some valid expressions.

If index types had the concept of optionality, then keyof FooState would return "foo?" | "bar", and Pick would become a perfect expression of the actual type of setState.

(Then I think for full completeness, if indexed types gain the concept of optionality they should also gain the concept of requiredness, so that we could undo optionality.

type Required<T> = {
    [K in keyof T]!: T[K]
})

[ericanderson]

@masonk if you define your state as type TState = { foo: string | undefined } you can still use it as you wish with Pick.

But if we use Partial and you have type State = { foo: string }, then it will not be an error to have setState({foo: undefined}).

[ericanderson]

@RyanCavanaugh If there is a bug here, I would suggest that any parameter who is an optional is also an implicit "T | undefined" so that when you convert it in something like Pick, the ability to assign undefined does not get lost.

[masonk]

Sure, but the idiomatic way to say { foo: string | undefined } is { foo?: string }. As I understand TypeScript, those two declarations ought to behave identically throughout TypeScript.

[ericanderson]

@masonk Correct. I think we could say that there is currently a bug in TypeScript that the undefined get lost in the case of Pick

[ericanderson]

@masonk Also do note that they arent always assignable.

type A = { foo?: string };
type B = { foo: string | undefined};

let a: A = { foo: "bar" }
let b: B = { foo: "bar" }

a = b; // okay
b = a; // not okay

Update: the definition of B implies that there is always a param called foo available, think Object.keys(b). A does not make that guarantee.