Isso é interessante. Estou feliz em reverter a parte parcial e escolher a parte da mudança

Direi que o que você relata parece um bug no TS, especificamente:

Digite '{baseProp: "foobar"; } 'não pode ser atribuído ao tipo' Parcial

Tudo bem. Talvez o TS não saiba o que está acontecendo porque não há relação entre S e baseProp.

Pode-se passar um S do tipo { baseProp: número }, caso em que é correto que você não pode atribuir uma string a baseProp.

Talvez se S estendesse a versão baseProp?

Eu tinha tentado algo assim 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' } );
    }
}

enquanto o acesso está ok, a chamada setState tem o mesmo erro:

Argumento do tipo '{baseProp: "foobar"; } 'não é atribuível ao parâmetro do tipo' ((prevState: Readonly \ , props: P) => Pick & Partial \ ) |
} 'não pode ser atribuído ao tipo' Seleção e parcial \ '.Digite '{baseProp: "foobar";

Provavelmente não é uma boa maneira de estruturá-lo - afinal, alguma classe filha poderia declarar variáveis ​​de estado que colidiram com variáveis ​​na classe base. Portanto, o texto datilografado pode estar certo em reclamar que não é possível ter certeza do que vai acontecer lá. É estranho que ele não tenha nenhum problema em acessar esses adereços.

Hmm. Isso definitivamente parece um bug no TS agora.

Vou brincar com isso hoje e, possivelmente, tirar o & Partial.

Vou adicionar isso como um caso de teste também e tentar outra ideia para tornar o intellisense feliz

Oi,
Mesmo 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>
        );
    }
}

Erro em 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>'.

O erro só começou a acontecer após essa mudança. Na versão 16.0.10 funcionou bem.

O texto datilografado tem vários problemas relacionados, eles os fecharam conforme planejado:

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

Fiz alguns exemplos aqui: https://gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

Embora o comportamento ainda pareça estranho. Em particular, você pode atribuir a uma variável digitada como a classe base sem conversão e, em seguida, fazer as mesmas chamadas sem problemas. Este problema parece sugerir que atribuição e comparação são duas coisas diferentes.

Não esqueci de vocês. Vai consertar em breve

O PR referenciado deve resolver este problema. Eu também adicionei testes que devem proteger contra quebrar este caso extremo novamente.

@ericanderson Obrigado pela resposta rápida :)

A nova correção tem alguma limitação / desvantagem?

Nenhum que eu conheça atualmente. Consegui manter o intellisense (na verdade melhor do que antes, pois resolve alguns casos extremos).

Para elaborar, a solução & Partial<S> era enganar o intellisense para revelar possíveis parâmetros, mas o fez afirmando que eles são X | undefined . Isso, é claro, não conseguiria compilar, mas era um pouco confuso. Obter | S corrige o intellisense de forma que sugere todos os parâmetros corretos e agora não mostra um tipo falso.

Tentei adicionar null como um possível valor de retorno do retorno de chamada setState (o que você pode retornar para indicar que não deseja alterar nenhum estado, sem fazer return; também válido), mas isso fez com que a inferência de tipo desistisse completamente e pegasse never como as chaves 😢

Por enquanto, nos retornos de chamada em que realmente desejo pular o estado de atualização, estou usando return null! . O tipo never desse retorno faz com que o TypeScript ignore o retorno para a inferência de tipo genérico.

Oi, pessoal...

O último commit corrigiu meu problema.
Obrigado pela resposta rápida :)

Qual versão tem a correção? É publicado no npm? Estou chegando ao caso em que a versão de retorno de chamada de setState está me informando que há uma incompatibilidade de propriedade no valor de retorno, assim como @UselessPickles encontrado.

Deve ser bom nos últimos @ types / react

Consertei para as séries 15 e 16

import produce from 'immer';

interface IComponentState
{
    numberList: number[];
}

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

A definição de tipo antigo do 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;

..produz este erro:

Tentei esta sugestão:

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

O Intellisense agora pode detectar a propriedade do estado de React. No entanto, a propriedade detectada agora é percebida como possibly undefined .

Teria que usar o operador de asserção nulo, embora numberList não seja indefinido nem anulável:

Vou ficar na definição de tipo antigo até que o sensor de tipo seja aprimorado. Por enquanto, apenas declararei explicitamente o tipo no parâmetro genérico do produto immer. produce<IComponentState> é mais fácil de raciocinar do que list! .

Seu primeiro erro é porque você não está devolvendo nada. Não é assim que setState funciona.

Funciona mesmo quando não retorna uma variável no produto. Acabei de seguir o exemplo aqui (não TypeScript):

https://github.com/mweststrate/immer

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

A única coisa que impede o TypeScript de executar esse código é que ele inferiu incorretamente o tipo da definição de tipo React. A definição de tipo relata um erro de numberList does not exist on type Pick<IComponentState, never> . Consegui apenas eliminar o erro de compilação passando explicitamente o tipo no parâmetro genérico do produto, ou seja, produce<IComponentState> .

