それは面白い。 変更の一部をロールバックして、一部を選択できます。

私はあなたが報告することはTSのバグのように聞こえると言います、具体的には：

タイプ '{baseProp： "foobar"; } 'はタイプ' Partialに割り当てることができません

大丈夫。 SとbasePropの間に関係がないため、TSは何が起きているのかわからないかもしれません。

タイプ{ baseProp：number }のSを渡すことができます。その場合、basePropに文字列を割り当てることはできません。

おそらく、SがbasePropバージョンを拡張した場合はどうでしょうか。

私は以前にこのようなことを試しました：

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

アクセスは正常ですが、setState呼び出しにも同じエラーがあります。

タイプの引数 '{baseProp： "foobar"; } 'はタイプ'のパラメータに割り当てることができません（（prevState：Readonly \ 、props：P）=> Pick ＆Partial \ ）|
} 'はタイプ' Pick ＆Partial \ 'に割り当てることはできませんタイプ '{baseProp： "foobar";

それを構造化するのはおそらく良い方法ではありません-結局のところ、一部の子クラスは、基本クラスの変数と衝突した状態変数を宣言する可能性があります。 したがって、typescriptは、そこで何が起こるかわからないと不平を言うのが正しいかもしれません。 しかし、それらの小道具にアクセスすることに問題がないのは奇妙です。

うーん。 これは間違いなくTSのバグのように感じます。

今日はこれで遊んで、おそらく＆Partialを取り出します。

これもテストケースとして追加し、インテリセンスを幸せにするための別のアイデアを試してみます

やあ、
ここで同じ問題...

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

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

この変更後、エラーが発生し始めました。 バージョン16.0.10では正常に動作しました。

Typescriptにはいくつかの関連する問題があり、設計どおりに機能するようにそれらを閉じました。

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

ここでいくつかの例の要点を作成しました： https ：

動作はまだ奇妙に見えますが。 特に、キャストなしで基本クラスとして型指定された変数に割り当てて、問題なく同じ呼び出しを行うことができます。 この問題は、割り当てと比較が2つの異なるものであることを示唆しているようです。

あなたたちを忘れていません。 すぐに修正されます

参照されたPRはこの問題を解決するはずです。 また、このエッジケースを再び壊さないように保護するテストを追加しました。

@ericanderson迅速な対応に感謝します:)

新しい修正には制限/欠点がありますか？

私が現在知っているものはありません。 インテリセンスを維持することができました（いくつかのエッジケースを解決するため、実際には以前よりも優れています）。

詳述すると、 & Partial<S>解決策は、インテリセンスをだまして可能なパラメータを明らかにすることでしたが、それはX | undefinedと述べることによって行われました。 もちろんこれはコンパイルに失敗しますが、少し混乱しました。 | S取得すると、インテリセンスが修正され、すべての正しいパラメーターが提案され、誤ったタイプが表示されなくなります。

setStateコールバックからの可能な戻り値としてnullを追加することを検討しました（ return;を作成せずに、状態を変更したくない状態に戻すことができるものまた有効です）が、代わりに型推論を完全に放棄し、キーとしてneverました😢

今のところ、実際に状態の更新をスキップしたいコールバックでは、 return null!ます。 この戻り値のnever型により、TypeScriptはジェネリック型推論の戻り値を無視します。

こんにちは、みんな...

最後のコミットで問題が修正されました。
迅速な返答に感謝致します ：）

どのバージョンで修正されていますか？ npmに公開されていますか？ @UselessPicklesが見つかったように、setStateのコールバックバージョンが戻り値にプロパティの不一致があると言っている場合があります。

最新の@types / reactで良いはずです

15シリーズと16シリーズで修正しました

import produce from 'immer';

interface IComponentState
{
    numberList: number[];
}

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

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;

..このエラーが発生します：

私はこの提案を試しました：

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は、Reactの状態からプロパティを検出できるようになりました。 ただし、検出されたプロパティはpossibly undefinedとして認識されるようになりました。

numberListが未定義でもnull許容でもない場合でも、nullアサーション演算子を使用する必要があります。

タイプセンシングが改善されるまで、古いタイプ定義のままにしておきます。 それまでの間、イマープロデュースのジェネリックパラメーターのタイプを明示的に説明します。 produce<IComponentState>は、 list!よりも推論が簡単です。

最初のエラーは、何も返さないためです。 それはsetStateがどのように機能するかではありません。

農産物で変数を返さない場合でも機能します。 私はここの例（TypeScript以外）に従いました：

https://github.com/mweststrate/immer

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

TypeScriptがそのコードを実行できないようにする唯一のことは、React型定義から誤って型が推測されていることです。 タイプ定義はnumberList does not exist on type Pick<IComponentState, never>エラーを報告します。 生成物のジェネリックパラメーター、つまりproduce<IComponentState>型を明示的に渡すことで、コンパイルエラーをなくすことができます。

