Visual Studio는 어떤 버전의 typescript를 사용하고 있습니까?

@vsaio for sa

문제 1의 경우 TS 2.1.5 및 최신 VSCode를 사용하면 이 방법이 잘 작동합니다. 나는 windows/VS가 없어서 거기에서 확인할 수 없지만 플러그인에 대한 업데이트가 있거나 TS 2.1.5에 있지 않을 것입니다.

문제 2와 동일

VS 2015(TS 2.1.5.0 포함)

문제 3은 논쟁의 여지가 있는 것 같습니다.

React에서 위의 예를 _기술적으로_ 할 수 있다는 것은 옳지만, 나는 그것이 React가 사용되도록 의도된 방식이 아니라고 확실히 주장하고 싶습니다.

이것은 3가지 별개의 경우로 나눌 수 있습니다.

일반 초기화

interface State {
  bar: number;
}

interface Props {
  baz: number;
}

class Foo extends React.Component<Props, State> {
  public state: State = {
    bar: 5,
  };
}

props 기반 초기화

interface State {
  bar: number;
}

interface Props {
  baz: number;
}

class Foo extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = {
      bar: props.baz,
    };

    // or
    this.setState({
      bar: props.baz,
    });
  }
}

forceUpdate 로 무작위 할당

사람들을 "올바른" 방향으로 밀어붙이는 것이 더 낫다고 생각하면 public state 를 다시 선언하여 이 문제를 쉽게 해결할 수 있습니다.

interface State {
  bar: number;
}

class Foo extends React.Component<{}, State> {
  public state: State;
  public myMethod() {
    this.state.bar = 5;
  }
}

내 문제는 제네릭 분산에 있습니다. 특히 일반적으로 입력되는 클래스 내에서 입력하기 위한 것입니다. 아래는 문제가 발생한 곳의 아주 최소한의 샘플입니다.

class TBaseState {
  public value: string;
}

function globalFunc<T extends Readonly<TBaseState>>(item: T) {
}

class MyComponent<TProps, TState extends TBaseState> extends React.Component<TProps, TState> {
  broken() {
    // typing of this.state is Readonly<TState>
    // this is not assignable to Readonly<TBase>
    globalFunc(this.state);

    // this is a horrible hack to fix the generics variance issue
    globalFunc(this.state as TState as Readonly<TBaseState>);
  }
}

class MyState extends TBaseState {
}

let component: MyComponent<any, MyState>;

// here the typing of component.state is Readonly<MyState>
// this is assignable to Readonly<TBase>
globalFunc(component.state);

나는 TS 2.1.5.0에있다

그러나 VS에서 VS 코드보다 최악의 TS 경험이 있을 수 있습니다...

문제 1의 경우 정의로 이동 TS는 VS 코드에서도 작동하지 않습니다.

interface MyComponentProps {
    name: string;
}

export abstract class MyComponent extends React.Component<MyComponentProps , void> {
    fullName: string;
    myMethood() {
       this.props.name; //<-- doesnt work
       this.fullName; //<-- works
   }
}

문제 2의 경우 VS Code가 더 잘 작동한다는 것은 사실입니다.

VS가 혼란스러워 보이는 동안:

VSCode 및 문제 1의 경우 더 똑똑한 처리가 필요한 "최신 Typescript 및 Javascript 문법"용 플러그인을 사용하고 있기 때문에 작동한다고 생각합니다.

@patsissons 흥미로운 예지만 정의 파일의 버그보다 typescript의 버그를 더 잘 대표한다고 생각합니다. 예를 들어, setState 는 S 를 취하는 데 사용되었습니다. 이는 우리가 setState({foo:5} as any as State) 와 같은 이상한 트릭을 수행하거나 함수를 사용하는 것을 사용해야 하는 부분을 수행하는 것을 의미했습니다. 컴파일러의 표현력 부족으로 인해 입력이 "잘못"되는지 잘 모르겠습니다. 나는 이것이 이 극단적인 경우를 표시하기 위해 README를 변경하는 것에 대한 적절한 주장이라고 생각합니다.

TS에 문제를 제출하셨습니까?

따라서 이 변경 사항은 요즘 모든 VS를 중단하고 플러그인이 있는 경우를 제외하고 모든 VS 코드에서 정의로 이동을 비활성화합니다...

또한 완전성 주장이 있습니다. 읽기 전용으로 의도된 API가 수십억 개 있으며 요즘에는 그렇지 않습니다. 단지 React.d.ts에만 있습니다.

 interface ComponentLifecycle<P, S> {
        componentWillMount?(): void;
        componentDidMount?(): void;
        componentWillReceiveProps?(nextProps: Readonly<P>, nextContext: any): void;
        shouldComponentUpdate?(nextProps: Readonly<P>, nextState: Readonly<S>, nextContext: Readonly<any>): boolean;
        componentWillUpdate?(nextProps: Readonly<P>, nextState: Readonly<S>, nextContext: Readonly<any>): void;
        componentDidUpdate?(prevProps: Readonly<P>, prevState: Readonly<S>, prevContext: Readonly<any>): void;
        componentWillUnmount?(): void;
    }

예를 들어 이벤트 개체와 같이 수정되지 않는 긴 꼬리가 아닌 '고정' 또는 'Inmmutable.js'에 readonly를 사용해야 한다고 생각합니다.

제출하지 않았습니다. 저는 오늘 새로운 Readonly<T> 유형을 처리하기 위해 코드를 개조하고 있습니다. 이것은 제대로 입력된 솔루션이 없는 경우였습니다. 계속해서 문제를 제기하세요. 저는 오늘 하루 중 대부분의 시간을 코드 패치로 바쁠 것입니다.

아 예, 제가 놓친 부분이 있다는 것을 알고 있었습니다. @olmobrutall 읽기 전용으로 표시하기 위해 도입한 상태 변경 사항을 유지한다면 해당 메서드를 업데이트해야 한다는 데 동의합니다. 하지만 먼저 해야 할 옳은 일에 대한 합의가 필요하다고 생각합니다.

VS 브레이크에 관해서는 무엇이 옳은지 모르겠습니다. 일부 도구가 최신 상태로 유지되지 않기 때문에 유형을 보류해야 합니까?

@patsisson 모든 코드를 업데이트하기 전에 이것이 어떻게 진행되는지 보고 싶다면 지금 당장은 반응에 대한 자신만의 타이핑을 제공할 수 있습니다. https://ericlanderson.com/using-custom-typescript-definitions-with-ts-2-x-3121db84015d#.ftlkojwnb

우리의 경험에 따르면 VS는 항상 약간 뒤쳐져 있습니다. 우리 가게는 활성 타입스크립트 개발을 수행하기 위해 vscode를 사용하며, VS는 단순히 코드 파일을 패치하거나 타입스크립트가 아닌 개발자가 코드를 살펴보는 데 더 많이 사용됩니다.

@ericanderson 지금 은 해킹 이 그렇게 나쁘지 않습니다. Readonly<Base> T $ 를 얻으려면 Readonly<T> 를 얻어야 합니다.

우리는 'react.d.ts'에 대해 이야기하고 있습니다. 이 단일 멤버 선언은 많이 사용됩니다. VS가 준비될 때까지 보류할 가치가 있다고 생각합니다.

또한 전 세계 유형의 50%가 API에서 가져온 개체와 같이 읽기 전용이므로 주석을 달 필요가 없다고 생각합니다.

