Eso es interesante. Me complace revertir la parte parcial y seleccionar la parte del cambio

Diré que lo que informa suena como un error en TS, específicamente:

Escriba '{baseProp: "foobar"; } 'no se puede asignar al tipo' Parcial

Bien. Quizás TS no pueda saber qué pasa porque no existe una relación entre S y baseProp.

Se podría pasar una S de tipo { baseProp: number }, en cuyo caso es correcto que no se pueda asignar una cadena a baseProp.

¿Quizás si S extendiera la versión baseProp?

Había intentado algo como esto antes:

interface BaseState_t
{
    baseProp: string
}

export abstract class ComponentBaseClass<P, S extends BaseState_t> extends React.Component<P, S >
{
    foo()
    {
        this.state.baseProp;
        this.setState( { baseProp: 'foobar' } );
    }
}

mientras el acceso es correcto, la llamada setState tiene el mismo error:

Argumento de tipo '{baseProp: "foobar"; } 'no se puede asignar a un parámetro de tipo' ((prevState: Readonly \ , props: P) => Pick & Partial \ ) |
} 'no se puede asignar al tipo' Pick & Partial \ '.Escriba '{baseProp: "foobar";

Probablemente no sea una buena forma de estructurarlo; después de todo, alguna clase secundaria podría declarar variables de estado que colisionan con variables en la clase base. Entonces, mecanografiado podría tener razón al quejarse de que no puede estar seguro de lo que sucederá allí. Sin embargo, es extraño que no tenga problemas para acceder a esos accesorios.

Mmm. Esto definitivamente se siente como un error en TS ahora.

Jugaré con esto hoy y posiblemente sacaré el & Partial.

También agregaré esto como un caso de prueba y probaré otra idea para hacer feliz a intellisense

Hola,
El mismo problema aqui...

export interface ISomeComponent {
    field1: string;
    field2: string;
}

interface SomeComponentState {
    field: string;
}

export class SomeComponent<
    TProps extends ISomeComponent = ISomeComponent,
    TState extends SomeComponentState = SomeComponentState> extends React.Component<TProps, TState>{

    doSomething() {
        this.setState({ field: 'test' });
    }

    render() {
        return (
            <div onClick={this.doSomething.bind(this)}>
                {this.state.field}
            </div>
        );
    }
}

Error en setState:
TS2345 (TS) Argument of type '{ field: "test"; }' is not assignable to parameter of type '((prevState: Readonly<TState>, props: TProps) => Pick<TState, "field"> & Partial<TState>) | (Pick...'. Type '{ field: "test"; }' is not assignable to type 'Pick<TState, "field"> & Partial<TState>'. Type '{ field: "test"; }' is not assignable to type 'Partial<TState>'.

El error acaba de comenzar a ocurrir después de este cambio. En la versión 16.0.10 funcionó bien.

TypeScript tiene varios problemas relacionados, los han cerrado porque funcionan según lo diseñado:

https://github.com/Microsoft/TypeScript/issues/19388

Hice un resumen de algunos ejemplos aquí: https://gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

Aunque el comportamiento todavía parece extraño. En particular, puede asignar a una variable escrita como clase base sin conversión, y luego hacer las mismas llamadas con eso sin problema. Este problema parece sugerir que la asignación y la comparación son dos cosas diferentes.

No los he olvidado, chicos. Lo arreglará pronto

El RP al que se hace referencia debería resolver este problema. También agregué pruebas que deberían proteger contra la rotura de este caso de borde nuevamente.

@ericanderson Gracias por la rápida respuesta :)

¿La nueva solución tiene limitaciones o desventajas?

Ninguno que yo sepa actualmente. Pude mantener intellisense (en realidad mejor que antes, ya que resuelve algunos casos extremos).

Para elaborar, la solución & Partial<S> fue engañar a intellisense para revelar posibles parámetros, pero lo hizo indicando que son X | undefined . Esto, por supuesto, no se compilaría, pero era un poco confuso. Obtener el | S corrige el intellisense para que sugiera todos los parámetros correctos y ahora no muestra un tipo falso.

Intenté agregar null como un posible valor de retorno de la devolución setState llamada return; también válido), pero eso hizo que la inferencia de tipo se rindiera por completo y eligiera never como claves 😢

Por ahora, en las devoluciones de llamada donde realmente quiero omitir el estado de actualización, he estado usando return null! . El tipo never de este retorno hace que TypeScript ignore el retorno de la inferencia de tipo genérico.

