Das ist interessant. Ich freue mich, den Teil der Änderung rückgängig zu machen und einen Teil der Änderung auszuwählen

Ich werde sagen, dass das, was Sie melden, sich wie ein Fehler in TS anhört, insbesondere:

Geben Sie '{ baseProp: "foobar" ein; }' ist nicht dem Typ 'Partial zuweisbar

In Ordung. Vielleicht kann TS nicht wissen, was los ist, weil keine Beziehung zwischen S und baseProp besteht.

Man könnte ein S vom Typ { baseProp:number } übergeben. In diesem Fall ist es richtig, dass Sie baseProp keinen String zuweisen können.

Vielleicht, wenn S die baseProp-Version erweitert?

Ich hatte sowas schon mal probiert:

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

während der Zugriff in Ordnung ist, hat der setState-Aufruf den gleichen Fehler:

Argument vom Typ '{ baseProp: "foobar"; }' ist dem Parameter vom Typ '((prevState: Readonly\ , props: P) => Pick & Partial\ ) |
}' ist nicht dem Typ 'Pick & Partial\ ' zuweisbar Geben Sie '{ baseProp: "foobar" ein;

Es ist wahrscheinlich keine gute Möglichkeit, es zu strukturieren - schließlich könnten einige untergeordnete Klassen Zustandsvariablen deklarieren, die mit Variablen der Basisklasse kollidiert sind. Typoskript könnte also richtig sein, sich zu beschweren, dass es nicht sicher sein kann, was dort passieren wird. Es ist seltsam, dass es kein Problem mit dem Zugriff auf diese Requisiten hat.

Hmm. Das fühlt sich jetzt definitiv wie ein Fehler in TS an.

Ich werde heute damit spielen und eventuell das & Partial rausnehmen.

Ich werde dies auch als Testfall hinzufügen und eine andere Idee ausprobieren, um Intellisense glücklich zu machen

Hi,
Selbes Problem hier...

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

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

Der Fehler trat erst nach dieser Änderung auf. In Version 16.0.10 hat es gut funktioniert.

Typescript hat mehrere verwandte Probleme, sie haben sie so geschlossen, dass sie wie geplant funktionieren:

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

Ich habe hier einige Beispiele zusammengefasst: https://gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

Obwohl das Verhalten immer noch seltsam erscheint. Insbesondere können Sie eine Variable, die als Basisklasse typisiert ist, ohne Umwandlung zuweisen und dann problemlos die gleichen Aufrufe damit durchführen. Dieses Problem scheint darauf hinzudeuten, dass Zuordnung und Vergleich zwei verschiedene Dinge sind.

Hab euch nicht vergessen. Wird bald behoben

Die referenzierte PR sollte dieses Problem lösen. Ich habe auch Tests hinzugefügt, die davor schützen sollen, dieses Edge-Case erneut zu brechen.

@ericanderson Danke für die schnelle Antwort :)

Hat der neue Fix irgendwelche Einschränkungen/Nachteile?

Keine die mir derzeit bekannt sind. Ich konnte Intellisense beibehalten (eigentlich besser als zuvor, da es einige Randfälle löst).

Um das auszuarbeiten, die & Partial<S> Lösung bestand darin, Intellisense auszutricksen, um mögliche Parameter aufzudecken, aber es tat dies, indem sie angab, dass sie X | undefined . Dies würde natürlich nicht kompilieren, aber es war ein bisschen verwirrend. Das Abrufen von | S behebt den Intellisense, so dass er alle richtigen Parameter vorschlägt und jetzt keinen falschen Typ anzeigt.

Ich habe versucht, null als möglichen Rückgabewert aus dem setState Rückruf hinzuzufügen (was Sie in den Zustand zurückgeben können, den Sie nicht ändern möchten, ohne dass return; auch gültig), aber das führte stattdessen dazu, dass die Typinferenz einfach komplett aufgegeben wurde und never als Schlüssel ausgewählt wurde 😢

