Visual Studioで使用しているtypescriptのバージョンは何ですか？

@vsaio for sa

問題1の場合、TS 2.1.5と最新のVSCodeを使用すると、これは問題なく機能します。 私はwindows/VSを持っていないので、そこで確認することはできませんが、プラグインに更新があるか、TS2.1.5を使用していないに違いありません。

問題2についても同じ

TS2.1.5.0を使用したVS2015

問題3は議論の余地があると思います。

上記の例をReactで_技術的に_実行できることは正しいですが、Reactが意図された方法ではないことは間違いありません。

これは、3つの異なるケースに分けることができます。

一般的な初期化

interface State {
  bar: number;
}

interface Props {
  baz: number;
}

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

小道具に基づく初期化

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

私はTS2.1.5.0にいます

しかし、VSではVSコードよりもTSエクスペリエンスが最悪である可能性があります...

問題1の場合、定義に進みます。TSもVSCodeでは機能しません。

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の場合、VSCodeの動作が優れているのは事実です。

VSは混乱しているように見えますが：

VSCodeと問題1については、よりスマートな処理が必要な「最新のTypescriptとJavascriptの文法」のプラグインを使用しているため、機能していると思います。

@patsissonsは興味深い例ですが、定義ファイルのバグよりもtypescriptのバグの方が代表的だと思います。 たとえば、 setStateはSを使用していました。これは、 setState({foo:5} as any as State)のような奇妙なトリックを実行したり、関数を使用したりする必要があったパーシャルを実行することを意味していました。 コンパイラの表現度の欠如がタイピングを「間違った」ものにするかどうかはわかりません。 これは、このエッジケースをマークするためにREADMEを変更するための適切な議論だと思います。

TSに問題を提出しましたか？

したがって、この変更により、現在、すべてのVSが機能しなくなり、プラグインがある場合を除いて、すべてのVSコードで[定義に移動]が無効になります...

また、完全性の議論もあります。 React.d.tsには、読み取り専用であり、現在ではないAPIが無数にあります。

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

読み取り専用は、たとえばイベントオブジェクトのように、変更することを意図していない思考のロングテールではなく、「freeze」または「Inmmutable.js」に使用する必要があると思います。

まだ提出していません。今日、新しいReadonly<T>タイプを処理するためにコードを改良しただけです。これは、適切にタイプされたソリューションがないことに遭遇したケースです。 先に進んで問題を提出してください。今日の残りの時間のほとんどは、パッチコードで忙しくなります。

ああ、はい、私は私がいくつかを逃したことを知っていました。 @olmobrutall読み取り専用としてマークするために導入した状態の変更を保持する場合、これらのメソッドを更新する必要があることに同意します。 しかし、最初に行うべき正しいことについてのコンセンサスが必要だと感じています。

VSブレイクに関しては、何が正しいのかわかりません。 一部のツールが最新の状態に保たれていないため、タイプを控える必要がありますか？

@patsissonsすべてのコードを更新する前に、これがどのようにパンアウトするかを確認したい場合は、今のところ、react用に独自のタイピングをいつでも提供できます。 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の準備が整うまで控える価値があると思います。

また、APIから取得するオブジェクトのように、世界中の型の50％が読み取り専用であるように、注釈を付ける必要はないと思います。

get-onlyプロパティを持つように明示的に変換されたオブジェクトには、Readonlyを使用する必要があると思います。 フリーズのように。

@olmobrutall Readonlyは新しいため、正確なベストプラクティスは実際には定義されていません。 私は個人的に、それがそれを変化させないことを示すのを助けるためにそれがReadonly<>のものを必要とすることをすべて宣言することを望みます。 同様に、ReactはsetState stateを変更することを期待していません。したがって、この変更により、事故によってバグが発生しないことが保証されます。これは、JavaScriptよりもTypeScriptを使用する主な利点の1つです。

Object.freezeのブラウザ間でパフォーマンスがより一貫している場合、Reactの人々はsetStateの後に実際にフリーズし始めると思います。

