Typescript: typeof this.xxx da un error de "identificador esperado".

Creado en 24 dic. 2014  ·  19Comentarios  ·  Fuente: microsoft/TypeScript

image

¿Es esto por diseño o un error?

Suggestion help wanted

Comentario más útil

@ sam-s4s hoy en día tienes algo para poder escribir CMultiDataset<this["thing"]> , en su lugar. Los accesos indexados _do_ funcionan con this (uno polimórfico, par), a diferencia de typeof .

Lo acabo de intentar, pero no funciona en TypeScript 3.4.4. Sin embargo, el de @ sam-s4s funciona ( ClassName['thing'] ). Creo que podría tener más sentido que this debería funcionar, en lugar de solo poder usar el "ClassName".

Todos 19 comentarios

Yo diría que tampoco ... es simplemente una sintaxis incorrecta ... intente "var copy = typeof (this.data = {});" ... habiendo dicho esto, no usaría este código ... es confuso ... .

@giancarloa hmm, no deberías agregar esos corchetes. el código anterior es solo un desencadenante de problema mínimo, no un código en producción, en algunas situaciones es posible que desee utilizar un código como este.

aquí, si lleva this a otra cosa que no sea eso, estaría bien y no se informaría ningún error. p.ej

class Test {
    static data = {};
    constructor() {
        var copy: typeof Test.data = {};
    }
}

Según la especificación

_TypeQueryExpression: _
_Identificador_
_TypeQueryExpression_ . _IdentifierName_

Entonces esto es lo esperado.

Creo que la razón por la que no está permitido es que algo como esto

function foo() {
    var x: typeof this.x;
}

es perfectamente válido, porque this más o menos tiene el tipo any . Entonces, si bien podría tener sentido en una clase, no tiene sentido en ningún otro contexto a menos que tengamos el número 229.

@DanielRosenwasser OO hmm ... entonces espero que consideres actualizar la especificación. lol.

Es algo a considerar; Si sus miembros no son privados, puede evitarlo fácilmente con lo siguiente mientras tanto.

self = this;
var x: typeof self.data;

Esperando esta función.
Creo que el caso más simple debería ser compatible.
var a: tipo de esto.x = 1;

Y un miembro typeof recursivo debería dar lugar a un error.

Gracias.

Parece que esto debería funcionar si cambiamos la gramática.

@RyanCavanaugh , pero ¿es apropiado permitirlo en el contexto que di? Inevitablemente conducirá a que la gente lo haga y obtenga any como su tipo.

sintácticamente correcto no tiene por qué significar que realmente debería tener sentido, en mi opinión.
Sin embargo, podría emitirse una advertencia por esta causa.

Ya le permitimos escribir typeof foo.bar donde foo es del tipo any , y ya le permitimos escribir this.x en otras posiciones de expresión punteada cuando el tipo de this es any . No veo por qué su intersección en typeof this.x debería merecer una excepción.

Solo para agregar otro caso de uso. Hace algún tiempo hice las definiciones de tipo para lodash y algunas de las firmas admitidas son realmente alias para otros métodos. Los había declarado así:

interface LoDashArrayWrapper<T> {
    rest(): LoDashArrayWrapper<T>;
    rest(
        callback: ListIterator<T, boolean>,
        thisArg?: any): LoDashArrayWrapper<T>;
    rest(n: number): LoDashArrayWrapper<T>;
    rest(pluckValue: string): LoDashArrayWrapper<T>;
    rest(whereValue: {}): LoDashArrayWrapper<T>;

    drop: typeof rest;

    tail: typeof rest;
}

Esto funcionó bien con la versión 1.0 del compilador. Pero ya no se compila. Y no veo ninguna otra opción además de duplicar todo el conjunto de firmas para cada alias, ya que no puedo pensar en una TypeQueryExpression que exprese esto.

@juanevp ¿Qué tal la interfaz de funciones?

interface LoDashArrayWrapper<T> {
    rest: LoDashArrayWrapperOperation<T>;
    drop: LoDashArrayWrapperOperation<T>;
    tail: LoDashArrayWrapperOperation<T>;
}

interface LoDashArrayWrapperOperation<T> {
    (): LoDashArrayWrapper<T>;
    (
        callback: ListIterator<T, boolean>,
        thisArg?: any): LoDashArrayWrapper<T>;
    (n: number): LoDashArrayWrapper<T>;
    (pluckValue: string): LoDashArrayWrapper<T>;
    (whereValue: {}): LoDashArrayWrapper<T>;
}

Aprobado. ¿Debería ser una solución extremadamente fácil? Sin embargo, asegúrese de que esto no cause que _this = this emita en las funciones de flecha

¿Está esto relacionado? Obtengo [ts] Identifier expected. con lo siguiente:


class UserState {
    <strong i="7">@observable</strong> state = {
        name : "",
        id : "",
    };

    <strong i="8">@action</strong>
    changeUser(user: typeof this.state) { // Error is here
        Object.assign(this.state, user);
    }
}

export const userState = new UserState();

Sería útil poder usar this.state en el caso anterior.

Hmmm me acabo de encontrar con este problema :(

Estoy definiendo un objeto en mi clase.
Luego estoy definiendo otro objeto que tiene un parámetro de tipo que debe ser del tipo anterior.

thing = {
    a: 1,
    b: 2
};
multi: CMultiDataset<typeof this.thing>;

En este caso, no es apropiado simplemente cambiar algo a una variable estática y decir typeof ClassName.thing porque será diferente en cada instancia. Además, multi debe ser una variable de clase y, por lo tanto, debe tener su tipo en el tiempo de declaración de la clase.

@RyanCavanaugh @DanielRosenwasser @mhegazy suena como si se pensara que esto era una solución relativamente fácil. Sin embargo, parece que se ha ido perdiendo de atención a lo largo de los años ... ¿Alguna posibilidad de que se implemente?

@ sam-s4s hoy en día tienes algo para poder escribir CMultiDataset<this["thing"]> , en su lugar. Los accesos indexados _do_ funcionan con this (uno polimórfico, par), a diferencia de typeof .

Gracias @weswigham - Descubrí que puedo hacer CMultiDataset<ClassName['thing']> que me saca de los problemas :)

No pude encontrar ninguna combinación usando this que funcione aunque ...

@ sam-s4s hoy en día tienes algo para poder escribir CMultiDataset<this["thing"]> , en su lugar. Los accesos indexados _do_ funcionan con this (uno polimórfico, par), a diferencia de typeof .

Lo acabo de intentar, pero no funciona en TypeScript 3.4.4. Sin embargo, el de @ sam-s4s funciona ( ClassName['thing'] ). Creo que podría tener más sentido que this debería funcionar, en lugar de solo poder usar el "ClassName".

Si tengo algo como
mecanografiado
public groupByTypes = ['Ninguno', 'Foo', 'Bar'] como constante;

public groupBy: typeof groupByTypes [número];
`` What is the proposed workaround? And I cannot make groupByTypes` estático

¿Fue útil esta página
0 / 5 - 0 calificaciones