Get-only 속성을 갖도록 명시적으로 변환된 개체에는 Readonly를 사용해야 한다고 생각합니다. 동결처럼.

@olmobrutall Readonly 는 새로운 것이므로 정확한 모범 사례가 실제로 정의되지 않습니다. 저는 개인적으로 모든 것이 Readonly<> 를 변경하지 않는다는 것을 나타내는 데 도움이 된다고 선언하는 것을 선호합니다. 마찬가지로 React는 setState state 를 수정하는 것을 기대하지 않으므로 이 변경으로 인해 사고로 인해 버그가 발생하지 않습니다. 이는 자바스크립트보다 TypeScript를 사용하는 주요 이점 중 하나입니다.

Object.freeze 에 대해 브라우저 간에 성능이 더 일관적이었다면 React 사람들이 setState 이후에 실제로 멈추기 시작할 것이라고 상상할 수 있습니다.

forceUpdate의 목적은 무엇입니까?

나는 도구 업데이트와 관련하여 확실히 유형이 어떻게 작동해야 하는지에 대한 다른 사람들의 생각과 반응에 대한 읽기 전용에 대한 철학(및 특정 개체를 수정하지 않는다는 의도를 가진 다른 라이브러리)에 대한 다른 사람들의 생각이 궁금합니다.

cc/ @johnnyreilly @vsaio @pspeter3 반응에 대한 생각과 일반적인 다른 생각
cc/ @andy-ms @mhegazy 는 툴링 업데이트와 Readonly 의 열성적인 사용을 위해 확실히 Typed가 어떻게 철학적으로 진행되어야 하는지에 대한 생각입니다.

@olmobrutall 우리는 forceUpdate 를 사용하여 상태 측의 관찰 가능한 이벤트에서 구동되는 반응 측의 렌더를 대기열에 넣습니다.

업데이트 :
오해가 없도록 시나리오를 조금 설명하겠습니다. 상태 개체는 오래 지속되는 불변 개체입니다(따라서 Readonly<T> 는 실제로 우리에게 매우 적합합니다). 이러한 상태 개체에는 stateChanged 라는 알림 관찰 가능 항목으로 유입되는 여러 rxjs 관찰 가능 스트림이 포함되어 있습니다. React 구성 요소는 이벤트에 대해 이 옵저버블을 관찰하고 해당 이벤트를 forceUpdate 에 대한 호출로 유입합니다(디바운싱 후). 사실상 우리의 변경 가능한 상태는 상태 내에 있지만 상태 자체와 상태에 존재하는 멤버는 모두 변경할 수 없습니다. 이것은 확실히 React의 표준 사용 사례는 아니지만 흐름이 매우 유사합니다. 재렌더링이 필요할 때 구성 요소에 알리는 방법을 알고 있는 스마트 상태 개체만 있으면 됩니다.

@ericanderson 주요 문제는 이러한 유형 정의가 SemVer 문제로 고통받고 있다는 것입니다. 유형 정의 버전은 해당 모듈 버전에 크게 연결되어 있기 때문에 유형 정의 변경을 일으키는 부 버전 범프가 발생합니다. 이는 @types 버전을 package.json 에 고정해야 함을 의미합니다. 파일.

@olmobrutall 반응 문서에서:

일반적으로 forceUpdate()의 모든 사용을 피하고 render()의 this.props 및 this.state만 읽어야 합니다.

반응 가이드는 사실 상태를 직접 업데이트하지 말라고 알려줍니다: https://facebook.github.io/react/docs/state-and-lifecycle.html#do -not-modify-state-directly

forceUpdate 는 내가 읽은 대로 구성 요소가 props 또는 state의 _not_ 데이터를 기반으로 할 때 구성 요소를 강제로 업데이트하기 위한 것입니다.

@patsisson 내가 틀릴 수도 있지만 SemVer가 API 및 의미론적 의도와 역호환되도록 설계되었다고 생각합니다. 의도하지 않은 방식으로 라이브러리를 사용한다고 해서(문서에 따라) 라이브러리가 의도하지 않은 사용을 계속 지원해야 한다는 의미는 아닙니다. 라이브러리 작성자는 SemVer 내에서 정확하지 않지만 일부 사람들이 사용하게 된 의미 체계를 변경할 수 있습니다.

즉, Readonly<> 에서 state 로 변경하는 것은 너무 큰 변경이지만 잠시 동안 올바른 변경이라고 가정합니다. 언제 확실히 Typed로 출시되어야 합니까? state 를 Readonly<> 로 표시하는 업데이트를 받으면 코드를 항상 변경해야 합니다.

나는 여전히 Readonly<> 가 state 에 적용되어 semver, tooling 또는 다른 것에 대해 토론하기 어렵게 만드는 것이 옳은지 모르겠습니다. 내 직감은 옳았다. 변경 사항을 검토한 사람들은 그것을 문제로 제기하지 않았습니다. React 팀의 의도와 일치하는 것 같습니다.

나는 확실히 Typed에 대한 반응에 대해 리뷰어들에게 맡길 수 있어 기쁩니다(위에서 모두 참조했습니다).

따라서 Observable은 강제 업데이트 상태를 변경합니까? 따라서 상태를 명령적으로 변경하는 것은 어느 정도 허용됩니다.

Readonly를 사용해야 하는 위치가 100% 정의되지 않는다는 것을 알았습니다. 그러나 도구가 준비되기 전에 논란의 여지가 많고 많이 사용되는 자산으로 시작해야 합니까?

저는 모두 강력한 형식을 사용하고 strictNullChecks가 있는 6개의 프로젝트를 모두 관리하지만 여기에서 얻는 이점은 현재 생성하는 문제보다 훨씬 적습니다.

@ericanderson 나는 SemVer2가 ^15.0.0 와 같은 노드 버전 선언을 허용하도록 설계되었으며 모듈에 대한 모든 마이너 또는 패치 업그레이드(예: 15.0.1 또는 15.1.0 )가 투명하거나 적어도 외부 관점에서 이전 버전과 호환됩니다. 모든 주요 업그레이드( 16.0.0 )는 변경 사항을 적용하기 위해 버전 선언을 조정해야 합니다. 이것은 본질적으로 주요 변경 사항이 타이핑 시스템으로 가져오는 것을 차단합니다. 그러나 현재 유형 정의 버전은 해당 모듈 버전(관례에 따라)에서 벗어날 수 없으므로 이러한 불연속성이 발생합니다.

짧은 버전은 유형 정의가 모듈 자체를 전혀 변경하지 않고도 도입된 주요 변경 사항을 가질 수 있으며 주요 변경 사항에는 주요 버전 범프가 필요하다는 것입니다.

하지만 PR을 제거하는 forceUpdate를 만들지는 않을 것입니다. 그렇죠?

그런 다음 forceUpdate가 있는 경우 상태를 반드시 변경해야 합니다.

이론상으로는 깊은 불변 상태 그래프를 사용해야 하지만 매우 자주 상태를 명령적으로 변경하는 것은 괜찮고 모든 개발자가 영구 데이터 구조 아이디어를 받아들이는 것은 아닙니다.

다행히 React는 스케이프 경로를 허용하고 상태를 직접 변경할 수 있습니다. TS 개발자가 해당 경로를 사용하는 것을 금지할까요? 너무 가부장적인거 아닙니까?

예를 들어 Vue.js는 명령적 변경을 촉진합니다. 그것이 React에 영향을 준다 해도 놀라지 않을 것입니다.