では、forceUpdateの目的は何ですか？

ツールの更新に関してDefinitelyTypedがどのように機能するかについての他の人々の考えや、reactでの読み取り専用（および特定のオブジェクトを変更しないことを目的とする他​​のライブラリ）についての哲学に興味があります。

cc / @johnnyreilly @vsaio @ pspeter3具体的に反応することについての考え、および一般的な他の考えについて
cc / @ andy-ms @mhegazyは、ツールの更新とReadonlyの熱心な使用のために、DefinitelyTypedが哲学的にどのように進むべきかについての考えを示しています。

@olmobrutall forceUpdateを使用して、状態側で観察可能なイベントから駆動され、反応側でレンダリングをキューに入れます。

更新：
誤解されないように、シナリオを少し明確にします。 私たちの状態オブジェクトは長生きする不変オブジェクトです（したがって、 Readonly<T>は実際には私たちに非常に適しています）。 これらの状態オブジェクトには、 stateChangedと呼ばれる通知監視対象に到達する複数のrxjs監視可能ストリームが含まれています。 Reactコンポーネントは、この監視可能なイベントを監視し、それらのイベントをforceUpdateへの呼び出しに注ぎ込みます（デバウンス後）。 事実上、私たちの可変状態は状態内に存在しますが、状態自体と状態に存在するメンバーはすべて不変です。 これは確かにReactの標準的なユースケースではありませんが、フローは非常に似ています。 再レンダリングが必要なときにコンポーネントに通知する方法を知っているスマートステートオブジェクトがあります。

@ericandersonの主な問題は、これらの型定義がSemVerの問題に悩まされていることです。 タイプ定義バージョンは主にそれぞれのモジュールバージョンに関連付けられているため、タイプ定義の変更を壊すマイナーバージョンバンプが発生します。つまり、 @typesバージョンをpackage.jsonに固定する必要があります。ファイル。

@olmobrutall反応のドキュメントから：

通常は、forceUpdate（）の使用をすべて避け、render（）のthis.propsとthis.stateからのみ読み取るようにしてください。

実際、Reactガイドでは、状態を直接更新しないように指示されています： https ://facebook.github.io/react/docs/state-and-lifecycle.html#do -not-modify-state-directly

forceUpdateは、私が読んだように、コンポーネントが小道具や州のデータに基づいていない場合に、コンポーネントを強制的に更新するためだけのものです。

@patsissons私は間違っているかもしれませんが、SemVerはAPIおよびセマンティックインテントとの下位互換性があるように設計されていると思います。 意図されていない方法でライブラリを使用しているからといって（ドキュメントによると）、ライブラリが前述の意図しない使用をサポートし続ける必要があるという意味ではありません。 ライブラリの作成者は、SemVerの範囲内で、誤っていたがたまたま一部の人が使用したセマンティクスを変更できます。

そうは言っても、おそらくReadonly<>からstateへの変更は大きすぎますが、それが正しい変更であると少しの間考えてみてください。 いつDefinitelyTypedにリリースする必要がありますか？ 最終的にstateをReadonly<> $としてマークする更新を取得すると、コードを変更する必要が常にあります。

Readonly<>がstateに適用されていることについて、私はまだ何が正しいのかわかりません。これにより、semverやツールなどについて議論するのが難しくなります。 私の直感はそれが正しかったということでした。 変更をレビューした人々は、それを問題として取り上げることはありませんでした。 Reactチームの意図と一致しているようです。

DefinitelyTypedでの反応については、レビュー担当者のいずれかに任せることができてうれしいです（上記のすべてをccしました）。

では、ObservableはforceUpdateの状態を変更しますか？ したがって、状態を強制的に変更することは、ある程度許可されています。

読み取り専用を使用する場所が100％定義されていないことを理解しています。 しかし、ツールの準備が整う前に、物議を醸す大量に使用されるプロパティから始める必要がありますか？

