C'est intéressant. Je suis heureux d'annuler la partie partielle et de sélectionner la partie du changement

Je dirai que ce que vous signalez ressemble à un bogue dans TS, en particulier :

Tapez '{ baseProp: "foobar" ; }' n'est pas assignable au type 'Partiel

Bien. Peut-être que TS ne peut pas savoir ce qui se passe car il n'y a pas de relation entre S et baseProp.

On pourrait passer un S de type { baseProp:number } auquel cas il est correct que vous ne puissiez pas affecter de chaîne à baseProp.

Peut-être que si S étendait la version baseProp ?

J'avais déjà essayé quelque chose comme ça :

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' } );
    }
}

alors que l'accès est ok, l'appel setState a la même erreur :

Argument de type '{ baseProp: "foobar"; }' n'est pas assignable au paramètre de type '((prevState: Readonly\ , props: P) => Pick & Partial\ ) |
}' n'est pas assignable au type 'Pick & Partial\ '.Tapez '{ baseProp: "foobar" ;

Ce n'est probablement pas un bon moyen de le structurer - après tout, une classe enfant pourrait déclarer des variables d'état qui entrent en collision avec des variables de la classe de base. Donc, le tapuscrit a peut-être raison de se plaindre qu'il ne peut pas être sûr de ce qui va se passer là-bas. Il est étrange qu'il n'y ait aucun problème pour accéder à ces accessoires.

Hmm. Cela ressemble définitivement à un bogue dans TS maintenant.

Je vais jouer avec ça aujourd'hui et éventuellement sortir le & Partial.

Je vais également ajouter ceci comme cas de test et essayer une autre idée pour rendre intellisense heureux

Salut,
Même problème ici...

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>
        );
    }
}

Erreur dans 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>'.

L'erreur vient de commencer à se produire après ce changement. Dans la version 16.0.10, cela fonctionnait bien.

Typescript a plusieurs problèmes liés, ils les ont fermés comme fonctionnant comme prévu :

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

J'ai fait un aperçu de quelques exemples ici : https://gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

Bien que le comportement semble toujours étrange. En particulier, vous pouvez affecter une variable typée comme classe de base sans transtypage, puis effectuer les mêmes appels avec celle-ci sans problème. Ce problème semble suggérer que l'affectation et la comparaison sont deux choses différentes.

Je ne vous ai pas oublié les gars. Réparera bientôt

Le PR référencé devrait résoudre ce problème. J'ai également ajouté des tests qui devraient protéger contre la rupture de ce boîtier de bord à nouveau.

@ericanderson Merci pour la réponse rapide :)

Le nouveau correctif a-t-il des limitations/inconvénients ?

Aucun à ma connaissance actuellement. J'ai pu garder intellisense (en fait mieux qu'avant, car il résout certains cas limites).

Pour élaborer, la solution & Partial<S> consistait à tromper intellisense pour révéler des paramètres possibles, mais il l'a fait en déclarant qu'ils sont X | undefined . Cela échouerait bien sûr à compiler, mais c'était un peu déroutant. Obtenir le | S corrige l'intellisense afin qu'il suggère tous les bons paramètres et maintenant il n'affiche pas de faux type.

J'ai essayé d'ajouter null comme valeur de retour possible du rappel setState (ce que vous pouvez retourner à l'état, vous ne voulez changer aucun état, sans faire de return; également valide), mais cela a plutôt fait abandonner complètement l'inférence de type et choisir never comme clés 😢

Pour l'instant, dans les rappels où je veux réellement ignorer l'état de mise à jour, j'ai utilisé return null! . Le type never de ce retour fait que TypeScript ignore le retour pour l'inférence de type générique.

Salut les gars...

Le dernier commit a résolu mon problème.
Merci pour la réponse rapide :)

Quelle version a le correctif? Est-il publié sur npm ? Je rencontre le cas où la version de rappel de setState me dit qu'il y a une incompatibilité de propriété dans la valeur de retour, tout comme @UselessPickles trouvé.

Devrait être bon sur les derniers @types/react

Je l'ai corrigé pour les séries 15 et 16

import produce from 'immer';

interface IComponentState
{
    numberList: number[];
}

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

L'ancienne définition de type 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;

..produit cette erreur :

J'ai essayé cette proposition :

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 peut désormais détecter la propriété à partir de l'état de React. Cependant, la propriété détectée est maintenant perçue comme possibly undefined .

Devrait utiliser l'opérateur d'assertion null même si numberList n'est ni indéfini ni nullable :

Je vais rester sur l'ancienne définition de type jusqu'à ce que la détection de type soit améliorée. En attendant, je vais juste indiquer explicitement le type sur le paramètre générique de immer produire. produce<IComponentState> est plus facile à raisonner que list! .

Votre première erreur est que vous ne retournez rien. Ce n'est pas ainsi que fonctionne setState.

Cela fonctionne même lorsqu'il ne renvoie pas de variable dans produire. Je viens de suivre l'exemple ici (non TypeScript):

https://github.com/mweststrate/immer

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

La seule chose qui empêche TypeScript d'exécuter ce code est qu'il a un type déduit à tort de la définition de type React. La définition de type signale une erreur de numberList does not exist on type Pick<IComponentState, never> . Juste capable de faire disparaître l'erreur de compilation en passant explicitement le type sur le paramètre générique de produire, c'est-à-dire produce<IComponentState> .