또한 나는 얼마 전에 모든 Redux 행사 없이 React 사용을 권장하는 React 작성자의 블로그 게시물을 읽고 있었습니다(기억할 수 있음).

그렇지 않으면 내 입장은 가능한 한 빨리 유형 정의를 게시하는 것입니다. 내 유일한 관심사는 자동화입니다. 유형 정의 버전 관리의 현재 상태가 주어지면 소스 변경 없이 연속 빌드가 중단될 수 있습니다. 이러한 유형의 비결정적 CI 실패는 문제가 됩니다. 변경 사항을 푸시한 다음 변경 사항이 빌드 중단과 관련이 없음을 알기 때문에 아무도 빌드 중단을 보고 싶어하지 않습니다.

자고 나서 개인적인 의견은 다음과 같습니다.

• 좋은 방법은 원사 또는 npm 잠금을 사용하는 것이므로 로컬에서 먼저 업그레이드하지 않는 한 놀라지 않을 것입니다.
• 상태를 읽기 전용으로 만드는 것은 React가 사용되는 방식입니다. 문서와 예제가 이를 확인합니다.
• setState를 사용하지 않으려는 워크플로는 코드 기반 및 고유 권한 내에 있습니다. React가 forceUpdate를 제공한다는 것은 맞지만 의도한 사용 사례를 벗어날 때 렌더링을 일으키기 위한 용도입니다. 따라서 의도한 대로 상태를 사용하고 싶지 않다면 괜찮지만 그 시점에서는 인스턴스 변수 상태를 사용할 필요가 없습니다. 실제로 일반 개인 변수를 사용할 수 있습니다.
• 예, 이 프로젝트는 많은 사람들에게 의존하고 있지만 지금까지 이것이 널리 퍼진 문제가 아니라고 생각하게 만드는 유일한 두 가지 불만 사항입니다. 또한 전역 함수에 대해 제기된 문제는 제네릭을 다르게 사용하도록 다시 작성할 수 있습니다(연결된 TypeScript 문제 참조).

위의 생각과 비표준 React 앱에 대한 해결 방법을 감안할 때 Readonly가 옳고 완전성을 위해 필요한 유일한 변경은 일치하도록 수명 주기 메서드를 업데이트하는 것입니다.

이러한 변경 사항이 완전히 의미가 있다는 점에 동의합니다. 문제를 일으킨 제 사용 사례는 거의 발생하지 않아야 하는 매우 독특한 코너 사례였습니다. 내 코드 기반을 읽기 전용 props 및 state에 적용함으로써 감지할 수 없는 타이핑 문제를 발견했습니다. 변경 사항을 게시한 것이 올바른 선택이었다는 점에는 의심의 여지가 없습니다.

Patsisson, VS, VS Code 또는 다른 편집기를 사용 중이신가요?

제 요점은 React가 기능적 접근 방식을 장려하는 반면 명령적으로(상태) 세계를 변경한 다음 렌더링(forceUpdate)하는 비디오 게임과 같은 워크플로를 허용한다는 것입니다. 이 접근 방식은 이제 TS에서 금지됩니다. 일종의 func-damentalism :)

그러면 현재 생태계를 작동 가능하게 만들기 위한 대안을 생각할 것입니다.

문제 2는 strictNullChecks 에서만 오류를 던집니다.

[TS] Cannot invoke an expression whose type lacks a call signature. Type '((val: any) => void) | undefined' has no compatible call signatures.

+1 strictNullChecks를 사용하고 있습니다.

@에리칸더슨 ?

위에서 언급했듯이 이것은 툴링과 관련이 있으며 이는 DT의 범위를 분명히 벗어납니다. VSCode를 사용 중이고 곧 출시될 TS 파서의 미리 보기를 설치하는 경우 위의 내용을 작성할 때 strictNullChecks에서 이 문제를 보지 못했습니다.

나는 창문이 없으므로 VS와 적절하게 말할 수 없습니다.

이 Pick 패치는 VSCode에서 제안을 중단했습니다. this.setState({ | }) (Ctrl + Space) 하면 State가 명확하게 정의되어 있고 Partial<State> 를 사용해도 아무 것도 표시되지 않습니다. setState 는 멤버의 상태를 선택적으로 설정할 수 있기 때문입니다.

IMHO 올바른 코드는 setState(state: Partial<S>, callback?: () => any): void; 여야 합니다.

원래 pull request 브랜치에서 논의한 것처럼 우리는 Partial로 시작했습니다. 그러나 상태 객체가 다음과 같은 경우:

인터페이스 상태 {
foo: 문자열;
}

그런 다음 부분적으로 다음을 수행할 수 있습니다.

setState({foo: 정의되지 않음});

분명히 잘못된 것입니다.

죄송합니다. 다시 읽기 전용에 대해

React는 Redux와 setState만이 아닙니다. React는 또한 mobx 및 기타 관찰 가능한 패턴이며 상태 속성 할당이 주요 기능 입니다. 논의된 변경 사항은 typescript로 mobx 사용을 완전히 종료합니다.

그렇다면 원래 반응 코드에 존재하지 않는 동작을 .d.ts 파일에 추가하는 이유는 무엇입니까? .d.ts는 원본 라이브러리를 반영하는 것이지만 작성자의 관점에 따라 올바른 코딩 스타일을 가르치는 것은 아닙니다!

@lezious , 나는 당신의 입장을 이해하지 못합니다. 코드 샘플을 제공할 수 있습니까? 그리고 샘플과 관련하여 타이핑에 대해 잘못된 점은 무엇입니까? 감사 해요!

괜찮아요:

이것은 내 상태 클래스입니다

class UserInfoBlockState  
{
    <strong i="7">@observable</strong>                  <- this is mobx way to declare state
    public updating: boolean;
    <strong i="8">@observable</strong> 
    public deleted: boolean;
}

그리고 이것은 내 구성 요소입니다

<strong i="12">@observer</strong>       <-- this is mobx way to make component react to state change
export class UserPanel extends React.Component<IUserInfoBlockProps, UserInfoBlockState>
{
   ......
     private updateUser()
    {
        this.state.updating = true;
        UsersAPI.update(this.props.user)
       .then(() =>
            {
                this.state.updating = false;      <--- this is the mobx way to work with the state
            }
        ).catch(() =>
            {
                this.showErrror("Server error");
                this.state.updating = false;
            });
    }
   ....

}

그리고 이제 우리(react+mobx로 작성된 거대한 프로젝트가 있는 우리 회사)는 새 릴리스 서클이 시작될 때 DT 및 React를 업데이트했으며 ... 3000개 이상의 컴파일 오류 "속성이 읽기 전용입니다". 와. 당신이 나에게 제안한 것 - 전체 프로젝트를 redux로 다시 작성하거나 react.d.ts를 업데이트하지 않거나 항상 분기된 버전을 유지하고 지원합니까?

@mweststrate , 이것을 확인하십시오.

@Iezious 귀하의 입장에 감사드리며 진정하시기 바랍니다. 나는 당신과 함께 일하려고 해요. 이것은 Redux와 아무 관련이 없지만 순수한 React입니다.

나는 DT가 이전에 작동했던 사용 사례를 차단하는 것을 원하지 않지만, 반응과 함께 mobx의 사용을 설명하는 방법이 반응 문서와 일치한다고 생각하지 않습니다. 그것).

React는 문서에서 state를 올바르게 사용하는 3가지 방법이 있다고 분명히 명시하고 있으며, 첫 번째는 "상태를 직접 수정하지 마십시오"입니다.