Eu até tentei retornar a variável em produzir e ver se isso ajudaria a definição de tipo do React a inferir o tipo (um problema de ovo e galinha), mas ainda não há como a definição de tipo do React detectar o tipo correto do estado. Portanto, o intellisense para o calado não está aparecendo:

Ou talvez eu tenha uma expectativa errada do compilador :) O compilador não pode fazer um tipo para a variável de rascunho com base no tipo de setState enquanto o compilador processa o código de dentro para fora. No entanto, a definição de tipo sugerida de alguma forma me fez pensar que o compilador pode processar o código de fora para dentro, que pode escolher o melhor tipo que pode passar do código externo ( setState ) para o 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;

Com a definição de tipo acima, o compilador pode detectar que o rascunho possui uma propriedade numberList . Ele detecta como possibly undefined embora:

Após alguns ajustes, tornei o compilador capaz de passar o tipo do estado para o rascunho do produto adicionando S à definição 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;

O código está compilando agora :)

Seu erro não é com setState, seu erro está dentro do produto. Qual é a sua definição de tipo para produto?

Meu PR acima tem um erro no script de teste do DefinitelyTyped, não testei localmente. Então, estou testando localmente agora.

Aqui está a definição do tipo immer / produzir.

/**
 * 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, você poderia me indicar a discussão sobre por que Pick é usado em vez de Partial ? Isso tem me causado horas de pesar (usando apenas setState(obj) , não a versão de retorno de chamada) e, por enquanto, vou usar this.setState(newState as State) como solução alternativa. Só quero entender por que mudou, porque devo estar faltando alguma coisa.

Olá @ericanderson ,

Tenho alguns problemas com a definição mais recente.

Meu caso de uso é resumidamente assim:

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
}

A mensagem de erro é assim:

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> não é compatível com a assinatura de setState . Claro que posso resolver isso por tipo de asserção, como

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

mas não é o ideal, porque:
1) esta sintaxe é muito detalhada
2) mais importante, a asserção de tipo pode violar meus dados reais. Por exemplo, newState as Pick<AppState, 'somethingElse'> também passa na verificação, embora não se encaixe em meus dados.

Eu acho parcialdeve de alguma forma compatível com Pick, já que parcialapenas escolhe um número incerto de chaves de T. Não tenho certeza se meu entendimento está correto. De qualquer forma, o uso ideal do meu ponto de vista deve ser que eu possa passar a variável digitada Partialdiretamente em setState.

Você poderia gentilmente considerar minha sugestão ou apontar meu mal-entendido, se houver? Obrigado!

Esta é uma mudança muito antiga, em primeiro lugar. Portanto, a menos que alguém tenha mudado isso recentemente, você provavelmente está latindo na árvore errada.

Dito isto. Parcial permite valores indefinidos.

const a: Parcial <{foo: string}> = {foo: indefinido}

a é válido, mas claramente o resultado dessa atualização em seu estado coloca seu estado com foo sendo indefinido, embora você tenha declarado que isso é impossível.

Portanto, um parcial não pode ser atribuído a um Pick. E Pick é a resposta certa para garantir que seus tipos não mentem

Eu sinto que não permitindo:

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

é super restritivo.

A solução alternativa de @Kovensky é a única solução sensata que conheço, mas ainda dolorosa de escrever.

Existe algo que pode ser feito para apoiar este (eu diria) padrão bastante comum?

A única coisa que pode ser feita é remover o tipo de segurança

Alguém pode explicar o motivo 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, eu nem mesmo agora por que a assinatura acima funciona para atualizações de estado parciais como K é definido como keyof S então Pick<S, K> essencialmente recria S ?

Partial<S> | null não deveria fazer o trabalho também?

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

Alguém pode explicar ...

Foi explicado claramente algumas respostas acima.

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

é super restritivo.

A solução alternativa de @Kovensky é a única solução sensata que conheço, mas ainda dolorosa de escrever.

Acabei de encontrar exatamente esse problema, mas não consigo ver nenhuma referência a Kovensky no tópico (talvez alguém tenha alterado o nome de usuário?). Alguém pode me indicar a solução alternativa atualmente recomendada

@ timrobinson33 Este comentário explica a solução alternativa https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment -351884578

E é uma coisa boa não termos que nos preocupar mais com isso com ganchos 🙂

@ timrobinson33 Este comentário explica a solução alternativa # 18365 (comentário)

Muito obrigado por isso. No final, achei que meu código parecia melhor com várias pequenas chamadas setState com instruções If fora delas, embora isso signifique que alguns caminhos chamarão setState mais de uma vez.

Eu acho que isso é realmente semelhante a como trabalhamos com ganchos, vendo o estado como várias pequenas coisas que atualizamos independentemente.