Im Moment habe ich in den Rückrufen, bei denen ich die Aktualisierung des Status überspringen möchte, return null! . Der never Typ dieser Rückgabe bewirkt, dass TypeScript die Rückgabe für den generischen Typrückschluss ignoriert.

Hallo Leute...

Der letzte Commit hat mein Problem behoben.
Danke für die schnelle Antwort :)

Welche Version hat den Fix? Wird es auf npm veröffentlicht? Ich treffe auf den Fall, in dem die Rückrufversion von setState mir mitteilt, dass der Rückgabewert nicht übereinstimmt, genau wie @UselessPickles gefunden wurde.

Sollte auf den neuesten @types/react gut sein

Ich habe es für die 15er und 16er Serie behoben

import produce from 'immer';

interface IComponentState
{
    numberList: number[];
}

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

Die alte Typdefinition des 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;

..produziert diesen Fehler:

Ich habe diesen Vorschlag ausprobiert:

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 kann nun das Eigentum aus dem Zustand von React erkennen. Die erfasste Eigenschaft wird jedoch jetzt als possibly undefined wahrgenommen.

Ich müsste den NULL-Assertion-Operator verwenden, obwohl numberList weder undefiniert noch NULL-fähig ist:

Ich bleibe einfach bei der alten Typdefinition, bis die Typerkennung verbessert ist. In der Zwischenzeit werde ich nur den Typ des generischen Parameters von immer produzieren explizit angeben. produce<IComponentState> ist einfacher zu begründen als list! .

Ihr erster Fehler ist, dass Sie nichts zurückgeben. So funktioniert setState nicht.

Es funktioniert auch, wenn keine Variable in product zurückgegeben wird. Ich bin einfach dem Beispiel hier gefolgt (Nicht-TypeScript):

https://github.com/mweststrate/immer

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

Das einzige, was TypeScript daran hindert, diesen Code auszuführen, ist der falsch abgeleitete Typ aus der React-Typdefinition. Die Typdefinition meldet einen Fehler von numberList does not exist on type Pick<IComponentState, never> . Der Kompilierungsfehler kann einfach behoben werden, indem der Typ explizit an den generischen Parameter von product übergeben wird, dh produce<IComponentState> .

Ich habe sogar versucht, die Variable in product zurückzugeben und zu sehen, ob dies der React-Typdefinition helfen würde, den Typ abzuleiten (allerdings ein Küken-und-Ei-Problem), aber immer noch gibt es für die React-Typdefinition keine Möglichkeit, den richtigen Typ des Zustands zu erkennen. Daher erscheint der Intellisense für Draft nicht:

Oder vielleicht habe ich eine falsche Erwartung vom Compiler :) Der Compiler kann keinen Typ für die Entwurfsvariable basierend auf dem Typ von setState erstellen, da der Compiler den Code von innen nach außen verarbeitet. Die vorgeschlagene Typdefinition ließ mich jedoch irgendwie glauben, dass der Compiler den Code von außen nach innen verarbeiten kann, dass er den besten Typ auswählen kann, den er vom äußeren Code ( setState ) an den inneren Code ( 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;

Mit der obigen Typdefinition kann der Compiler erkennen, dass Draft eine numberList Eigenschaft hat. Es erkennt es jedoch als possibly undefined :

Nach weiteren Basteleien habe ich den Compiler in die Lage versetzt, den Typ des Zustands an den Entwurf von Produzieren zu übergeben, indem ich S zur Typdefinition von setState hinzugefügt habe:

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;

Der Code wird jetzt kompiliert :)

Ihr Fehler liegt nicht bei setState, Ihr Fehler liegt in product. Was ist Ihre Typdefinition für Produkte?

Meine obige PR hat einen Fehler im Testskript von DefinitelyTyped, ich habe es nicht lokal getestet. Also teste ich es jetzt lokal.

Hier ist die Definition des Immer/Produzieren-Typs.