이것은 현재 코드 기반이 작동하는 방식이 향후 버전의 react에서 깨질 가능성이 높다고 믿게 만듭니다. https://github.com/mobxjs/mobx-react 를 살펴보면 상태를 이런 식으로 사용한다는 제안을 볼 수 없습니다. 사실, 그들은 당신이 속성을 사용하기를 원하는 것 같습니다.

https://mobx.js.org/getting-started.html 을 검토하고 "mobx 반응 상태"에 대해 인터넷 검색을 해보면, mobx를 사용하는 방식을 제안하는 문서를 찾지 못했습니다.

DT는 기껏해야 기본 라이브러리의 정신을 전달하고 최악의 경우 실제 구현을 전달해야 하며, 반응을 구매하고 구성 요소를 확장하는 것은 묵시적 ​​계약을 존중한다는 것을 의미한다는 것이 분명합니다.

내가 당신에게 무엇을 제안하는지 잘 모르겠습니다. 내가 생각할 수있는 몇 가지 옵션은 다음과 같습니다.

1. state 변수 인수를 주장하는 경우 "저렴한" 옵션은 React.Component 를 검색하여 MyComponent 로 바꾸고 $ MyComponent 를 하위 클래스로 정의하는 것입니다. 읽기 전용 제약 없이 React.Component 중.
2. mobx에 대한 문서에 게시된 관용적 예를 기반으로 하는 또 다른 방법은 this.state 사용을 중단하고 실제 React.Component 에 변수를 사용하는 것입니다. 이것은 약간 고통스러울 수 있지만 적어도 프로젝트의 새로운 사람들은 온라인에 설명된 대로 코드 기반의 패턴을 볼 수 있을 것입니다.
3. 현재 하고 있는 방식과 유사하게 계속 수행하려면 각 구성 요소에서 state 를 다시 선언할 수 있습니다.
4. this.state 를 검색하여 this.somethingElse 로 바꾸고 수동으로 선언할 수 있습니다.
5. DT에서 반응하기 위해 업데이트를 중단할 수 있습니다(향후 변경 사항이 사용 사례에 어떤 영향을 미칠 수 있는지에 따라 일반적으로 향후 반응에서 가능).

그것이 내 프로젝트라면 아마도 2번을 했을 것입니다. 비록 mobx에 대해 확실히 알지는 못하지만요.

죄송합니다(다른 사람들이 동의하지 않을 것이라는 의미는 아님). 나는 그 부분을 되돌릴 이유를 찾으려고 노력했지만 지금은 탑승하지 못하는 것 같습니다.

Mobx 패턴과 매우 유사한 React 상태 변경 및 렌더링을 구동하기 위한 RxJ 관찰 가능 항목의 사용자 지정 응용 프로그램인 우리의 전략을 다시 언급하겠습니다. 뷰(React) 레이어에서 입력을 받기 위해 액션을 사용합니다. 작업은 입력을 소비하고 관찰 가능 항목을 생성한 다음 다른 상태 관찰 가능 항목을 추가로 구동하는 함수와 동의어입니다. 이 패턴을 사용하면 관찰 가능한 값만 쿼리하고 상태 작업을 실행하기 때문에 React 레이어 관점에서 상태를 변경할 수 없습니다. 내부 상태에는 읽기 전용 제약 조건이 없기 때문에 내부적으로 상태는 작업의 결과로 자체적으로 "변경"될 수 있습니다.

진정할 수 없어요. 나는 프로덕션에 있는 프로젝트를 가지고 있고 엄청난 양의 팀 시간을 보내야 하고, 이것은 이 변경 이후에 돈을 의미합니다.

그리고 그 이유는 무엇입니까? 이 변화는 반응의 현실을 반영합니까? 아니요. 반응에 없는 제한 사항과 동작을 추가합니다. 이것이 옳다고 생각하기 때문에 어떻게든 추가되는 제한 사항입니다.

DT 프로젝트의 목표는 무엇입니까? JS 라이브러리를 가능한 한 정확하게 설명하거나 이러한 라이브러리의 올바른 사용 방법에 대한 우리의 비전을 설명하려면? "Definitely Typed"라는 이름에 따르면 첫 번째입니다. 따라서 이 제한이 원래 JS 라이브러리에 존재하지 않으면 DT에도 존재해서는 안 됩니다(MUST NOT). 이것이 제 요점입니다. 이 시점에서 내가 잘못한 부분은 무엇입니까?

나는 당신이 좌절감을 느낀다는 것을 이해합니다. 그러나 이것은 문서를 읽을 때 반응이 사용되도록 의도된 방식입니다. 귀하의 팀이 라이브러리를 남용하고 묵시적 계약을 위반했기 때문에 DT를 덜 구체적으로 만드는 방법을 거의 알 수 없습니다.

상태가 직접 변경 가능해야 함을 제안하는 반응 팀이 내놓은 1온스의 문서를 보여주시면 즉시 코드를 다시 변경하겠습니다.

https://facebook.github.io/react/docs/react-component.html#state

나중에 setState()를 호출하면 변경을 대체할 수 있으므로 this.state를 직접 변경하지 마십시오. this.state를 변경할 수 없는 것처럼 처리합니다.

반응이 this.state 변경할 수 없는 것으로 간주하는 것이 매우 분명해 보입니다. React는 this.state 의 _properties_를 변경할 수 없는 것으로 간주하지 않습니다(이는 redux 가정). 다음 작업을 자유롭게 수행할 수 있습니다.

this.state.user.name = "foo";

관용적 반응으로.

내가 선호하는 것은 API를 정확하게 입력하고(이 경우 Readonly 의미) 반응 팀이 명시한 모든 불변량을 표현하는 것입니다.

@ericanderson 죄송합니다. 이제서야 알아차렸습니다. FWIW 나는 변화가 합리적이고 도구가 따라 잡을 것이라고 생각합니다. 에 의해 개체를 사용하는 setState 오버로드를 더 이상 사용하지 않는 것을 고려하고 있다고 들었습니까? 미래는 모든 계정의 setState 축소 스타일입니다.

@amoreland 동의하지 않습니다. 당: https://facebook.github.io/react/docs/state-and-lifecycle.html#do -not-modify-state-directly

상태를 직접 수정하지 마십시오.

예를 들어 다음은 구성 요소를 다시 렌더링하지 않습니다.

// Wrong
this.state.comment = 'Hello';

대신 setState()를 사용하십시오.

// Correct
this.setState({comment: 'Hello'});

this.state를 할당할 수 있는 유일한 장소는 생성자입니다.

@johnnyreilly 나는 없었다. 그 흥미 롭군요. 원천?

최근의 리액트 컨퍼런스에서 논의된 내용 중 하나입니다. YouTube에서 사용할 수 있습니다. Lin Clark의 연설이었을 것입니다. 1일 차의 첫 번째 대화 중 하나 - v16에 대응할 예정된 변경 사항을 다룹니다. 섬유 등

https://www.reddit.com/r/reactjs/comments/5zqgsb/react_fiber_functional_setstate/ @gaeron이 여기에서 언급

@gaearon 죄송합니다.