私はすべて強く型付けされているので、すべてstrictNullChecksを使用して6つのプロジェクトを管理していますが、ここでの利点は、現在発生している問題よりもはるかに小さいものです。

@ericanderson SemVer2は、 ^15.0.0のようなノードバージョン宣言を許可するように設計されており、モジュールへのマイナーアップグレードまたはパッチアップグレード（つまり、 15.0.1または15.1.0 ）が透過的または少なくとも外部の観点からは下位互換性があります。 メジャーアップグレード（ 16.0.0 ）では、変更を加えるためにバージョン宣言を調整する必要があります。 これは本質的に、タイピングシステムに持ち込まれることからの破壊的な変更をゲートします。 ただし、現在、型定義バージョンは、それぞれのモジュールバージョンのメジャーバージョン（慣例により）から逸脱することはできません。そのため、この不連続性が発生します。

短いバージョンでは、タイプ定義には、モジュール自体をまったく変更せずに重大な変更を導入することができ、重大な変更にはメジャーバージョンのバンプが必要です。

しかし、あなたはforceUpdateを削除するPRを作成しませんよね？

次に、forceUpdateが存在する場合は、状態を変更する必要があります。

理論的には、深く不変の状態グラフを使用する必要がありますが、状態を強制的に変更することは問題なく、すべての開発者が永続データ構造のアイデアに賛成するわけではありません。

幸い、Reactはスケープルートを許可し、状態を直接変更することを可能にします。TS開発者がそのルートを使用することを禁止しますか？ それはあまりにも父性的ではありませんか？

たとえば、Vue.jsは必須の変更を促進しますが、Reactに影響を与えても驚かないでしょう。

また、私は少し前にReactの作者のブログ投稿を読んでいました（思い出すことができます）。

それ以外の私の立場は、型定義をできるだけ早く公開することです。私の唯一の関心事は自動化です。 タイプ定義のバージョン管理の現在の状態を考えると、ソースを変更せずに後続のビルドが中断する可能性があるためです。 これらのタイプの非決定論的CI障害は厄介です。 彼らが変更をプッシュし、ビルドの中断とは何の関係もない変更の手を見つけたので、誰もビルドの中断を見たくありません。

その上で寝た後、私の個人的な意見は次のとおりです。

• 糸またはnpmロックを使用することをお勧めします。そのため、最初にローカルでアップグレードしない限り、驚くことはありません。
• 状態を読み取り専用にすることは、Reactの使用を意図した方法です。 ドキュメントと例はこれを確認します。
• setStateを使用したくないワークフローは、コードベース内およびユーザー自身の権限内にあります。 ReactがforceUpdateを提供することは正しいですが、その使用は、意図されたユースケースの外にあるときにレンダリングを引き起こすことを目的としています。 したがって、意図したとおりに状態を使用したくない場合は問題ありませんが、その時点でインスタンス変数の状態を使用する必要はありません。 実際、通常のプライベート変数を使用できます。
• はい、このプロジェクトは多くの人々に依存していますが、これまでのところ、これは2つの不満だけであり、これは広範囲にわたる問題ではないと私は思います。 さらに、グローバル関数に関して提起された問題は、ジェネリックを別の方法で解釈するように書き直すことができます（リンクされたTypeScriptの問題を参照）。

上記の考えと非標準のReactアプリの回避策を考えると、Readonlyは正しいと思います。完全を期すために必要な変更は、ライフサイクルメソッドを一致するように更新することだけです。

これらの変更が完全に理にかなっていることに同意します。問題を引き起こしていた私のユースケースは、めったに遭遇しない非常にユニークなコーナーケースでした。 コードベースを読み取り専用の小道具と状態に適合させることで、他の方法では検出できないタイピングの問題をいくつか見つけました。 変更を公開することが正しい選択であったことは間違いありません。

Patsisson、VS、VS Code、またはその他のエディターを使用していますか？

私のポイントは、Reactは機能的なアプローチを促進しますが、ビデオゲームのようなワークフローを可能にし、世界に強制的に変更を加え（state）、次にレンダリングする（forceUpdate）ということです。 このアプローチは現在TSでは禁止されています。 一種の機能-ダメンタリズム:)

