그 흥미 롭군요. 변경 사항의 일부를 롤백하고 일부를 선택하게 되어 기쁩니다.

나는 당신이 보고한 것이 TS의 버그처럼 들린다고 말할 것입니다. 구체적으로:

유형 '{ baseProp: "foobar"; }'은(는) 'Partial' 유형에 할당할 수 없습니다.

괜찮은. S와 baseProp 사이에 관계가 없기 때문에 TS가 무슨 일이 일어나고 있는지 모를 수도 있습니다.

{ baseProp:number } 유형인 S를 전달할

아마도 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\ ) 유형의 매개변수에 할당할 수 없습니다 (픽 &...'.유형 '{ baseProp: "foobar";
}'은(는) 'Partial\ ' 유형에 할당할 수 없습니다

아마도 그것을 구조화하는 좋은 방법이 아닐 것입니다. 결국 일부 자식 클래스는 기본 클래스의 변수와 충돌하는 상태 변수를 선언할 수 있습니다. 따라서 typescript는 그곳에서 무슨 일이 일어날지 확신할 수 없다고 불평하는 것이 옳을 수 있습니다. 그래도 해당 소품에 액세스하는 데 문제가 없다는 것이 이상합니다.

흠. 이것은 확실히 TS의 버그처럼 느껴집니다.

나는 오늘 이것을 가지고 놀 것이고 아마도 & Partial을 꺼낼 것입니다.

나는 이것을 테스트 케이스로 추가하고 intellisense를 행복하게 만들기 위해 다른 아이디어를 시도 할 것입니다.

안녕하세요,
여기서도 같은 문제...

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://gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

행동이 여전히 이상해 보이지만. 특히 기본 클래스로 유형이 지정된 변수에 캐스트 없이 할당한 다음 문제 없이 동일한 호출을 수행할 수 있습니다. 이 문제 는 할당과 비교가 두 가지 다른

잊지 않으셨습니다. 곧 수정됩니다

참조된 PR이 이 문제를 해결해야 합니다. 나는 또한 이 엣지 케이스를 다시 깨지 않도록 보호해야 하는 테스트를 추가했습니다.

@ericanderson 빠른 답변 감사합니다 :)

새로운 수정 사항에 제한/단점이 있습니까?

내가 현재 알고 있는 것은 없습니다. 나는 Intellisense를 유지할 수 있었습니다(일부 극단적인 경우를 해결하기 때문에 실제로 이전보다 낫습니다).

자세히 설명하자면 & Partial<S> 솔루션은 가능한 매개변수를 나타내도록 intellisense를 속이는 것이지만 X | undefined 라고 명시함으로써 그렇게 했습니다. 이것은 물론 컴파일에 실패하지만 약간 혼란스러웠습니다. | S 얻으면 intellisense가 수정되어 모든 올바른 매개변수를 제안하고 이제 잘못된 유형을 표시하지 않습니다.

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가 정의되지 않았거나 nullable이 아니더라도 null 어설션 연산자를 사용해야 합니다.

유형 감지가 개선될 때까지 이전 유형 정의를 유지하겠습니다. 그동안 immer 제품의 일반 매개변수에 대한 유형을 명시적으로 설명하겠습니다. 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 유형 정의가 상태의 올바른 유형을 감지할 방법이 없습니다. 따라서 초안에 대한 Intellisense가 나타나지 않습니다.

아니면 컴파일러에서 잘못된 기대를 하고 있을지도 모릅니다. 컴파일러가 내부에서 코드를 처리하기 때문에 컴파일러는 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에는 ConfirmlyTyped의 테스트 스크립트에 오류가 있습니다. 로컬에서 테스트하지 않았습니다. 그래서 지금 로컬에서 테스트 중입니다.

침수/생산 유형 정의는 다음과 같습니다.

/**
 * 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'> 도 내 데이터에 맞지는 않지만 검사를 통과합니다.

내 생각에 부분적어떻게든 Pick과 호환되어야 합니다., 부분 이후T에서 불확실한 수의 키를 선택합니다. 정확한지 내 이해가 확실하지 않습니다. 어쨌든 내 관점에서 이상적인 사용법은 Partial 유형의 변수를 전달할 수 있다는 것입니다.setState에 직접.

내 제안을 친절하게 고려하거나 내 오해가 있다면 지적해 주시겠습니까? 감사합니다!

이것은 처음부터 정말 오래된 변경 사항입니다. 따라서 다른 사람이 최근에 이것을 변경하지 않는 한 아마도 잘못된 나무를 짖고 있을 것입니다.

그렇게 말했다. 부분은 정의되지 않은 값을 허용합니다.

const a : 부분<{foo: string}> = { foo: 정의되지 않음 }

유효하지만 분명히 상태 업데이트의 결과는 불가능하다고 선언했음에도 불구하고 foo가 정의되지 않은 상태를 넣습니다.

따라서 부분은 Pick에 할당할 수 없습니다. 그리고 Pick은 당신의 타입이 거짓말을 하지 않도록 하는 정답입니다.

다음을 허용하지 않는다고 생각합니다.

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

매우 제한적입니다.

@Kovensky 의 해결 방법은 내가 아는 유일한 합리적인 해결 방법이지만 여전히 쓰기가

상당히 일반적인 패턴을 지원하기 위해 할 수 있는 일이 있습니까?

할 수 있는 유일한 것은 typesafety를 제거하는 것입니다.

누군가 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(댓글)

감사합니다. 결국 내 코드가 If 문이 외부에 있는 몇 개의 작은 setState 호출로 더 멋져 보인다고 생각했습니다. 비록 이것이 일부 경로가 setState를 두 번 이상 호출한다는 것을 의미하긴 하지만요.

나는 이것이 우리가 독립적으로 업데이트하는 몇 가지 작은 것으로 상태를 보는 우리가 후크를 사용하는 방법과 실제로 유사하다고 생각합니다.