mobx가 상태 변경을 수행하는 이유는 옵저버블이 상태를 완전히 _교체_하는 대신 React 업데이트를 구동하기 때문입니다. 상태는 렌더링을 구동하는 엔진이 됩니다. 따라서 this.state.updating = true; 와 같은 작업을 수행하면 실제로 상태 교체와 동일한 작업을 수행하는 것이지만 상태는 이전 콘텐츠에서 상태가 변경되었음을 구성 요소에 통지하여 새 렌더링을 트리거할 만큼 충분히 똑똑합니다. 나는 이것이 _conventional_ React 사용법이 아니라 훨씬 더 포괄적이고 더 높은 수준의 React 사용법이라는 데 동의합니다. 나는 전통적인 React 사용법이 소수의 구성 요소가 있는 소규모 프로젝트에만 유용하다고 주장합니다. 각각 수십 개의 반응성 돌연변이 드라이버가 있는 100개의 구성 요소로 끝나면 기존의 React 상태 변경(즉, setState)을 더 이상 안정적으로 사용할 수 없으며 _smart_ state(mobx가 기본적으로 수행하는 작업)와 관련된 아키텍처 변경을 수용해야 합니다. ).

즉, 타이핑 변경이 React 시스템의 고급 사용에 영향을 미치기 때문에 그가 화난 이유를 이해합니다. 관찰 가능한 상태 할당은 기술적으로 _mutating_ 상태가 아니라 RHS 값에 대한 관찰 가능한 이벤트를 호출하는 것입니다. mobx가 이러한 관찰 가능한 이벤트를 발행하기 위해 선택한 구문이 React 불변 상태의 명시적 의도와 충돌하는 경우가 있습니다.

@Iezious 이러한 유형의 문제에 대한 빠른 수정이 필요한 경우 React 유형을 보강하고 React.Component 유형 정의에 대한 확장을 사용하도록 구성 요소를 리팩터링하여 문제를 해결할 수 있습니다.

import * as React from 'react';
declare module 'react' {
  class MutableStateComponent<P, S> extends React.Component<P, S> {
    state: S;
  }
}
(React as any).MutableStateComponent = React.Component;

이제 state 멤버가 더 이상 readonly 로 표시되지 않는다는 점을 제외하고 일반 구성 요소와 마찬가지로 변경 가능한 상태 구성 요소를 만들 수 있습니다.

export class MyComponent extends React.MutableStateComponent<MyProps, MyState> {
  // this.state.name is writable
}

@patsissons 네, 바로 그 이유입니다.

저는 상태를 변경하지 않고 setState를 호출하는 mobx 옵저버블을 사용하고 있습니다. 제 거대한 프로젝트 코드가 훨씬 더 명확하고 이해하기 쉬워 보이기 때문에 그렇게 하고 있습니다.

나는 내 구성 요소를 만들 수 있다는 것을 알고 있습니다. 또한 npm 서버에서 스크립트를 만들 수 있으며 이 스크립트는 항상 우리 회사에 대해 이 변경 사항을 되돌릴 것입니다. "this.state.state.updated"와 같은 해킹과 다른 많은 해킹을 사용할 수 있습니다.

저는 이 변경이 실제로 반응 방식을 따르는 mobx와 같은 관찰 가능한 패턴 사용에 영향을 미친다고 말하고 싶습니다. 그러나 지금은 이 변경을 컴파일할 수 없고 작동하려면 몇 가지 해킹 및 해결 방법이 필요하기 때문입니다. 그래서 저는 이 변화가 옳지 않다고 생각합니다.

아마도 내가 제안한 MutableStateComponent 대신 Observable React 패턴에 더 잘 맞는 ObservableComponent 라고 부릅니다.

Readonly 를 삭제하면 일반 반응(및/또는 mobx를 제외한 다른 상태 관리 시스템)과 함께 반응 유형을 사용하는 사람들이 오류에 노출됩니다. 나는 거대한 프로젝트에서 mobx를 사용하지 않으며 누군가가 오타를 만들고 실수로 this.state.foo = bar 을 사용할 때 컴파일러 오류에 감사드립니다.

표준 반응과 비표준 반응 사용 사이에 피할 수 없는 절충점이 있는 경우 표준 반응 유형은 전자에 의존해야 합니다.

또한 mobx를 관용적으로 사용하면 문제가 되지 않습니다.

Readonly를 삭제하면 일반 반응(및/또는 mobx를 제외한 여러 상태 관리 시스템)과 함께 반응 유형을 사용하는 사람들이 오류에 노출됩니다. 나는 거대한 프로젝트에서 mobx를 사용하지 않으며 누군가 오타를 만들고 실수로 this.state.foo = bar를 사용할 때 컴파일러 오류에 감사합니다.

다시 한 번 - 당신은 코드 작성을 가르치고 있습니다

이 프로젝트는 코드 작성을 가르치는 것이 아니라 JS 라이브러리의 기존 기능을 설명하는 것입니다. 논의된 제한 사항은 원본 라이브러리에 없으므로 삭제해야 합니다.

그게 다야.

@patsissons

이러한 유형의 문제에 대한 빠른 수정이 필요한 경우 React 유형을 보강하고 React.Component 유형 defs에 대한 확장을 사용하도록 구성 요소를 리팩터링하여 문제를 해결할 수 있습니다.

옳지 않다. 내가 있는 기업의 세계에는 "빠른 수정"이 없습니다. SDK에서 무언가가 변경되거나 이전 버전과 호환 되어야 하는 경우, 그렇지 않으면 몇 년이 걸립니다. 2백만 라인 이상의 코드 프로젝트에는 빠른 수정이 없습니다. 몇 주간의 변경, 테스트, A/B 제품 테스트, 많은 사람들을 위한 롤아웃입니다. 실제 돈이 듭니다. 그리고 누군가가 실제 라이브러리에 존재하지 않는 이전 버전과 호환되지 않는 변경 사항을 추가했기 때문에 이 모든 엄청난 노력을 기울였습니까?

왜 forceUpdate가 반응에 여전히 존재한다고 생각합니까? 그들은 올바른 스타일에 대해 conf에 대해 이야기하고 있지만 다른 사용 방법을 방지하기 위해 변경합니다. 왜요? 대기업이고 라이브러리가 이전 버전과 호환되어야 함을 알고 있기 때문입니다.

@ericanderson 이 썼습니다

this.state.state.value = 1 

그의 관점에서도 정당하지 않다. 다음에 그는 TS에서 도구를 얻고 이 코드를 방지하는 제한을 추가할 것입니다. 또는 구성 요소를 최종 클래스로 만들거나 "올바른 스타일이고 사람들이 실수하지 않도록"하기 때문에 다른 것으로 만듭니다.

사람들의 실수 방지 - FB의 작업입니다. 원하는 경우 프록시를 쉽게 추가하고 상태 돌연변이를 허용하지 않을 수 있습니다. DT의 목적은 설명을 추가하는 것뿐입니다.

@이지어스

요점은 React 팀이 JavaScript로 상태를 변경할 수 없도록 만들 수는 없지만 가능하다면 그렇게 할 수 있다는 것입니다. 반면에 TypeScript는 상태를 변경할 수 없도록 만들 수 있으므로 이러한 변경이 유형 정의에 적용된 이유입니다. 상태 구성원에 대한 직접 수정을 허용하지 않는 것이 React 팀의 절대적인 의도였지만( 상태를 올바르게 사용하는 것에 대한 공식 문서에서 알 수 있듯이), 해당 제약 조건을 부과할 언어 구성이 없었습니다. 이 제약 조건은 알려지지 않았으며 처음부터 잘 문서화되었습니다. React의 _conventional_ 사용 범위 밖에서 작업하는 사람들의 경우 최소한 React 공식 사용 권장 사항을 준수해야 합니다. 우리 팀에게 이는 상태를 직접 변경하지 않고 상태 변경을 추진할 수 있는 솔루션을 설계하는 것을 의미했습니다. 이것은 특히 이와 같은 문제가 발생하지 않도록 하기 위해 수행되었습니다(이 변경이 우리에게 약간의 영향을 주긴 했지만 기본 설계가 아닌 기능 서명을 통해서만).

