Partial Types

This is a proposal for #4889 and a variety of other issues.

Use Cases

Many libraries, notably React, have a method which takes an object and updates corresponding fields on some other object on a per-key basis. It looks like this

function setState<T>(target: T, settings: ??T??) {
  // ...
}
let obj = { a: 2, b: "ok", c: [1] };
setState(obj, { a: 4 }); // Desired OK
setState(obj, { a: "nope"}); // Desired error
setState(obj, { b: "OK", c: [] }); // Desired OK
setState(obj, { a: 1, d: 100 }); // Desired error
setState(obj, window); // Desired error

Observations

The update is rarely recursive (an exception is Mongo's query); this is a "shallow" operation
It's not desirable to allow "new" properties to appear
We're not looking for a supertype of some type (due to the non-recursive nature)

Unary `partial T` operator

A type partial T behaves as follows:

Its properties are the same as the properties of T, except that those properties are now optional
A S type is only assignable to type partial T if S has at least one property in common with T
- Otherwise regular structural subtype/assignability rules apply
The type partial (T | U) is equivalent to (partial T) | (partial U)
The type partial (T & U) does not expand (this would interact poorly with rule 2)
Any type T is always a subtype of partial T
The type partial T is equivalent to T if T is any, never, null, or undefined

More thoughts to come later, likely

A S type is only assignable to type subset T if S has at least one property in common with T

I thought we are not lumping week type detection in this proposal. so why the change?

Weak type detection everywhere would be a breaking change, whereas here we have an easy place to restrict the bad assignment.

Do excess property checks still apply though?

Of course

This is not the same as covariance/contravariance #1394 ?

It is one aspect of covariance I believe (in that subset T is covariant to T), but it is not a whole system of being able to deal with generic types in a full covariant/contravariant way. Covariance/contravariance implies the relationship of the whole type, versus just optionality of presence of particular properties of the type.

I would personally rather take this pragmatic approach to dealing with the usage patterns in JavaScript/TypeScript then wait for a total covariant/contravariant solution. I suspect this would not interfere with an eventual full solution (e.g. support C# type in T and out T generics).

On the weak type detection, I assume with something like this:

interface State {
    foo: string;
}

const a: subset State = {}; // not assignable?

The only challenge I see with that is that sometimes that might be unavoidable, but I guess that is an edge case.

Also what about something like this:

interface State {
    foo: string;
    bar: { baz: string; };
}

interface OptionalState {
    foo?: string;
}

interface LiteralState {
    foo: 'bar';
}

interface DeepState {
    bar: { baz: 'qat'; };
}

function setState<subset T>(state: T) { }

const a: OptionalState = {};
const b: LiteralState = { foo: 'bar' };
const c: DeepState = { bar: { baz: 'qat' } };

setState(a); // Ok?
setState(b); // Ok?
setState(c); // Ok?

Can you explain the choice of the name 'subset'?

type T = { a: string; b: number; }
type Subset = subset T; // equivalent to { a?: string; b?: number; }

The set of values in Subset is a superset of the set of values in T, if I understand this right?

Union and intersection types are named to describe how their value sets are constructed from the value sets of their constituent types. So it seems strange that subset T describes the construction of a value set that is a superset of T's values.

const a: subset State = {}; // not assignable?

I forgot to mention the special case that the empty type is not subject to the "at least one property in common" rule 👍

// Corrected to what I think you meant -- 'subset' is not a legal type parameter prefix
function setState(state: subset State) { }
setState(a); // OK: OptionalState has 'foo' in common with 'State'
setState(b); // Error: type 'string' not assignable to { baz: string }
setState(c); // OK: { bar: { baz: 'qat' } } assignable to { bar: { baz: string } }

Can you explain the choice of the name 'subset'?

Hopefully the intuition is at least apparent - that subset T has a subset of the properties of T. Whether we name something according to the set theory operation applied to the properties or to the values is somewhat arbitrary and while consistency is desirable, I'm not sure there's a good name that conveys the intent when seen in the other formulation of the domain, especially since the rule isn't intended to be recursive (which rules out things like super IMHO). Open to bikeshedding on this point.

Otherwise regular structural subtype/assignability rules apply

that wouldn't work with generic types. Need to better describe assignability rules, like:

if type S is a subtype of T then subset S is a subtype of subset T

Prototype (no generics, no sealedness) is working well

Open questions I have when implementing this:

What happens to call and construct signatures?
What happens to index signatures?
What is the correct precedence in parsing, e.g. is subset T | U equivalent to (subset T) | U, or subset (T | U) ?
Initial thinking is that subset (T | U) is exactly (subset T) | (subset U), is this correct?
Initial thinking is that subset (T & U) is exactly (subset T) & (subset U), is this correct?
Better name than subset ? Flow uses $Shape which is not intuitive at all

My opinions for what they are worth:

What happens to call and construct signatures?

Wouldn't these be optional too. Actually that might come in super handy when trying to deal with creating decorated functions:

interface Foo {
    (): void;
    foo: string;
}

const foo: subset Foo = function foo() { };
foo.foo = 'bar';
default export <Foo> foo;

I guess though, that raises the question in my head, is a subtype "frozen" at the point it is evaluated and assigned? For example:

interface State {
    foo: string;
    bar: number;
}

let a: subset State = { foo: 'string' };
let b: subset State = { bar: 1 };

let c = a; // what gets inferred?
let a = b; // is this valid?
let b = c; // is this valid?

What happens to index signatures?

These should persist unmodified to the subset and essentially be the only thing "required" in the subset.

What is the correct precedence in parsing, e.g. is subset T | U equivalent to (subset T) | U, or subset (T | U) ?

Would it be the same order of precedence as the typeof keyword in the type position? Which then only operates on the next type. So typeof foo | Bar is always (typeof foo) | Bar and therefore subset T | U would always be (subset T) | U.

Initial thinking is that subset (T | U) is exactly (subset T) | (subset U), is this correct?

Initial thinking is that subset (T & U) is exactly (subset T) & (subset U), is this correct?

We heavily use type FooBarState = FooState & BarState and I can't think of a situation where that I would expect (subset FooState) & (subset BarState) wouldn't be equal to subset (FooState & BarState). I guess the one exception is how you deal with index properties. I am not familiar how they are dealt with in unions and intersections anyways.

Troy Gerwien (@yortus)

I'm a little bit concerned that the keyword subset might not be appropriate in this case. My arguments are the same as Troy Gerwien (@yortus), so I won't repeat them . IMO subset is not an improvement over partial, which was the original proposal.

Two "type" operator end with of, such as typeof and instanceof and not to mention a third proposed keysof.

Since Ryan Cavanaugh (@RyanCavanaugh) mentioned that super is out of discussion, because it infers recursiveness. I tend to agree, so it rules out superset, supersetof, supertypeof etc.

What about shapeof? It's short, concise and consistent.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) will object spread stuffs still hit in 2.1 or do they have to come together?

Jason Killian (@jkillian)

Jason Killian (@jkillian) see #12114 . It slices, it dices, it makes partial types!

At last some good news in America!

Alexandre Galays (@AlexGalays)

Alexandre Galays (@AlexGalays) I hope you are talking about anything related to the partial types.

We'll close this with the assumption that #12114 (which is merged now) addresses all these use cases adequately - chime in with a new issue if that turns out not to be the case.

Ryan Cavanaugh (@RyanCavanaugh)

Hi Ryan Cavanaugh (@RyanCavanaugh), mapped types are fantastic, but it doesn't seem to address the questions above with deep partial types / deep subsets. Mapped types and Partial<> allow for a shallow subset, but all nested objects must be complete (though there are some dirty solutions). A PartialDeep generic would be fantastic.

The use case is that there is an API I'm building against which allows for object merges of very complex/deep objects.

Connor Peet (@connor4312)

Connor Peet (@connor4312)

type DeepPartial<T> = {
    [P in keyof T]?: DeepPartial<T[P]>;
};

this works just fine for me.

Igor Oleinikov (@Igorbek)

Igor Oleinikov (@Igorbek)

This gives zero control over Arrays for instance. It will iterate over their keys and allow you to access their method as nullable ones (concat, reduce, etc) which makes no sense. Same with a Date, etc.

ok, understood. My use case did require it. You then might be interested in #6606 with its mapping capabilities.

Also the related PR #17961. In fact, I'm facing the same problem. Will be extremely delighted when a solution becomes available.

Navigation Menu

Repository navigation

Partial Types #11233

Use Cases

Observations

Unary `partial T` operator

46 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Partial Types #11233

Description

Use Cases

Observations

Unary partial T operator

Activity

mhegazy commented on Sep 28, 2016

RyanCavanaugh commented on Sep 28, 2016

DanielRosenwasser commented on Sep 29, 2016

RyanCavanaugh commented on Sep 29, 2016

tinganho commented on Sep 29, 2016

kitsonk commented on Sep 29, 2016

kitsonk commented on Sep 29, 2016

yortus commented on Sep 29, 2016

RyanCavanaugh commented on Sep 29, 2016

Igorbek commented on Sep 29, 2016

RyanCavanaugh commented on Oct 3, 2016

kitsonk commented on Oct 4, 2016

tinganho commented on Oct 4, 2016

46 remaining items

rozzzly commented on Nov 7, 2016

RyanCavanaugh commented on Nov 9, 2016

AlexGalays commented on Nov 9, 2016

saschanaz commented on Nov 9, 2016

RyanCavanaugh commented on Nov 14, 2016

connor4312 commented on Sep 29, 2017

Igorbek commented on Sep 29, 2017

AlexGalays commented on Sep 29, 2017

Igorbek commented on Sep 30, 2017

alvis commented on Oct 12, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Unary `partial T` operator