次に、現在のエコシステムを機能させるための代替案を考えます...

問題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を使用しています

@ericanderson ？

上記のように、これはツールに関連しており、明らかにDTの範囲外です。 VSCodeを使用していて、次のTSパーサーのプレビューをインストールする場合、上記のいずれかを記述しているときに、strictNullChecksでこの問題は発生しませんでした。

私は窓を持っていないので、VSに適切に話すことができません。

このPickパッチは、VSCodeでの提案を破りました。 this.setState({ | }) （Ctrl + Space）を実行すると、状態が明確に定義され、 setStateがメンバーの状態を選択的に設定できるため、$ Partial<State>を使用していても、何も表示されません。

私見正しいコードはsetState(state: Partial<S>, callback?: () => any): void;である必要があります

元のプルリクエストブランチで説明したように、Partialから始めました。 ただし、状態オブジェクトが次の場合：

インターフェイスの状態{
foo：文字列;
}

次に、partialを使用すると、次のことができます。

setState（{foo：undefined}）;

これは明らかに間違っています。

申し訳ありませんが、読み取り専用についてです

ReactはReduxとsetStateだけではありません。 Reactはmobxやその他の観察可能なパターンでもあり、状態プロパティの割り当てが主な機能です。 議論された変更は、typescriptでmobxの使用を完全に殺します。

では、なぜ元のReactコードに存在しない動作を.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 、plzこれをチェックしてください。

@Ieziousあなたの立場に感謝し、落ち着いてください。 私はあなたと一緒に仕事をしようとしています。 これはReduxとは何の関係もありませんが、純粋なReactです。

DTが以前に機能したユースケースをブロックしたくないのですが、reactでのmobxの使用をどのように説明するかは、reactのドキュメント（または、私が読んだ今のmobxのドキュメント）と一致しているとは思いません。それ）。

Reactは、ドキュメントで状態を正しく使用する方法が3つあることを明確に述べています。最初の方法は、「状態を直接変更しない」です。

これにより、コードベースが現在機能している方法が、reactの将来のバージョンで機能しなくなる可能性が非常に高いと私は信じています。 https://github.com/mobxjs/mobx-reactを調べても、このように状態を使用するという提案は見当たりません。 実際、彼らはあなたにプロパティを使って欲しいようです。

https://mobx.js.org/getting-started.htmlを確認し、「mobx react state」をグーグルで検索しましたが、mobxを現在の方法で使用することを提案するドキュメントは見つかりませんでした。

DTは、基礎となるライブラリの精神をよく伝え、実際の実装を最悪の場合に伝えることになっています。反応してコンポーネントを拡張することは、暗黙の契約を尊重することを意味することは明らかです。

何をすればいいのかわかりません。 私が手に負えないと考えることができるいくつかのオプション：

1. state変数を引き継ぐことを主張する場合の「安価な」オプションは、$ React.Componentを検索してMyComponentに置き換え、$ MyComponentをサブクラスとして定義することです。読み取り専用の制約なしでReact.Componentの。
2. もう1つは、mobxのドキュメントに投稿されている慣用的な例に基づいて、時間をかけてthis.stateの使用を停止し、実際のReact.Componentの変数を使用することです。 これは少し面倒かもしれませんが、少なくともプロジェクトの新しい人々は、オンラインで説明されているように、コードベースのパターンを見ることができます。
3. 自分と同じようにやり続けたい場合は、各コンポーネントでstateを再宣言できます。
4. this.stateを検索してthis.somethingElseに置き換え、手動で宣言することができます。
5. DTから反応するための更新の取得を停止することができます（将来の変更がユースケースにどのように影響するかによっては、将来的には一般的に反応しないようにすることもできます）。

もしそれが私のプロジェクトだったら、私はおそらく2番目のことをするでしょうが、確かに知るためにmobxについて十分に知りません。