J'ai même essayé de renvoyer la variable dans produire et de voir si cela aiderait la définition de type React à déduire le type (un problème de poussin et d'œuf), mais il n'y a toujours aucun moyen pour la définition de type React de détecter le type correct de l'état. Par conséquent, l'intellisens pour le brouillon n'apparaît pas :

Ou peut-être que j'ai une mauvaise attente du compilateur :) Le compilateur ne peut pas créer un type pour la variable de brouillon basé sur le type de setState car le compilateur traite le code de l'intérieur vers l'extérieur. Cependant, la définition de type suggérée m'a fait penser que le compilateur peut traiter le code de l'extérieur vers l'intérieur, qu'il peut choisir le meilleur type qu'il peut passer du code externe ( setState ) au code interne ( 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;

Avec la définition de type ci-dessus, le compilateur peut détecter que le brouillon a une propriété numberList . Il le détecte comme possibly undefined cependant :

Après avoir bricolé davantage, j'ai rendu le compilateur capable de transmettre le type de l'état au brouillon de produire en ajoutant le S à la définition de type 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;

Le code se compile maintenant :)

Votre erreur n'est pas avec setState, votre erreur est à l'intérieur de produire. Quelle est votre définition de type pour les produits ?

Mon PR ci-dessus a une erreur sur le script de test de DefinitelyTyped, je n'ai pas testé localement . Je le teste donc localement maintenant.

Voici la définition du type 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 pourriez-vous m'indiquer la discussion sur la raison pour laquelle Pick est utilisé au lieu de Partial ? Cela m'a causé des heures de chagrin (en utilisant tout simplement setState(obj) , pas la version de rappel), et pour l'instant je vais avec this.setState(newState as State) comme solution de contournement. Je veux juste comprendre pourquoi ça a été changé, parce qu'il doit me manquer quelque chose.

Bonjour @ericanderson ,

J'ai un problème avec la dernière définition.

Mon cas d'utilisation est brièvement comme ceci:

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
}

Le message d'erreur est comme :

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

Il semble que Partial<AppState> ne soit pas compatible avec la signature de setState . Bien sûr, je peux résoudre ce problème par une assertion de type comme

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

mais ce n'est pas idéal, car :
1) cette syntaxe est très verbeuse
2) plus important encore, l'assertion de type pourrait violer mes données réelles. Par exemple, newState as Pick<AppState, 'somethingElse'> réussit également le contrôle, bien qu'il ne corresponde pas à mes données.

je pense que partieldevrait en quelque sorte compatible avec Pick, depuis Partiellechoisit juste un nombre incertain de clés de T. Je ne suis pas sûr que ma compréhension soit exacte. Quoi qu'il en soit l'utilisation idéale de mon point de vue devrait être que je puisse passer la variable typée Partialdirectement dans setState.

Pourriez-vous avoir l'amabilité d'examiner ma suggestion ou de signaler mon malentendu s'il y a lieu ? Merci!

C'est un très vieux changement tout d'abord. Donc, à moins que quelqu'un d'autre n'ait récemment changé cela, vous vous trompez probablement d'arbre.

Cela dit. Partial autorise des valeurs indéfinies.

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

a est valide mais il est clair que le résultat de cette mise à jour de votre état met votre état avec foo indéfini même si vous avez déclaré que c'est impossible.

Par conséquent, un partiel n'est pas assignable à un Pick. Et Pick est la bonne réponse pour s'assurer que vos types ne mentent pas

J'ai l'impression que ne pas permettre :

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

est hyper restrictif.

La solution de contournement de @Kovensky est la seule solution de contournement sensée que je connaisse, mais toujours pénible à écrire.

Y a-t-il quelque chose qui puisse être fait pour soutenir ce modèle (je dirais) assez courant ?

La seule chose à faire est de supprimer typesafety

Quelqu'un peut-il expliquer le raisonnement pour 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, je ne sais même pas pourquoi la signature ci-dessus fonctionne même pour les mises à jour d'état partielles car K est défini comme keyof S donc Pick<S, K> recrée essentiellement S ?

Partial<S> | null ne devrait-il pas faire le travail aussi ?

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

Quelqu'un peut-il expliquer...

Il a été expliqué clairement quelques réponses.

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

est hyper restrictif.

La solution de contournement de @Kovensky est la seule solution de contournement sensée que je connaisse, mais toujours pénible à écrire.

Je viens de rencontrer ce problème exact, mais je ne vois aucune référence à Kovensky dans le fil (peut-être que quelqu'un a changé son nom d'utilisateur ?). Quelqu'un peut-il m'indiquer la solution de contournement actuellement recommandée

@ timrobinson33 Ce commentaire explique la solution de contournement https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment -351884578

Et c'est une bonne chose que nous n'ayons plus à nous soucier de ça avec des crochets 🙂

@ timrobinson33 Ce commentaire explique la solution de contournement #18365 (commentaire)

Merci beaucoup pour cela. En fin de compte, je pensais que mon code avait l'air plus agréable que plusieurs petits appels setState avec des instructions If dehors d'eux, même si cela signifie que certains chemins appelleront setState plus d'une fois.

Je suppose que c'est en fait similaire à la façon dont nous travaillons avec les crochets, considérant l'état comme plusieurs petites choses que nous mettons à jour indépendamment.