Hola tios...

La última confirmación solucionó mi problema.
Gracias por la rápida respuesta :)

¿Qué versión tiene la solución? ¿Está publicado en npm? Estoy llegando al caso en el que la versión de devolución de llamada de setState me dice que hay una discrepancia de propiedad en el valor de retorno, al igual que @UselessPickles encontró.

Debería ser bueno en los últimos @ tipos / reaccionar

Lo arreglé para las series 15 y 16

import produce from 'immer';

interface IComponentState
{
    numberList: number[];
}

export class HomeComponent extends React.Component<ComponentProps, IComponentState>

La antigua definición de tipo de React.

// We MUST keep setState() as a unified signature because it allows proper checking of the method return type.
// See: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment-351013257
// Also, the ` | S` allows intellisense to not be dumbisense
setState<K extends keyof S>(
    state: ((prevState: Readonly<S>, props: P) => (Pick<S, K> | S)) | (Pick<S, K> | S),
    callback?: () => void
): void;

..produce este error:

Probé esta sugerencia:

setState<K extends keyof S>(
    state:
        ((prevState: Readonly<S>, props: P) => (Partial<S> & Pick<S, K>))
        | (Partial<S> & Pick<S, K>),
    callback?: () => any
): void;

Intellisense ahora puede sentir la propiedad del estado de React. Sin embargo, la propiedad detectada ahora se percibe como possibly undefined .

Tendría que usar un operador de aserción nula a pesar de que numberList no es indefinido ni anulable:

Me quedaré en la definición de tipo antiguo hasta que se mejore la detección de tipos. Mientras tanto, solo declararé explícitamente el tipo en el parámetro genérico de immer produce. produce<IComponentState> es más fácil de razonar que list! .

Su primer error se debe a que no devuelve nada. No es así como funciona setState.

Funciona incluso cuando no devuelve una variable en producir. Acabo de seguir el ejemplo aquí (no TypeScript):

https://github.com/mweststrate/immer

onBirthDayClick2 = () => {
    this.setState(
        produce(draft => {
            draft.user.age += 1
            // no need to return draft
        })
    )
}

Lo único que impide que TypeScript pueda ejecutar ese código es que tiene un tipo inferido incorrectamente de la definición de tipo de React. La definición de tipo informa un error de numberList does not exist on type Pick<IComponentState, never> . Solo puedo eliminar el error de compilación pasando explícitamente el tipo en el parámetro genérico de produce, es decir, produce<IComponentState> .

Incluso intenté devolver la variable en producir y ver si ayudaría a la definición de tipo de React a inferir el tipo (aunque un problema de pollito y huevo), pero aún no hay forma de que la definición de tipo de React detecte el tipo correcto del estado. Por lo tanto, el intellisense para borrador no aparece:

O tal vez tengo una expectativa incorrecta del compilador :) El compilador no puede crear un tipo para la variable borrador basado en el tipo de setState ya que el compilador procesa el código de adentro hacia afuera. Sin embargo, la definición de tipo sugerida de alguna manera me hizo pensar que el compilador puede procesar el código de afuera hacia adentro, que puede elegir el mejor tipo que puede pasar del código externo ( setState ) al código interno ( produce ).

setState<K extends keyof S>(
    state:
        ((prevState: Readonly<S>, props: P) => (Partial<S> & Pick<S, K>))
        | (Partial<S> & Pick<S, K>),
    callback?: () => any
): void;

Con la definición de tipo anterior, el compilador puede detectar que el borrador tiene una propiedad numberList . Aunque lo detecta como possibly undefined :

Tras realizar más retoques, hice que el compilador pudiera pasar el tipo del estado para producir el borrador agregando S a la definición de tipo de setState:

setState<K extends keyof S>(
    state:
        ((prevState: Readonly<S>, props: P) => (Partial<S> & Pick<S, K> & S))
        | (Partial<S> & Pick<S, K>),
    callback?: () => any
): void;

El código se está compilando ahora :)

Su error no es con setState, su error está dentro del producto. ¿Cuál es su definición de tipo para producir?

Mi PR anterior tiene un error en el script de prueba de DefinitelyTyped, no probé localmente. Así que ahora lo estoy probando localmente.

Aquí está la definición de tipo immer / produce.