申し訳ありませんが、私はあなたに同意することができませんでした（他の人があなたに同意しないという意味ではありません）。 その部分を元に戻す理由を見つけようとしましたが、現時点では乗船できないようです。

Reactの状態変化とmobxパターンに非常によく似たレンダリングを駆動するためのRxJオブザーバブルのカスタムアプリケーションである私たちの戦略についてもう一度説明します。 アクションを使用して、ビュー（React）レイヤーから入力を受け取ります。 アクションは、入力を消費してオブザーバブルを生成する関数と同義であり、オブザーバブルは他の状態のオブザーバブルをさらに駆動します。 このパターンにより、監視可能な値を照会して状態アクションを実行するだけなので、Reactレイヤーの観点から状態を不変のままにすることができます。 内部状態には読み取り専用の制約がないため、内部的には、アクションの結果として状態が「変化」する可能性があります。

落ち着かない。 私はプロジェクトを本番環境で使用しており、チームに膨大な時間を費やす必要があります。これは、この変更以降、お金を意味します。

そして、その理由は何ですか？ この変化は、反応の現実を反映していますか？ いいえ。それは、reactには存在しない制限と動作を追加します。これは、彼がこれが正しいと思ったという理由だけで、何らかの形で追加された制限です。

DTプロジェクトの目的は何ですか？ JSライブラリを可能な限り正確に説明するのか、それともそれらのライブラリを正しく使用する方法についての私たちのビジョンを説明するのですか？ 「DefinitelyTyped」という名前によると、それが最初です。 したがって、この制限が元のJSライブラリに存在しない場合は、DTにも存在してはなりません（MUSTNOT）。 これが私のポイントです。 この点で私はどこが間違っていますか？

不満を感じているとのことですが、これは、ドキュメントを読んで反応を使用することを目的とした方法です。 あなたのチームがライブラリを悪用し、暗黙の契約に違反したため、DTをより具体的にする方法がわかりません。

状態を直接変更できるようにする必要があることを示唆する、reactチームが出した1オンスのドキュメントを見せてください。すぐにコードを元に戻します。

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

this.stateを直接変更しないでください。後でsetState（）を呼び出すと、行った変更が置き換えられる可能性があります。 this.stateを不変であるかのように扱います。

reactがthis.state不変と見なしていることはかなり明らかなようです。 Reactはthis.stateの_properties_を不変とは見なしません（これはreduxの仮定です）。 あなたは自由に行うことができます：

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

慣用的な反応で。

私の好みは、APIを正確に入力し（この場合はReadonlyを意味します）、反応チームが述べているすべての不変条件を表現することです。

@ericanderson申し訳ありませんが、私はこれに気づいただけです。 FWIW変更は合理的であり、ツールが追いつくと思います。 by byとして、オブジェクトを取得する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私はしていませんでした。 それは面白い。 ソース？

最近のReactカンファレンスでの講演の1つで取り上げられました。 YouTubeで入手できます。 リン・クラークの話だったのかもしれません。 1日目の最初の講演の1つ-v16に対応するための今後の変更について説明します。 ファイバーなど

https://www.reddit.com/r/reactjs/comments/5zqgsb/react_fiber_functional_setstate/ここで@gaeronが言及

申し訳ありませんが@gaearon私は意味しました

mobxが状態変更を実行している理由は、オブザーバブルが状態を完全に_置換_するのではなく、React更新を駆動しているため、状態がレンダリングを駆動するエンジンになるためです。 したがって、 this.state.updating = true;のようなことを行うことで、実際には状態の置換と同等のことを行いますが、代わりに、状態が以前のコンテンツから変更されたことをコンポーネントに通知することで、新しいレンダリングをトリガーするのに十分なスマートな状態になります。 私は、これが_従来の_Reactの使用法ではなく、Reactのはるかに包括的で高レベルの使用法であることに同意します。 従来のReactの使用法は、少数のコンポーネントを含む小さなプロジェクトにのみ役立つと私は主張します。 それぞれが数十のリアクティブミューテーションドライバーを持つ数百のコンポーネントで終わると、従来のReact状態の変更（つまり、setState）を確実に使用できなくなり、_smart_状態（mobxが本質的に行うこと）を含むアーキテクチャの変更を楽しまなければなりません。 ）。