귀하의 상황에서 리팩토링이 불가능한 경우 변경이 이루어지기 전에 @types/react 를 15.0.1 에 고정하거나 @types/react 를 사용하지 않고 대신 자신의 변형을 유지하십시오. defs 를 입력하고 Component state 타이핑을 변경하기만 하면 됩니다. 변경 사항을 되돌리도록 누군가를 설득하는 데 성공하지 못할 것이라고 생각합니다.

forceUpdate 는 내부 구조적 상태가 수정될 때(또는 render() 가 변경 가능한 상태 외부의 데이터를 사용할 때) 렌더링을 구동하기 위한 권장 코드 경로로 문서화되어 있기 때문에 존재합니다. forceUpdate 의 사용법은 우리 팀이 React에서 사용하는 사용 패턴과 정확히 일치하도록 설계되었습니다.

React 팀은 JS로 상태를 변경할 수 없도록 만들 수 있습니다. 쉽습니다. 그러나 이전 버전과 호환되지 않습니다.

다시 한 번 다음과 같습니다.

this.state.state.value = 1 

합법 여부?

라고 생각합니다만 제 생각은 이미 명확합니다...

나는 가변성/불변성에 대한 대화가 _아직_ 관련이 있다고 생각하지 않습니다. 분명히 이 변경과 결합된 TS 컴파일러의 버그( Readonly 관련)로 인해 일반 구성 요소를 완전히 사용할 수 없게 되어 많은 기존 코드가 손상됩니다. 확실히 그것은 보편적으로 허용되는 유효한 사용 사례이며 지금은 이것을 롤백할 충분한 이유가 됩니다???

interface test1 {
    num: number;
}

function add<T extends test1>(initial: T, add: number) {
    var copy: Readonly<T> = initial;

    //ERROR HERE: [ts] Operator '+' cannot be applied to types 'T["num"]' and 'number'.
    return copy.num + add;
}

이에 대해 Typescript 팀에 미해결 문제가 있는지 아는 사람이 있습니까? 트래커에서 관련 문제를 찾을 수 없는 것 같습니다.

@caesay Microsoft/TypeScript#15501 참조

생성자에서 상태를 초기화해야 하지만 tslint는 "상태가 읽기 전용입니다"라고 표시합니다....

constructor(props) {
  super(props);
  this.state = {
     value: props.defaultValue,
  };
}

어떻게 고칠 수 있나요...........

setState 사용

setState가 생성자에서 작동하지 않습니다

또는 componentWillMount w/setState를 고려하십시오.

감사 해요

안녕하세요,

전체 스레드를 읽었지만 @alanwei0 시나리오를 처리할 계획이 있는지 확실하지 않습니다.

state 를 ReadOnly 로 사용하는 것이 합리적이라는 데 전적으로 동의합니다. 생성자에서 초기 상태를 설정할 수 없다는 것은 componentDidMount render 가 호출되기 때문에 상당히 복잡합니다.

생성자에서 this.state = { 를 사용하는 @pawelpabich 는 문제가 되지 않습니다. 생성자에서 readonly 변수에 할당할 수 있으며 Readonly<T> 는 할당을 방지하지 않습니다(절대!).

interface TInterface {
    test: string;
}

class TClass {
    readonly blah: Readonly<TInterface>;
    constructor() {
        this.blah = { test: "constructor" };
    }

    fn = () => {
        this.blah = { test: "fn" };
    }
}

여기서 유일한 오류는 fn 내부에 있습니다. Readonly<T> 때문이 아니라 readonly 키워드 때문입니다. 사실, 최신 버전의 타이핑은 readonly 키워드를 사용하지도 않습니다. 그래서 state 내부의 속성을 변경하지 않고 실제로 state를 아무데나 할당할 수 있습니다.

여기서 우리가 이야기한 문제는 상속된 구성 요소에서 상태 속성의 유형이 손실되는 유형 스크립트 컴파일러의 버그였습니다. 이것은 이후로 수정되었으며, 그렇다면 이 문제를 종료할 수 있습니다.

@caesay 죄송합니다, 저는 우리가 여기서 말하는 경우라고 생각했습니다. 내 문제는 기본 클래스에서 상태를 설정할 수 없다는 것입니다. 저는 TS 2.4.1을 사용 중입니다. 혹시 id가 문제인지 확인할 수 있도록 해주시나요?

항상 setState(componentWillMount에서)를 호출할 수 있습니다.

@pawelpabich 다시 말하지만 이것은 문제가 아닙니다 :) 의도적으로 기본 클래스에서 상태를 할당할 수 없습니다. 어떻게 할 수 있니? 파생 구성 요소에서 사용 중인 prop 계약을 모릅니다.

interface BaseCompState {
    baseState1?: string;
}

class BaseComp<TState extends BaseCompState> extends React.Component<any, TState> {
    constructor(props) {
        super(props);
        this.state = {
            baseState1: "fromBase",
        };
    }
}

interface TopCompState extends BaseCompState {
    topState1?: string;
}

class TopComp extends BaseComp<TopCompState> {
    constructor(props) {
        super(props);
        this.state = {
            baseState1: "fromTop",
            topState1: "fromTop",
        };
    }
}

이것은 파생 구성 요소의 간단한 예입니다(props는 생략되었지만 동일한 아이디어). 기본 클래스의 this.state = 는 TState 가 무엇인지 모르기 때문에 분명히 작동하지 않습니다. 게다가, 그것이 _did_ 작동한다면, 그것은 단지 부모가 설정한 상태를 덮어쓰게 될 것입니다. 최종 상태는 { baseState1: "fronBase" } 입니다. topState 속성은 어떻게 되었나요?

기본 구성 요소에서 상태를 처리해야 한다고 절대적으로 확신하는 경우 파생 구성 요소의 상태를 기본 구성 요소 생성자로 전달할 수 있습니다(할당할 수 있도록 TState 로). 다음과 같을 수 있습니다. 이것:

interface BaseCompState {
    baseState1?: string;
}

class BaseComp<TState extends BaseCompState> extends React.Component<any, TState> {
    constructor(props, state: TState) {
        super(props);
        this.state = Object.assign({
            baseState1: "fromTop",
        }, state);
    }
}

interface TopCompState extends BaseCompState {
    topState1?: string;
}

class TopComp extends BaseComp<TopCompState> {
    constructor(props) {
        super(props, {
            topState1: "fromTop",
        });
    }
}