/**
 * 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 könnten Sie mich bitte auf die Diskussion darüber hinweisen, warum Pick anstelle von Partial ? Dies hat mir stundenlangen Kummer bereitet (mit einfachem setState(obj) , nicht der Rückrufversion), und im Moment gehe ich mit this.setState(newState as State) als Workaround vor. Ich möchte nur verstehen, warum es geändert wurde, weil mir etwas fehlt.

Hallo @ericanderson ,

Ich habe ein Problem mit der neuesten Definition.

Mein Anwendungsfall sieht kurz wie folgt aus:

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
}

Die Fehlermeldung lautet wie folgt:

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

Es scheint, dass Partial<AppState> nicht mit der Signatur von setState kompatibel ist. Natürlich kann ich dies durch Typ-Assertion lösen wie

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

aber es ist nicht ideal, denn:
1) diese Syntax ist sehr ausführlich
2) Noch wichtiger ist, dass die Typzusicherung meine tatsächlichen Daten verletzen könnte. newState as Pick<AppState, 'somethingElse'> auch die Prüfung, obwohl sie nicht zu meinen Daten passt.

Ich denke teilweisesollte irgendwie mit Pick kompatibel sein, da teilweisewählt nur eine unsichere Anzahl von Schlüsseln von T. Ich bin mir nicht sicher, ob mein Verständnis richtig ist. Wie auch immer, die ideale Verwendung aus meiner Sicht sollte sein, dass ich die Variable mit dem Typ Partial übergeben kanndirekt in setState.

Könnten Sie freundlicherweise meinen Vorschlag berücksichtigen oder auf mein Missverständnis hinweisen, falls vorhanden? Dankeschön!

Dies ist zunächst einmal eine wirklich alte Änderung. Wenn dies nicht kürzlich von jemand anderem geändert wurde, bellen Sie wahrscheinlich den falschen Baum an.

Das gesagt. Teilweise erlaubt undefinierte Werte.

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

a ist gültig, aber das Ergebnis dieser Aktualisierung Ihres Bundesstaates führt dazu, dass Ihr Bundesstaat mit foo undefiniert ist, obwohl Sie dies für unmöglich erklärt haben.

Daher ist ein Partial nicht einem Pick zuordenbar. Und Pick ist die richtige Antwort, um sicherzustellen, dass Ihre Typen nicht lügen

Ich habe das Gefühl, dass es nicht erlaubt ist:

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

ist super restriktiv.

Der Workaround von

Gibt es etwas, das getan werden kann, um dieses (ich würde sagen) ziemlich häufige Muster zu unterstützen?

Das einzige, was getan werden kann, ist die Typsicherheit zu entfernen

Kann jemand die Gründe für Pick<S, K> | S | null erklären?

        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 ich weiß nicht einmal, warum die obige Signatur sogar für teilweise Statusaktualisierungen funktioniert, da K als keyof S also Pick<S, K> Wesentlichen S ?

sollte Partial<S> | null den Job nicht auch machen?

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

Kann jemand erklären...

Es wurde ein paar Antworten klar erklärt.

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

ist super restriktiv.

Der Workaround von

Ich bin gerade auf genau dieses Problem gestoßen, kann aber im Thread keinen Hinweis auf Kovensky sehen (vielleicht hat jemand seinen Benutzernamen geändert?). Kann mir jemand den aktuell empfohlenen Workaround nennen?

@timrobinson33 Dieser Kommentar erklärt die Problemumgehung https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment -351884578

Und gut, dass wir uns darüber mit Haken keine Gedanken mehr machen müssen 🙂

@timrobinson33 Dieser Kommentar erklärt die Problemumgehung #18365 (Kommentar)

Vielen Dank dafür. Am Ende fand ich, dass mein Code schöner aussah als mehrere kleine setState-Aufrufe mit If Anweisungen außerhalb davon, obwohl dies bedeutet, dass einige Pfade setState mehr als einmal aufrufen.

Ich denke, dies ist tatsächlich ähnlich wie wir mit Hooks arbeiten, da wir den Zustand als mehrere kleine Dinge betrachten, die wir unabhängig voneinander aktualisieren.