Augment Key during Type Mapping

[MeirionHughes]

Aurelia follows the convention that for any field foo, when foo is changed by the framework, then an attempt to call fooChanged() is made. There is (seemingly) no way to describe this convention as a type (automatically) via the Mapped Type functionality alone.

I would like to open discussion to the prospect of augmenting property keys during mapping.

For example: via arthimetic:

type Changed<T> = 
{          
   [ P in keyof T ] + "Changed" ?: Function;
}

class Foo{
  field:number;
}

let foo = <Foo & Changed<Foo>> new Foo();

foo.field = 10;

if(foo.fieldChanged)
  foo.fieldChanged();

in this use-case specifically it probably would require #12424 too, but that is beside the point here.

[yortus]

Another relevant example is bluebird's promisifyAll. E.g.:

type Before = {
    foo: (callback: (err, res) => void) => void
    bar: (x: string, callback: (err, res) => void) => void
}

// promisifyAll would map Before to After - note all keys have 'Async' appended:
type After = {
    fooAsync: () => Promise<any>;
    barAsync: (x: string) => Promise<any>;
}

let before: Before;
let after: After = promisifyAll(before);

[saschanaz]

I think unusual complex type operations like this should be supported by programmatic type builder like #9883.

[Nimelrian]

Digging this one out since I'm wrestling with a use case for this right now: Scoping redux actions.
I have an interface Action:

interface Action<Type extends string> {
  type: Type
}

to avoid clashes with (e.g.) third party libraries, I scope my actions, for example like this:

export const createScopedActionType = _.curry((scope: string, type: string) => `${scope}/${type}`);

const createActionInMyScope = createScopedActionType("MyScope");
const MY_ACTION = createActionInMyScope("MY_ACTION");

It is known at compile time that MY_ACTION will have a value of "MyScope/MY_ACTION" and such should be its type. Typescript however sees it as a string.

I could obviously assign the resulting value directly, but that would reduce maintainability since with the approach depicted above I can simply reuse my partially applied function. So I only have to define my scope once. If I were to use regular assignments, I would have to change multiple lines of code (and be in danger of missing an instance!) if the name of the scope would change.

A compile time evaluation of functions called with literals (if evaluatable, as in: no side effects, no parameter modification => pure functions) should yield the final type/value returned by the function call.

C++ has a similar concept with constant expressions (constexpr).

I'm not sure in how far Typescript would allow the implementation of such a feature, but it would be a great help in keeping code maintainable and modular.

[Retsam]

It might be nice to revisit this issue in light of the 2.8 enhancements. Specifically, I think this issue is the only thing prevent a good implementation of Bluebird.promisifyAll. It was mentioned previously in this thread, but I think return type inference was an important piece of the puzzle that was also missing, until now.

[markusmauch]

In our library, a Component class has for each of it's private properties (here id) an associated public getter function:

class Component { 
    private _id: string;
    public get_id() { 
        return this._id;
    }
}

For each component we have an additional Properties interface that - in this case - has an id property:

interface Properties {
    id:? string;
}

There is a lot of error-prone redundancy in here which caused us a lot of trouble in the past. With the new conditional types feature of TypeScript 2.8 I would love to see a linq-style syntax in indexed types:

type Properties<T extends Component> =
{
    [ P in keyof T where P.startsWith( 'get_' ) select P.replace( 'get_', '' ) as K ]: ReturnType<T[K]>;
}                                                                                            |
                                                                                             ReturnType is defined in TypeScript 2.8  
let componentProperties: Properties<Component>;
componentProperties.id = "foo"; // string is fine
componentProperties.id = true; // error

[ddurschlag6river]

In Loopback, a DB's order clause is specified as:

{ order: 'field ASC' }

or

{ order: [ 'field1 DESC', 'field2 ASC' ] }

I think this feature is required for TS to type this field appropriately.