또는 더 간단하게 기본 구성 요소 내에서 this.setState( 를 호출할 수 있습니다(예, 생성자에서 할 수 있습니다!)

여기에는 문제가 없습니다.

@caesay 제약 조건이 없으면 할당이 의미가 없다는 데 전적으로 동의합니다. 그러나 컴파일러에 코드가 올바른지 확인하는 데 필요한 모든 정보가 있지만 다음 코드는 여전히 컴파일 오류를 생성합니다.

import * as React from "react";

/* tslint:disable:max-classes-per-file*/

interface BaseProps {
    baseProp: string;
}

interface BaseState {
    baseState: string;
}

class Base<TProps extends BaseProps, TState extends BaseState> extends React.Component<TProps, TState> {
    constructor(props) {
        super(props);

        this.state = {
            baseState: props.baseProp
        };
    }

    render() {
        return <div>{this.state.baseState}</div>;
    }
}

interface DerivedProps extends BaseProps {
    derivedProp: string;
}

interface DerivedState extends BaseState {
    derivedState: string;
}

export class Derived extends Base<DerivedProps, DerivedState> {
    constructor(props) {
        super(props);

        this.state = {
            derivedState: props.derivedProp
        };
    }

    render() {
        return <div>{this.state.derivedState}</div>;
    }
}

오류

webpack: Compiled successfully.
ERROR at Test.tsx(17,9):
TS2322: Type '{ baseState: any; }' is not assignable to type 'Readonly<TState>'.

ERROR at Test.tsx(39,9):
TS2322: Type '{ derivedState: any; }' is not assignable to type 'Readonly<DerivedState>'.
  Property 'baseState' is missing in type '{ derivedState: any; }'.

Version: typescript 2.4.1

첫 번째. 생성자의 base에 있는 소품이 입력되지 않았습니다. 따라서 props.baseProp 는 할당할 수 없는 any 입니다!

둘째, Derived 의 소품에는 동일한 문제가 있고 baseState 가 없습니다. 물론 Readonly에 관계없이 작동하지 않습니다.

TProps extends BaseProps 즉 TProps 에는 BaseProps 와 동일한 구성원이 있습니다. 그렇다면 어떻게 정의되지 않습니까? 컴파일러가 그것을 유추할 수 없을 수도 있지만 정의되지 않았다고 말하는 것은 올바르지 않은 것 같다는 것을 이해합니다. Derived 에도 같은 생각을 적용할 수 있습니다.

생성자의 @caesay setState 는 이 메서드가 비동기식이고 초기 상태 설정 없이 render 에 도달할 수 있기 때문에 신뢰할 수 있는 솔루션이 아닙니다.

내가 볼 수있는 유일한 신뢰할 수있는 솔루션은 파생 클래스에서 전체 상태를 설정하는 것입니다. 여기에는 다음과 같은 명백한 단점이 있습니다.

1. 이것은 모든 파생 클래스에서 복제되어야 합니다.
2. 파생 클래스는 신경 쓰지 않는 상태에 대해 알아야 합니다.

위에서 보여드린 예제는 C#에서 작동하므로 TypeScript에서 작동하면 좋을 것입니다.

1. ~setState는 생성자에서 안전합니다~
2. 파생 클래스의 경우 내가 볼 수있는 가장 좋은 경우는 componentWillMount setState 를 호출하는 것입니다. 귀하의 기지는 해당 하위 상태에 있어야 하는 항목을 알지 못하므로 this.state 를 안전한 구성으로 가져올 수 없습니다. 그러나 하위 클래스는 부모의 componentWillMount 를 호출한 다음 필요하다고 생각하는 상태를 설정할 수 있습니다.
3. 많은 언어에는 typescript에 있으면 좋을 언어 기능이 있습니다. 일부는 가능합니다. 다른 사람들은 그렇지 않습니다. 어느 쪽이든 그것은 포함에 대한 논쟁이 아닙니다.
4. 보고 있는 오류는 의미가 있습니다. 그들은 타이핑이나 타이핑에서 버그를 제안하지 않습니다. 각각의 경우에 말 그대로 예상 유형과 일치하지 않는 개체에 this.state 를 할당하려고 합니다.

편집됨, 생성자의 setState에 대해 잘못되었음을 반영하고 가독성을 위해 백틱을 추가합니다.

@ericanderson 저는 우리가 여기서 어떤 진전도 이루지 못하고 있다고 생각합니다. 예시를 보여 드렸는데 집중해 주시면 감사하겠습니다. 그렇지 않으면 토론이 어렵습니다.

Re setState 생성자에서 사용하는 것은 안전 하지 않습니다 . 오류가 발생하지 않지만 렌더링이 발생하기 전에 상태를 설정하지 않습니다. 나는 그것 때문에 깨지는 코드를 가지고 있으며 React 문서는 거기에서 사용되어서는 안 된다는 것이 매우 분명합니다.

@pawelpabich 아니요, 이것은 이 주장을 할 곳이 아닙니다. 당신은 언어에 대한 이해가 근본적으로 잘못되었습니다. 귀하가 제공한 예에서 귀하는 주에 대한 귀하의 할당 중 어느 쪽이든 "주" 계약을 충족하지 않았습니다.

예를 들어 할 때

this.state = { baseState: props.baseProp };
// now the state is exactly { baseState: props.baseProp }

상태는 정확히 { baseState: props.baseProp } 이고 이것은 TProps extends BaseProps 의 요구 사항을 충족하지 않습니다(TProps가 무엇인지 모르기 때문에! 속성이 있을 수 있음).

그 후, 당신은 _ SEPARATE _ 할당을 하고 있습니다.

this.state = { derivedState: props.derivedProp };
// now the state is exactly {  derivedState: props.derivedProp }

상태는 이제 정확히 { derivedState: props.derivedProp } 이고(기본 상태 할당을 덮어썼습니다!!) 이것은 DerivedState 또는 BaseProps를 충족하지 않습니다.

이것이 작동해야 한다고 생각하는 것은 완전히 잘못된 것입니다. 기본 변수 할당이 작동하는 방식에 문제가 있는 경우 새 문제에서 언어 디자이너와 함께 문제를 해결하고 여기서 문제가 발생하므로 여기에서 알림을 받지 않도록 하세요.

참고로 기본 render() 메서드도 재정의합니다. 즉, 기본 구성 요소는 아무 것도 렌더링할 수 없습니다. 이것이 원하는 것이라고 확신한다면 보호된 멤버 getBaseState() 를 추가하고 상태를 설정할 때 파생된 생성자에서 이것을 호출할 수 있습니다(따라서 기본 상태 논리를 복제할 필요가 없음). 그러나 당신이 정말로 원하는 것은 파생 구성 요소를 전혀 사용하지 않는 것입니다. 구성을 사용하도록 구조 조정을 시도합니다(여러 하위 개체를 포함하는 하나의 개체가 있는 경우). 훨씬 깔끔해 질 것 같아요.

나는 단지 당신과 이 문제에 대해 토론하기 위해 새로운 프로젝트를 만들기 위해 독서에서 한 발짝 물러서고 싶지 않지만, 아아...

나는 생성자에서 setState () 에 대해 정정할 것이지만, componentWillMount 에서 그것을 사용하는 것에 대한 느낌은 변하지 않습니다.

이 작업을 수행하는 방법의 실제 예:
https://github.com/ericanderson/set-state-example

특히 index.tsx:

import * as React from "react";
import * as ReactDOM from "react-dom";

/* tslint:disable:max-classes-per-file*/

interface BaseProps {
  baseProp: string;
}

interface BaseState {
  baseState: string;
}

class Base<TProps extends BaseProps, TState extends BaseState> extends React.Component<TProps, TState> {
  public componentWillMount() {
    this.setState({
      baseState: this.props.baseProp,
    });
  }

  public render() {
    return (
      <p>
        <code>this.state.baseState: </code>
        {this.state.baseState}
      </p>
    );
  }
}

interface DerivedProps extends BaseProps {
  derivedProp: string;
}

interface DerivedState extends BaseState {
  derivedState: string;
}

export class Derived extends Base<DerivedProps, DerivedState> {
  public componentWillMount() {
    super.componentWillMount();
    this.setState({
      derivedState: this.props.derivedProp,
    });
  }

  public render() {
    return (
      <div>
        <p>
          <code>this.state.derivedState: </code>
          {this.state.derivedState}
        </p>
        {super.render()}
      </div>
    );
  }
}

ReactDOM.render(<Derived derivedProp="its derived" baseProp="its basic" />, document.getElementById("main"));

@pawelpabich 초기 상태로 다형성 구성 요소를 구현하려면 기본 구성 요소를 추상화하고 파생 클래스에서 구현할 추상 getInitialState() (또는 유사한 테마) 함수를 만들어야 합니다. @ericanderson 이 보여준 것처럼 생성자에서 또는 setState 를 사용하여 상태를 한 번만 할당하려고 합니다.

아래는 상태 구성과 관련된 문제를 완전히 분리하여 완전히 다형성 솔루션으로 변환한 예입니다.

interface BaseProps {
  baseProp: string;
}

interface BaseState {
  baseState: string;
}

abstract class Base<TProps extends BaseProps, TState extends BaseState> extends React.Component<TProps, TState> {
  constructor(props: TProps) {
      super(props);

      this.state = this.getInitialState();
  }

  protected abstract getInitialState(): TState;

  protected getBaseState() {
    return this.props.baseProp;
  }

  render() {
      return <div>{this.state.baseState}</div>;
  }
}

interface DerivedProps extends BaseProps {
  derivedProp: string;
}

interface DerivedState extends BaseState {
  derivedState: string;
}

export class Derived extends Base<DerivedProps, DerivedState> {
  getInitialState(): DerivedState {
    return {
      baseState: this.getBaseState(),
      derivedState: this.props.derivedProp,
    };
  }

  render() {
      return <div>{this.state.derivedState}</div>;
  }
}

@patsisson 감사합니다!

@caesay 나는 내가 틀렸다는 것을 인정하고 어떤 이유로 할당이 서로를 무시하는 것을 보지 못했습니다. CAPS와 ! 를 사용해도 문제에서 벗어날 수 없었습니다.

@patsissons 와 @ericanderson 은 문제에 집중했고 이제 다른 사람들이 사용할 수 있는 솔루션이 있습니다.

@pawelpabich 내 매너리즘이 전문적이지 못하다는 데 동의합니다. 하지만 내가 여러 설명, 샘플 등을 제공했고 당신이 내 말을 듣지 않기로 선택한 것을 고려하면 이해할 만합니다.

그러면 부모가 설정한 상태를 덮어쓰게 됩니다.

[_하고 싶은 경우_] 기본 ​​구성 요소의 상태를 처리하려면 파생 구성 요소의 상태를 기본 구성 요소 생성자로 전달할 수 있습니다.

[_파생된 구성 요소의 상태를 처리하려는 경우_] 보호된 멤버 getBaseState()를 추가하고 상태를 설정할 때 파생된 생성자에서 이를 호출할 수 있습니다.

@patsisson 이 한 일은 여기에 이미 언급된 주석을 가져와서 코드 샘플을 제공하는 것이었습니다. 이는 필요하지 않았을 것입니다. 이것은 stackoverflow가 아니며 우리는 종종 거기에서 미리 만들어진 코드 샘플을 제공하지 않습니다.

나는 반응 및 typescript에 익숙하지 않으며 아마도 sth를 모르지만 앱이 오류, 경고 및 힌트 없이 컴파일되지만 런타임 오류가 발생합니다. 아래는 예시 컴포넌트입니다. Readonly 상태에 오류가 발생했습니다. Readonly 변경 전에 앱이 작동했다면 이 변경 후에는 작동이 중지되고 컴파일 시간 오류가 발생하지 않습니다.

import * as React from 'react';

export default class HomePage extends React.Component<any, Map<string, string>> {

  public componentWillMount() {
    const map = new Map<string, string>();
    map.set('aKey', 'aValue');
    this.setState(map);
  }

  public render() {

      return (
        <div className="home">
          <div className="greeting">
            Home page: {this.state.get('aKey')} // <-- I get an error here
          </div>
        </div>
      );
  }
}

오류:

homePage.tsx:12 Uncaught TypeError: this.state.get is not a function
    at HomePage.render (homePage.tsx:12)
    at eval (ReactCompositeComponent.js:793)
    at measureLifeCyclePerf (ReactCompositeComponent.js:73)
    at ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext (

상태는 항상 일반 키 객체여야 하므로 대신 상태를 정의하십시오.
{ values: Map <string, string> } 와 같이 읽고
this.state.values.get('aKey')

Op vr 29 9월 29일 2017 om 09:01 schreef Janusz Białobrzewski <
알림@github.com>:

나는 반응하고 타이핑하는 것이 처음이고 아마도 sth를 모르지만 심지어
앱이 오류, 경고 및 힌트 없이 컴파일되지만 런타임이 표시됩니다.
오류. 아래는 예시 컴포넌트입니다. 나는 오류를 읽기 전용으로 돌립니다.
상태. 앱이 읽기 전용 변경 이전에 작동했다면 이 후에
변경하면 작동이 중지되고 컴파일 시간 오류가 발생하지 않습니다.

* 'react'에서 React로 가져오기;
내보내기 기본 클래스 HomePage는 React.Component를 확장합니다.> {

공개 componentWillMount() {
const 맵 = 새 맵();
map.set('aKey', 'aValue');
this.setState(지도);
}

공개 렌더() {

  return (
    <div className="home">
      <div className="greeting">
        Home page: {this.state.get('aKey')} // <-- I get an error here
      </div>
    </div>
  );

}
}

오류:

홈페이지. tsx:12 잡히지 않은 TypeError: this.state.get은 함수가 아닙니다.
HomePage.render에서(homePage.tsx:12)
평가 시(ReactCompositeComponent.js:793)
measureLifeCyclePerf에서 (ReactCompositeComponent.js:73)
ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext에서 (

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14250#issuecomment-333047367 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABvGhM5hDyRNyUeZuIiGeTZk1N-rfuA4ks5snJW5gaJpZM4LuDWV
.

감사합니다. 하지만 state를 Readonly<S> 로 선언하는 것은 의미가 없는 것 같습니다. 중첩된 멤버는 Readonly의 영향을 받지 않기 때문입니다.

언젠가는 Readonly 가 재귀적으로 적용될 수 있지만 지금은 올바르게 처리했는지 확인하는 것은 사용자의 몫입니다. 귀하의 경우 실제로 ReadonlyMap 또는

interface State {
    readonly [key: string]: string;
}

또는 중첩:

interface State {
    map: { readonly [key: string]: string };
}

깊은 읽기 전용으로 사용할 수 있습니다.

export type DeepReadonly<T> =
  T extends Array<any> ?
  ReadonlyArray<T[0]> :
  T extends Date ?
  T :
  T extends Function ?
  T :
  T extends object ?
  { readonly [P in keyof T]: DeepReadonly<T[P]> } :
  T;

export type Writable<T> =
  T extends ReadonlyArray<any> ?
  Array<WritableObject<T[0]>> :
  T extends Array<any> ?
  Array<WritableObject<T[0]>> :
  WritableObject<T>;

type WritableObject<T> =
  T extends Date ?
  T :
  T extends Function ?
  T :
  T extends object ?
  { -readonly [P in keyof T]: Writable<T[P]> } :
  T;