農産物で変数を返して、React型定義が型を推測するのに役立つかどうかを確認しようとしましたが（ひよこと卵の問題です）、それでもReact型定義が状態の正しい型を検出する方法はありません。 したがって、ドラフトのインテリセンスは表示されません。

あるいは、コンパイラからの期待が間違っているかもしれません:)コンパイラはコードを裏返しに処理するため、setStateの型に基づいてドラフト変数の型を作成できません。 しかし、提案された型定義は、コンパイラが外部からコードを処理でき、外部コード（ setState ）から内部コード（ 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;

上記の型定義を使用すると、コンパイラはドラフトにnumberListプロパティがあることを検出できます。 ただし、 possibly undefinedとして検出されます。

さらにいじくり回すと、setStateの型定義にSを追加することで、コンパイラが状態の型を渡してドラフトを生成できるようにしました。

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;

コードは現在コンパイル中です:)

エラーはsetStateではなく、農産物の内部にあります。 農産物のタイプ定義は何ですか？

上記の私のPRは、DefinitelyTypedのテストスクリプトでエラーが発生しました。ローカルでテストしませんでした。 だから私は今それをローカルでテストしています。

これがイマー/プロデュースタイプの定義です。

/**
 * 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がPartial代わりにPickが使用される理由についての議論を教えていただけますか？ これは私に何時間もの悲しみを引き起こしました（コールバックバージョンではなく、プレーンなsetState(obj)を使用します）、そして今のところ私は回避策としてthis.setState(newState as State)を使用します。 何かが足りないので、なぜ変更されたのかを理解したいだけです。

こんにちは@ericanderson 、

最新の定義に問題があります。

私のユースケースは簡単に次のようになります。

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
}

エラーメッセージは次のようなものです。

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

Partial<AppState>はsetState署名と互換性がないようです。 もちろん、私は次のようなタイプアサーションによってこれを解決できます

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

しかし、それは理想的ではありません。理由は次のとおりです。
1）この構文は非常に冗長です
2）さらに重要なことに、型アサーションは私の実際のデータに違反する可能性があります。 たとえば、 newState as Pick<AppState, 'somethingElse'>もチェックに合格しますが、私のデータには適合しません。

部分的だと思いますどういうわけかピックと互換性があるはずです、部分的なのでTから不確かな数のキーを選択するだけです。正確かどうかはわかりません。 とにかく、私の観点からの理想的な使用法は、Partial型の変数を渡すことができるということです。setStateに直接。

私の提案を検討したり、誤解がある場合は指摘していただけませんか。 ありがとうございました！

これは最初は本当に古い変更です。 したがって、他の誰かが最近これを変更しない限り、おそらく間違った木を吠えているでしょう。

そうは言った。 部分的には未定義の値を許可します。

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

aは有効ですが、明らかに、状態を更新した結果、不可能であると宣言した場合でも、fooが未定義の状態になります。

したがって、パーシャルをピックに割り当てることはできません。 そして、ピックはあなたのタイプが嘘をつかないようにするための正しい答えです

私はそれを許さないと感じています：

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

超制限的です。

@Kovenskyの回避策は、私が知っている唯一の賢明な回避策ですが、それでも書くのは苦痛です。

この（私が言うだろう）かなり一般的なパターンをサポートするためにできることはありますか？

できる唯一のことは、型安全性を取り除くことです

誰かが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 Kがkeyof Sとして定義されているので、上記の署名が部分的な状態の更新でも機能する理由は今でもわかりません。したがって、 Pick<S, K>基本的にS再作成しますか？

Partial<S> | nullもその仕事をするべきではありませんか？

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

誰かが説明できますか...

いくつかの回答が明確に説明されています。

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

超制限的です。

@Kovenskyの回避策は、私が知っている唯一の賢明な回避策ですが、それでも書くのは苦痛です。

この正確な問題が発生したばかりですが、スレッドにKovenskyへの参照が表示されません（誰かがユーザー名を変更した可能性がありますか？）。 誰かが私に現在推奨されている回避策を教えてもらえますか

@ timrobinson33このコメントは、回避策を説明していますhttps://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment -351884578

そして、フックでこれについてもう心配する必要がないのは良いことです🙂

@ timrobinson33このコメントは回避策を説明しています＃18365（コメント）

どうもありがとうございました。 結局、いくつかのパスがsetStateを複数回呼び出すことを意味しますが、 Ifステートメントが外部にあるいくつかの小さなsetState呼び出しとして、私のコードは見栄えが良いと思いました。

これは実際にはフックの操作方法と似ていると思います。状態は、個別に更新するいくつかの小さなものと見なされます。