/**
 * Immer takes a state, and runs a function against it.
 * That function can freely mutate the state, as it will create copies-on-write.
 * This means that the original state will stay unchanged, and once the function finishes, the modified state is returned.
 *
 * If the first argument is a function, this is interpreted as the recipe, and will create a curried function that will execute the recipe
 * any time it is called with the current state.
 *
 * <strong i="7">@param</strong> currentState - the state to start with
 * <strong i="8">@param</strong> recipe - function that receives a proxy of the current state as first argument and which can be freely modified
 * <strong i="9">@param</strong> initialState - if a curried function is created and this argument was given, it will be used as fallback if the curried function is called with a state of undefined
 * <strong i="10">@returns</strong> The next state: a new state, or the current state if nothing was modified
 */
export default function<S = any>(
    currentState: S,
    recipe: (this: S, draftState: S) => void | S
): S

// curried invocations with default initial state
// 0 additional arguments
export default function<S = any>(
    recipe: (this: S, draftState: S) => void | S,
    initialState: S
): (currentState: S | undefined) => S
// 1 additional argument of type A
export default function<S = any, A = any>(
    recipe: (this: S, draftState: S, a: A) => void | S,
    initialState: S
): (currentState: S | undefined, a: A) => S
// 2 additional arguments of types A and B
export default function<S = any, A = any, B = any>(
    recipe: (this: S, draftState: S, a: A, b: B) => void | S,
    initialState: S
): (currentState: S | undefined, a: A, b: B) => S
// 3 additional arguments of types A, B and C
export default function<S = any, A = any, B = any, C = any>(
    recipe: (this: S, draftState: S, a: A, b: B, c: C) => void | S,
    initialState: S
): (currentState: S | undefined, a: A, b: B, c: C) => S
// any number of additional arguments, but with loss of type safety
// this may be alleviated if "variadic kinds" makes it into Typescript:
// https://github.com/Microsoft/TypeScript/issues/5453
export default function<S = any>(
    recipe: (this: S, draftState: S, ...extraArgs: any[]) => void | S,
    initialState: S
): (currentState: S | undefined, ...extraArgs: any[]) => S

// curried invocations without default initial state
// 0 additional arguments
export default function<S = any>(
    recipe: (this: S, draftState: S) => void | S
): (currentState: S) => S
// 1 additional argument of type A
export default function<S = any, A = any>(
    recipe: (this: S, draftState: S, a: A) => void | S
): (currentState: S, a: A) => S
// 2 additional arguments of types A and B
export default function<S = any, A = any, B = any>(
    recipe: (this: S, draftState: S, a: A, b: B) => void | S
): (currentState: S, a: A, b: B) => S
// 3 additional arguments of types A, B and C
export default function<S = any, A = any, B = any, C = any>(
    recipe: (this: S, draftState: S, a: A, b: B, c: C) => void | S
): (currentState: S, a: A, b: B, c: C) => S
// any number of additional arguments, but with loss of type safety
// this may be alleviated if "variadic kinds" makes it into Typescript:
// https://github.com/Microsoft/TypeScript/issues/5453
export default function<S = any>(
    recipe: (this: S, draftState: S, ...extraArgs: any[]) => void | S
): (currentState: S, ...extraArgs: any[]) => S
/**
 * Automatically freezes any state trees generated by immer.
 * This protects against accidental modifications of the state tree outside of an immer function.
 * This comes with a performance impact, so it is recommended to disable this option in production.
 * It is by default enabled.
 */
export function setAutoFreeze(autoFreeze: boolean): void

/**
 * Manually override whether proxies should be used.
 * By default done by using feature detection
 */
export function setUseProxies(useProxies: boolean): void

@ericanderson, ¿ podría indicarme la discusión sobre por qué se usa Pick lugar de Partial ? Esto me ha estado causando horas de dolor (usando setState(obj) simple, no la versión de devolución de llamada), y por ahora voy con this.setState(newState as State) como solución. Solo quiero entender por qué se cambió, porque debo estar perdiendo algo.

Hola @ericanderson ,

Tengo algún problema con la última definición.

Mi caso de uso es brevemente así:

interface AppState {
  valueA: string;
  valueB: string;
  // ... something else
} 
export default class App extends React.Component <{}, AppState> {
  onValueAChange (e:React.ChangeEvent<HTMLInputElement>) {
    const newState: Partial<AppState> = {valueA: e.target.value}
    if (this.shouldUpdateValueB()) {
      newState.valueB = e.target.value;
    }
    this.setState(newState); // <-- this leads to a compiling error
  }
  // ... other methods
}