そうは言っても、タイピングの変更がReactシステムのより高度な使用法に影響を与えているため、彼が動揺している理由を理解しています。 監視可能な状態の割り当ては、技術的には「変化する」状態ではなく、RHS値の監視可能なイベントを呼び出します。 mobxがこれらの観察可能なイベントを発行するために選択した構文が、Reactの不変状態の明示的な意図と矛盾するのは偶然です。

@Ieziousこのタイプの問題の迅速な修正が必要な場合は、React型を拡張し、コンポーネントをリファクタリングしてReact.Component型defの拡張機能を使用することで問題を回避できます。

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 observablesを使用しています。これは、巨大なプロジェクトコードがはるかに明確で理解しやすいように見えるためです。

私は自分のコンポーネントを作成できることを知っています。また、npmサーバーでスクリプトを作成することもできます。このスクリプトは、会社のこの変更を常に元に戻します。 「this.state.state.updated」のようなハックや他の多くのハックを使用できます。

この変更は、実際には反応方法に従うmobxのような観察可能なパターンの使用に影響を与えると言いたいのですが、現在、この変更はコンパイルできず、動作するためにいくつかのハックと回避策が必要です。 そのため、この変更は正しくないと思います。

おそらく、私の提案しMutableStateComponentの代わりに、Observable Reactパターンとより整合性のあるObservableComponentと呼びます。

Readonlyをドロップすると、通常の反応で反応タイプを使用している人（および/またはmobx以外の任意の数の他の状態管理システム）がエラーにさらされます。 私は巨大なプロジェクトでmobxを使用していません。誰かがタイプミスをして、誤ってthis.state.foo = barを使用した場合のコンパイラエラーに感謝します。

標準の反応と非標準の反応の使用の間に避けられないトレードオフがある場合、標準の反応タイプは前者に傾くはずです。

さらに、mobxを慣用的な方法で使用する場合、これは問題ではありません。

読み取り専用を削除すると、通常の反応で反応タイプを使用している人（および/またはmobx以外の任意の数の他の状態管理システム）がエラーにさらされます。 私は巨大なプロジェクトでmobxを使用していません。誰かがタイプミスをして、誤ってthis.state.foo=barを使用した場合のコンパイラエラーに感謝します。

だからもう一度-あなたはコードを書くことを教えています

このプロジェクトは、コードの記述方法を教えることではなく、JSライブラリの既存の機能を説明することを目的としています。 説明した制限は元のライブラリには存在しないため、削除する必要があります。

それで全部です。

@patsissons

このタイプの問題をすばやく修正する必要がある場合は、React型を拡張し、コンポーネントをリファクタリングしてReact.Component型defの拡張機能を使用することで問題を解決できます。

正しくありません。 私がいる企業の世界では、「迅速な修正」はありません。 SDKで何かが変更された場合、または下位互換性が必要な場合、または何年もかかります。 2M以上のコードプロジェクトには迅速な修正はありません。 何週間にもわたる変更、テスト、A / B製品テスト、多数の人々への展開です。 実費がかかります。 そして、誰かが実際のライブラリに存在しない下位互換性のない変更を追加したという理由だけで、この膨大な努力はすべてありますか？

なぜforceUpdateがreactにまだ存在していると思いますか？ 彼らは正しいスタイルについてconfsについて話しているが、他の使用方法を防ぐために変更を加えている。 なんで？ それは大企業であり、ライブラリは下位互換性がなければならないことを彼らは知っているからです。

@ericandersonはそれを書いた

this.state.state.value = 1 

彼の観点からも合法ではありません。 次回、彼はTSからツールを入手し、このコードを妨げる制限を追加します。 または、「それが正しいスタイルであり、人々が間違いを犯さないようにする」という理由だけで、コンポーネントの最終クラスなどを作成します。

