More accurate typing of Object.assign and React component setState()

[rogierschouten]

This is a proposal for solving the second use case mentioned in Issue #6218

Problem

/**
 * This class is a given by the React framework
 */
class ReactComponent<S> {
    protected _state: S;

    /**
     * This method actually accepts any supertype of S
     */
    protected setState(newState: S): void {
        for (let name in newState) {
            if (newState.hasOwnProperty(name)) {
                this._state[name] = newState[name];
            }
        }
    }

    protected componentWillMount(): void {
        // abstract
    }
}

/**
 * Some state interface declaration. Note all members are optional to allow setState to
 * be called with supertypes of BaseState
 */
interface BaseState {
    a?: string;
}

/**
 * My own base class for certain React widgets
 */
class BaseWidget<S extends BaseState> extends ReactComponent<S> {

    constructor() { 
        super();
        this._state = {};
    }

    protected componentWillMount(): void {
        this.setState({ a: "boo" });
    }
} 

$ tsc v1.ts
v1.ts(39,9): error TS2322: Type '{}' is not assignable to type 'S'.
v1.ts(43,23): error TS2345: Argument of type '{ a: string; }' is not assignable to parameter of type 'S'.

The compiler cannot know that the setState() method will accept any super-type of S, i.e. an object with any subset of the members of S.

Proposal

Add a keyword to type setState() properly. To avoid confusion, I chose partof instead of e.g. 'supertype of' (see also initial confusion in #6218). For me, 'partof' conveys that I can give the method any object with a subset of the members of S.

/**
 * This class is a given by the React framework
 */
class ReactComponent<S extends {}> {
    protected _state: S;

    /**
     * This method accepts any supertype of S
     */
    protected setState(newState: partof S): void {
    }
}

Properties of partof

• Only works for object types (hence the 'extends {}' above) because I wouldn't know how to pass part of e.g. a string
• Allows any supertype of the given type
• Incorporates knowledge of the generic parameter. Given the class declaration class ReactComponent<S extends { foo: number; }>, one is able to call setState({ foo: 3}) and setState({}) but not setState({ bar: 3 }) inside the class definition.

Comments more than welcome, I'm not a compiler expert. This is just to get the discussion going. If you think there already exists a way of typing this, please check with the original issue for a couple of failed examples.

[rogierschouten]

@RyanCavanaugh what do you think?

[RyanCavanaugh]

Let's say for a moment we had a type operator optionalize that took an object type and produced a new object type whose properties were all optional. What would the trade-offs of that be vs partof for solving the React setState problem?

[rogierschouten]

I think that your description is more concise and clear, and I think optionalize is a very intuitively clear keyword. At first glance, I see no difference in usability between our proposals, do you?

[ahejlsberg]

A more general purpose alternative would be to allow super constrains for type parameters:

class ReactComponent<S extends {}> {
    protected _state: S;

    /**
     * This method accepts any supertype of S
     */
    protected setState<T super S>(newState: T): void {
    }
}

The requirement implied by T super S is that T must be a type to which S is assignable.

[rogierschouten]

@ahejlsberg that would work too, but I would avoid the word 'super' because one would not know whether you mean supertype or superclass or super-something-else. Maybe use 'S assignable T'?

However I've found a number of use cases for a type operator 'optionalize' like @RyanCavanaugh suggested - that way I can declare new types and declare variables of optionalized types.

[RyanCavanaugh]

The problem with super here is that it's inaccurate in several ways:

declare function setState<T super { s1: { x: Derived; y: number; } }>(s: T);

setState( { x1: 32 }); // No error, but wrong
setState( { s1: { y: 42 } }); // No error, but wrong
setState( { s1: { x: new Base(), y: 32 } }); // No error, but wrong

[kitsonk]

I also want to say that this use case is important to other libraries as well (and I think the title is a bit misleading, really what the intent of this is the way to operate on a type to make all its members optional).

I think it is a common pattern to pass an object literal to a constructor (or factory) function that can be any of the public properties of the instance class, which is then mixed in upon construction. I ran into this issue when trying to type Dojo 1 Dijits. The only option, if I wanted to type the constructor functions, is to create a wholly separate interface which has all optional members.

I agree super might give the wrong semantic impression. I suspect optionalize or optional would be more semantically clear:

class A {
  foo: string;
  bar(): string { return 'bar'; };
  constructor<O optionalize this>(options: O) { };
}

type OptionalA = optionalize A;

/*or*/

class B {
  foo: string;
  bar(): string { return 'bar'; };
  constructor(options: $Optionalize<this>) { };
}

type OptionalB = $Optionalize<B>;

[ahejlsberg]

Whatever we do here also applies to Object.assign that was introduced in ES2015.

[Strate]

Somewhere here in issues I see this proposal for similar case:

function assign<R extends A,B,C>(a:A, b:B, c:C):R

Isn't it the similar thing?

[rogierschouten]

@Strate I don't think so, see the first use case of post #6218. The first use case was solved like you said but the setState() use case wasn't.