El mensaje de error es como:

Argument of type 'Partial<AppState>' is not assignable to parameter of type 'AppState | ((prevState: Readonly<AppState>, props: {}) => AppState | Pick<AppState, "valueA" | "v...'.
  Type 'Partial<AppState>' is not assignable to type 'Pick<AppState, "valueA" | "valueB" | "somethingElse">'.
    Types of property 'valueA' are incompatible.
      Type 'string | undefined' is not assignable to type 'string'.
        Type 'undefined' is not assignable to type 'string'.

Parece que Partial<AppState> no es compatible con la firma de setState . Por supuesto que puedo resolver esto mediante una afirmación de tipo como

this.setState(newState as Pick<AppState, 'valueA' | 'valueB'>)

pero no es ideal, porque:
1) esta sintaxis es muy detallada
2) lo que es más importante, la afirmación de tipo podría violar mis datos reales. Por ejemplo, newState as Pick<AppState, 'somethingElse'> también pasa la verificación, aunque no se ajusta a mis datos.

Creo que parcialdebería ser compatible de alguna manera con Pick, desde Parcialsimplemente elige un número incierto de claves de T. No estoy seguro de que mi comprensión sea precisa. De todos modos, el uso ideal desde mi punto de vista debería ser que pueda pasar la variable escrita Parcialdirectamente en setState.

¿Podría considerar amablemente mi sugerencia o señalar mi malentendido si lo hay? ¡Gracias!

Este es un cambio muy antiguo en primer lugar. Entonces, a menos que alguien más haya cambiado esto recientemente, probablemente esté ladrando al árbol equivocado.

Dicho eso. Parcial permite valores indefinidos.

const a: Partial <{foo: string}> = {foo: undefined}

a es válido, pero claramente el resultado de esa actualización de su estado pone a su estado con foo indefinido a pesar de que usted declaró que eso es imposible.

Por lo tanto, un parcial no se puede asignar a un Pick. Y Pick es la respuesta correcta para asegurarse de que sus tipos no mientan

Siento que no permitiendo:

setState((prevState) => {
  if (prevState.xyz) {
    return { foo: "" };
  }
  return { bar: "" };
});

es super restrictivo.

La solución de @Kovensky es la única solución sensata que conozco, pero sigue siendo dolorosa de escribir.

¿Hay algo que se pueda hacer para respaldar este (yo diría) patrón bastante común?

Lo único que se puede hacer es eliminar la seguridad de tipos

¿Alguien puede explicar el razonamiento de Pick<S, K> | S | null ?

        setState<K extends keyof S>(
            state: ((prevState: Readonly<S>, props: Readonly<P>) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null),
            callback?: () => void
        ): void;

Tbh, ni siquiera ahora, ¿por qué la firma anterior funciona incluso para actualizaciones de estado parciales, ya que K se define como keyof S entonces Pick<S, K> esencialmente recrea S ?

¿No debería Partial<S> | null hacer el trabajo también?

        setState(
            state: ((prevState: Readonly<S>, props: Readonly<P>) => (Partial<S> | null)) | (Partial<S> | null),
            callback?: () => void
        ): void;

¿Alguien puede explicar ...

Se ha explicado claramente en algunas respuestas.

setState((prevState) => {
  if (prevState.xyz) {
    return { foo: "" };
  }
  return { bar: "" };
});

es super restrictivo.

La solución de @Kovensky es la única solución sensata que conozco, pero sigue siendo dolorosa de escribir.

Acabo de encontrar este problema exacto, pero no puedo ver ninguna referencia a Kovensky en el hilo (¿tal vez alguien cambió su nombre de usuario?). ¿Alguien puede indicarme la solución alternativa recomendada actualmente?

@ timrobinson33 Este comentario explica la solución https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment -351884578

Y es bueno que ya no tengamos que preocuparnos por esto con los ganchos 🙂

@ timrobinson33 Este comentario explica la solución alternativa # 18365 (comentario)

Muchas gracias por eso. Al final, pensé que mi código se veía mejor con varias llamadas pequeñas a setState con declaraciones If fuera de ellas, aunque esto significa que algunas rutas llamarán a setState más de una vez.

Supongo que esto es similar a cómo trabajamos con los ganchos, viendo el estado como varias cosas pequeñas que actualizamos de forma independiente.