人々が不正行為をするのを防ぐ-それはFBの仕事です。彼らがそれをしたいのであれば、彼らは簡単にプロキシを追加し、状態の変化を禁止することができます。 DTの目的は、説明を追加することだけです。

@Iezious

重要なのは、ReactチームはJavaScriptで状態を不変にすることはできないということですが、できればそうすることができます。 一方、TypeScriptは状態を不変にすることができるため、この変更が型定義に加えられたのはそのためです。 州のメンバーに直接変更を許可しないことはReactチームの絶対的な意図でしたが（州の正しい使用に関する公式ドキュメントで明らかです）、その制約を課すための言語構造がありませんでした。 この制約は決して未知ではなく、最初から十分に文書化されています。 Reactの_従来の_使用法以外で操作している私たちの場合、少なくともReactの公式使用法の推奨事項を順守する必要があります。 私のチームにとって、それは、状態を直接変更せずに状態の変化を促進できるソリューションを設計することを意味しました。 これは特に、このような問題が発生しないようにするために行われました（この変更はわずかに影響しましたが、基本的な設計ではなく、関数のシグネチャを介してのみ影響しました）。

ご使用の状況でリファクタリングが不可能な場合は、変更が行われる前に@types/reactを15.0.1に固定するか、 @types/reactを使用せずに、代わりに独自のバリアントを維持してください。 defsと入力し、 stateの入力をComponentに変更するだけです。 変更を元に戻すように説得することに成功することはないと思います。

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キーワードも使用されていないため、状態内のプロパティを変更するだけでなく、実際にどこにでも状態を割り当てることができます。

ここで話していた問題は、typescriptコンパイラのバグであり、継承されたコンポーネントで状態プロパティの型が失われていました。 これはその後修正されたと思います。もしそうなら、この問題は解決できます。

@caesay申し訳ありませんが、ここで話しているのはそうだと思いました。 私の問題は、基本クラスで状態を設定できないことです。 私はTS2.4.1を使用しています。 たまたま問題のIDを教えていただけますか？

（componentWillMount内の）setStateをいつでも呼び出すことができます。

@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",
        };
    }
}

