Type meta dependencies

[NoelAbrahams]

Consider this scenario.

• An external web service that stores arbitrary JSON objects and provides querying services.
• A sample object could look like { "id": 100, "name": "Joe Bloggs" , "address":"1 London"}
• As users of this web service, we add and retrieve these "Person" objects and use it widely around the code base.
• Consequently, it makes sense to type this object:

interface Person {
   id: number;
   name: string;
   address: string;
}

• This is just great, because now we have compile time safety around most of the interaction with the external web service.
• There is, however, a small hole: the web service specifies the object that should be passed when querying the service as follows:

    interface Query {

          term: string; // The search term
          select: string; // A comma separated list of columns to return
    }

And we define the object as follows:

        var query: Query = {
            term: 'Joe',
            select: 'id,name'  // This is the hole
        };

• The property names defined here are obviously outside of the type system and are a potential source for bugs.
• In order to bring this into the type system we carry out the following hack:

       // Need to do this everywhere Query is used to request a Person
        var typeCheck: Person = <any>{};
        typeCheck.name;
        typeCheck.id;

        var query: Query = {
            term: 'Joe',
            select: 'id,name'
        };

The idea being that if someone changes, say, Person.name to Person.firstName then that would highlight the hidden reference to name in the string literal.

A similar problem was highlighted in #394.

I wonder if TypeScript could formalise this somehow:

        var query: Query <depends on meta of Person> = {
            term: 'Joe',
            select: 'id,name'
        };

so that it's not possible to change Person without breaking this code.

[danquirk]

As you noted #394 is similar but also seems simpler and more obviously applicable to a wide variety of scenarios. This seems like a somewhat awkward way to enforce a fairly specific pattern, unless you're saying this kind of thing is super common in a lot of frameworks. This is getting into some complex dependent type mappings or something.

[NoelAbrahams]

Yes, it's specific. The intention was to provide a use-case that will hopefully be taken into account when resolving #394

[danquirk]

Got it. There is definitely a large class of problems that our type system can't currently model with all these string based JavaScript APIs the tie string values to property names, events, etc. I'm hoping there are some targeted fixes we can make in the compiler (like #394) and tooling (like #606) that will improve things a bit but there will definitely still be holes. I'd love to come up with a more general, holistic approach but a lot of these APIs do things just differently enough to make it hard to see how to model them all well.