これは派生コンポーネントの簡単な例です（小道具は省略されていますが、同じ考えです）。 基本クラスのthis.state =は、 TStateが何であるかを知らないため、明らかに機能しません。 さらに、それが機能する場合は、親によって設定された状態を上書きするだけです。 最終的な状態は{ 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

初め。 コンストラクターのベースにある小道具は入力されていません。 したがって、 props.basePropはanyであり、割り当てできません。

次に、 Derivedの小道具にも同じ問題があり、 baseStateがありません。 もちろん、読み取り専用に関係なく、どちらも機能しません

TProps extends BasePropsは、 TPropsに少なくともBasePropsと同じメンバーがいることを意味します。 では、それはどのように定義されていないのでしょうか？ コンパイラがそれを推測できないかもしれないことは理解していますが、それが定義されていないと言うのは正しくないようです。 同じ考え方をDerivedにも適用できます。

コンストラクターの@caesay setStateは、このメソッドが非同期であり、初期状態を設定しなくてもrenderに到達できるため、信頼できるソリューションではありません。

私が見ることができる唯一の信頼できる解決策は、派生クラスに状態全体を設定することです。 これには明らかな欠点があります。

1. これは、すべての派生クラスで複製する必要があります
2. 派生クラスは、気にしない状態について知る必要があります。

上で示した例はC＃で機能するので、TypeScriptで機能することができれば便利です。

1. 〜setStateはコンストラクターで安全です〜
2. 派生クラスの場合、私が見ることができる最良のケースは、 componentWillMountでsetStateを呼び出すことです。 あなたの基地はその子のために何が状態にあるべきかを知らないので、おそらくthis.stateを安全な構成にすることができません。 ただし、サブクラスは親のcomponentWillMountを呼び出してから、必要と思われる状態を設定できます。
3. 多くの言語には、typescriptに含めると便利な言語機能があります。 いくつかは実行可能です。 他はそうではありません。 いずれにせよ、それはそれらを含めることの議論ではありません。
4. あなたが見ているエラーは理にかなっています。 それらはtypescriptやタイピングのバグを示唆していません。 いずれの場合も、期待されるタイプと一致しないオブジェクトを文字通りthis.stateに割り当てようとしています。

編集済み。コンストラクターのsetStateについて間違っていたことを反映し、読みやすくするためにバッククォートを追加しました。

@ericandersonここでは進展がないと思います。 例を示しましたが、それに焦点を当てていただければ幸いです。 そうでなければ、議論するのは難しいです。

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()を追加し、状態を設定するときに派生コンストラクターからこれを呼び出すことができます（したがって、基本状態ロジックを複製する必要はありません）。 しかし、あなたが本当に望んでいるのは、派生コンポーネントをまったく使用しないことです。 コンポジションを使用するように再構築してみてください（1つのオブジェクトに複数の子オブジェクトが含まれている場合）。 かなりきれいになると思います。

私はあなたとこれを議論するためだけに新しいプロジェクトを作成するために読書から離れたくありませんが、残念ながら...

コンストラクターで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を使用して、状態を1回だけ割り当てる必要があります。

以下は、状態の構築に関する関心の分離を完全に分離した、完全に多形のソリューションに変換された例です。

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

@patsissonsありがとう！

@caesay私は自分が間違っていたことを認め、何らかの理由で割り当てが相互に上書きされることを認識していませんでした。 そうは言っても、CAPSと!を使用しても、自分の穴から抜け出すのに役立ちませんでした。

@patsissonsと@ericandersonは問題に焦点を合わせ、他の人が使用できる解決策ができました。

@pawelpabich私は私のマニエリスムが専門的ではなかったことに同意しますが、当然のことながら、私があなたにいくつかの説明やサンプルなどを与えたことを考えると、あなたは私に耳を傾けないことを選択します。

その場合、親によって設定された状態を上書きするだけです。

[_必要に応じて_]ベースコンポーネントの状態を処理する場合は、派生コンポーネントからベースコンポーネントコンストラクターに状態を渡すことができます。

[_派生コンポーネントで状態を処理する場合_]保護されたメンバーgetBaseState（）を追加し、状態を設定するときに派生コンストラクターからこれを呼び出すことができます。

@patsissonsが行ったことは、ここですでに述べたコメントを取得し、コードサンプルを提供することでした。これは必要ではなかったはずです。 これはスタックオーバーフローではなく、既製のコードサンプルも提供しないことがよくあります。

私は反応してタイプスクリプトを作成するのは初めてです。おそらく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 (

状態は常にプレーンキーオブジェクトafaikである必要があるため、代わりに状態を定義します
次のようなものとして： { values: Map <string, string> }そして読む
this.state.values.get('aKey')

Op vr299月。 2017 om09:01schreefJanuszBiałobrzewski<
[email protected]>：

私は反応してタイプスクリプトを書くのは初めてです、おそらく私はsthを知りませんが、
アプリはエラー、警告、ヒントなしでコンパイルされますが、ランタイムが発生します
エラー。 以下はコンポーネントの例です。 エラーは読み取り専用に起因すると考えています
州。 読み取り専用の変更前にアプリが機能した場合は、この後
変更すると動作が停止し、コンパイル時エラーは発生しません。

import * as React from'react';
デフォルトクラスのエクスポートHomePageはReact.Componentを拡張します> {

public componentWillMount（）{
const map = new Map（）;
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>
  );

}
}

エラー：

ホームページ。 tsx ：12 Uncaught TypeError：this.state.getは関数ではありません
HomePage.render（homePage.tsx：12）で
evalで（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
。

感謝しますが、ネストされたメンバーは読み取り専用の影響を受けないため、状態をReadonly<S>として宣言するのは無意味な作業のようです。

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;