Definitelytyped: [@ types / react] RefObject.currentは読み取り専用ではなくなりました

PRをいただければ幸いです。 非常に簡単な1行の変更である必要があります😊

@ferdaber 、
こんにちは、私はこの問題を選ぶのが好きです。 私はtypescriptを初めて使用するので（わずか1週間）、オープンソースへの最初の貢献になります。

node_modules / @ types / react / index.d.tsを確認しましたが、61行目に次のコードがあり、currentを読み取り専用として宣言しています。

interface RefObject<T> {
        readonly current: T | null;
    }

これが問題であれば、私は解決できます。 私の最初のPRのガイドをしてもらえますか？
お時間をいただきありがとうございます:)

はい、その行のreadonly修飾子を削除しているだけです。

React.useRefは、$ currentプロパティがreadonly MutableRefObjectを返します。 問題は、refオブジェクト型を統一する必要があるかどうかだと思います。

それらは統合されるべきであり、ReactランタイムはReact.createRef()によって作成されたcurrentプロパティに制限がなく、オブジェクト自体は封印されていますが凍結されていません。

そうではありません。 凍結されていない場合でも、正しい使用法を保証するために意図的に読み取り専用のままにしておきます。 nullを割り当てることができるようにすることを明確に示さずにnullで初期化された参照は、Reactによって管理したい参照として解釈されます。つまり、Reactは現在を「所有」し、表示しているだけです。

null値で始まる可変refオブジェクトが必要な場合は、ジェネリック引数にも| nullを指定してください。 Reactではなく「所有」しているため、変更可能になります。

私は以前にポインタベースの言語を頻繁に使用したことがあり、所有権はそれらの言語で_非常に_重要であるため、おそらくこれは私にとって理解しやすいものです。 そして、それがrefとは何か、ポインターです。 .currentはポインタを逆参照しています。

それは公平です。私はReact.createRef()をヘルパー関数として使用して、ポインターを作成しました。これは、Reactがrefの小道具として渡されない限り、ポインターを管理しないためです。同じ構造の単純なポインタオブジェクトを作成します。

createRefを変更して同じオーバーロードロジックを使用することもできますが、引数がないため、条件付きの型を返す必要があります。 | nullを含めると、$＃ MutableRefObjectが返されます。含めない場合は、（不変） RefObjectなります。

ただし、 strictNullTypesを有効にしていない場合は機能しますか？

🤔

_do_でstrictNullTypesが有効になっているコードに対して、間違ったコードを簡単に記述できるようにする必要がありますか？

この問題を作成したとき、この| nullの過負荷がすでにあることに気づいていませんでした。 あまり一般的なパターンではないので、そのようなものが存在するとは思っていませんでした。 私はドキュメントでそれをどのように見逃したのかわかりませんが、それは非常によく文書化され、説明されています。 useRefとcreateRefを統合したい場合を除いて、これを問題なく閉じても問題ありません。

問題自体はcreateRef useRefに基づいていたので、 createRefの逆参照ポインタ値を直接変更する人はほとんどいないので、これを閉じても問題ありません。

このオーバーロードパターンがうまく機能するかどうか疑問に思います。フックのドキュメントを見ると、デフォルト値でuseRefがいくつか使用されていることがわかります。この場合、 .currentの値は決して正しくない可能性があります。 nullですが、null以外のアサーション演算子を常に使用してそれを乗り越えるのは、ユーザーにとってちょっと面倒な場合があります。

初期値が指定されている場合は戻り値が可変であるが、省略されている場合は不変である方が理にかなっていますか？ 初期値が指定されている場合、refはおそらくrefを介してコンポーネントに渡されず、インスタンス変数のように使用されます。 一方、コンポーネントに渡されるだけの参照を作成する場合、初期値はおそらく提供されません。

そういうことを考えていました。 @Kovenskyどう思いますか？

@ferdaber useRefは現在定義されているため、 | nullと初期値nullを含まない一般的な引数を明示的に指定しない限り、常に可変であり、null許容ではありません。

コンポーネントに渡される参照は、 nullで初期化する必要があります。これは、リリース時にReactが参照を設定するためです（条件付きでマウントされているコンポーネントをアンマウントする場合など）。 値を渡さずにuseRefを指定すると、代わりにundefinedが開始されるため、 | nullだけを気にする必要があるものに| undefinedを追加する必要があります。 | null 。

Reactのドキュメントと初期値なしでuseRefを使用する際の問題は、Reactチームがnullとundefinedの違いをあまり気にしていないように見えることです。 それはフローのことかもしれません。

とにかく、私がuseRefを定義した方法は、 @ bschlenkのユースケースに正確に適合しますが、上記の理由により、 nullが「省略された」値であるだけです。

ああ、もっとよく見るとそれがわかります。そして、パラメーターなしでReactソースでundefinedとして初期化されているのは興味深いことです。 かっこいいので、すべてが桃色です、それは👍のように聞こえます

| nullを含めるかどうかにかかわらず、 currentのタイプがnullになる可能性があり、可変性が変更されただけであるというのは少し奇妙なことです。 また、Reactドキュメントは常に明示的にnullを渡すので、initialValueを省略しても有効ですか？

一般的にはそうではなく、少なくとも過去に、あるドキュメントでReactチームが「それが機能したとしても」、それを省略することを意図していないと指摘したとき。

たとえば、コンテキストをundefinedで開始する場合でも、 createContextの最初の引数が必要になるのはそのためです。 実際にundefinedを渡す必要があります。

一部の使用法では、パラメータを使用していないようです。

https://reactjs.org/docs/hooks-faq.html#is -there-something-like-instance-variables
https://reactjs.org/docs/hooks-faq.html#how -to-get-the-previous-props-or-state
https://reactjs.org/docs/hooks-faq.html#how -to-read-an-often-changing-value-from-usecallback

@ferdaberそれは彼らがそこのタイプを気にしていないからです。 useRef() （引数なし）のcurrentのタイプはどうあるべきですか？ undefined ？ any ？ それが何であれ、一般的な引数を与えたとしても、それはundefinedで|編集される必要があります。 _そして_それが（スレッドローカルストレージとしてだけでなく）react要素refとして使用するrefである場合、Reactはそこにnull | null必要です。

これで、 currentが$＃$ T ＃$ではなくT | null | undefinedであることがわかります。

// you should always give an argument even if the docs sometimes miss them
// $ExpectError
const ref1 = useRef()
// this is a mutable ref but you can only assign `null` to it
const ref2 = useRef(null)
// this is also a mutable ref but you can only assign `undefined`
const ref3 = useRef(undefined)
// this is a mutable ref of number
const ref4 = useRef(0)
// this is a mutable ref of number | null
const ref5 = useRef<number | null>(null)
// this is a mutable ref with an object
const ref6 = useRef<React.CSSProperties>({})
// this is a mutable ref that can hold an HTMLElement
const ref7 = useRef<HTMLElement | null>(null)
// this is the only case where the ref is immutable
// you did not say in the generic argument you want to be able to write
// null into it, but you gave a null anyway.
// I am taking this as the sign that this ref is intended
// to be used as an element ref (i.e. owned by React, you're only sharing)
const ref8 = useRef<HTMLElement>(null)
// not allowed, because you didn't say you want to write undefined in it
// this is essentially what would happen if we allowed useRef with no arguments
// to make it worse, you can't use it as an element ref, because
// React might write a null into it anyway.
// $ExpectError
const ref9 = useRef<HTMLElement>(undefined)

ええ、このDXは私のために機能し、ドキュメントはA ++なので、ほとんどの人が混乱することはないと思います。 この精緻化に感謝します！ 正直なところ、typedocでこの問題をパーマリンクする必要があります:)

useRef<T>()をサポートし、 useRef<T | undefined>(undefined)と同じように動作させる場合があります。 ただし、それを使用して作成したrefは、スレッドローカルストレージと同様に、要素refとして使用することはできません。

問題は...許可されている一般的な引数を_与えない_場合はどうなりますか？ TypeScriptは{}を推測します。 正しいデフォルトタイプはunknownですが、使用できません。

次のコードでこのエラーが発生します：

~~~ js
//..。
intervalRef = useRefとします（ヌル）; // letの代わりにconstでも試してみました
//..。
useEffect（（）=> {
const interval = setInterval（（）=> {/ *何かをする* /}、1000）;
intervalRef.current =間隔; //この行でエラーが発生しています

return () => {
    clearInterval(intervalRef.current);
}

}）
//..。
〜そして、ここでreadonlyを削除すると、次のように機能します。〜js
インターフェイスRefObject{{
読み取り専用電流：T | ヌル;
}
~~~

私はreackフックとtypescriptの両方を初めて使用するので（一緒に試してみるだけです）、コードが間違っている可能性があります

デフォルトでは、 nullのデフォルト値を使用して参照を作成し、その汎用パラメーターを指定すると、Reactに参照を「所有」させる意図を通知します。 所有しているrefを変更できるようにする場合は、次のように宣言する必要があります。

const intervalRef= useRef<NodeJS.Timeout | null>(null) // <-- the generic type is NodeJS.Timeout | null

@ferdaberありがとうございます！

これをさらに段階的に進めて、 currentのリターンタイプを見ると、おそらくT | null Tである必要がありますか？ フックの出現により、すべての参照がnullになる可能性がある場合があります。特に、 useRefがnull以外の初期化子で呼び出されることがよくあります。

https://github.com/DefinitelyTyped/DefinitelyTyped/issues/31065#issuecomment -446660394の優れた例のリストから続けて、次のように記述します。

const numericRef = useRef<number>(42);

numericRef.currentのタイプはどうあるべきですか？ number | nullである必要はありません。

タイプと関数を次のように定義した場合：

interface RefObject<T> {
  current: T;
}

function useRef<T>(initialValue: T): RefObject<T>;
function useRef<T>(initialValue: T|null): RefObject<T | null>;

function createRef<T>(): RefObject<T | null>;

これにより、次の使用法とタイプが生成されます。

const r1 = useRef(42);
// r1 is of type RefObject<number>
// r1.current is of type number (not number | null)

const r2 = useRef<number>(null);
// r2 is of type RefObject<number | null>
// r2.current is of type number | null

const r3 = useRef(null);
// r3 is of type RefObject<null>
// r3.current is of type null

const r4 = createRef<number>();
// r4 is of type RefObject<number | null>
// r4.current is of type number | null

何か問題がありますか？

Reactチームによると、「パラメーター化されていないuseRefのタイプは何ですか？」に対する答えは、（ドキュメントにもかかわらず）その呼び出しが正しくないということです。

DOM /コンポーネント参照の便利なオーバーロードとして、| null _specifically_を使用してオーバーロードを追加しました。これは、それらが常にnullで始まり​​、アンマウント時に常にnullにリセットされ、現在の自分で再割り当てすることはなく、Reactのみであるためです。

読み取り専用には、真のJavaScriptフリーズオブジェクト/ゲッターのみのプロパティの表現よりも、論理エラーを防ぐための機能があります。

とにかく値をnullに初期化するときに、nullを受け入れないという一般的な引数を両方とも与える場合にのみ、偶然にそれを行うことができます。 その他の場合は変更可能です。

ああ、はい、 RefObject<T>と比較して、 MutableRefObject<T>ではすでに| nullのケースが削除されていることがわかります。 したがって、 useRef<number>(42)のケースはすでに正しく機能しています。 説明してくれてありがとう！

createRefで何をする必要がありますか？ 現在、不変のRefObject<T>を返します。これは、コードベースで問題を引き起こしています。これらを渡し、（可変の） useRef refオブジェクトと同じように使用したいからです。 createRefの入力を微調整して、可変のrefオブジェクトを形成できるようにする方法はありますか？

（そして、 ref属性はRefObject<T> Ref<T>であると定義されているため、すべてが不変になります。これは私たちにとって大きな問題です。 useRefからの参照、 forwardRef呼び出しを通じて不変であるという事実を利用することはできません。）

うーん...おそらく同じトリックを使用できますが、引数がない（そして常にnullで始まる）という理由だけで、条件付きタイプが必要になります。

: null extends T ? MutableRefObject<T> : RefObject<T>は、同じロジックを実行して使用する必要があります。 nullを入れたいと言った場合、それは可変ですが、そうでない場合でも、現在の意味では不変です。

それはとてもいい考えです。 createRefはパラメータを受け取らないため、おそらく常に| nullオプションを含める必要があります（ useRefとは異なります）。したがって、おそらくMutableRefObject<T | null>と言う必要がありますか？

私はどちらもTSで動作させることができませんでした。 これで構成されたTSプレイグラウンドは次のとおりです。
https://tinyurl.com/y75c32y3

タイプは常にMutableRefObjectとして検出されます。

forwardRefで何ができると思いますか？ refがRef<T>であると宣言しますが、これにはMutableRefObjectの可能性は含まれていません。

（問題を引き起こしているユースケースは、関数refまたはrefオブジェクトのいずれかであるrefの配列を受け取り、渡すことができる単一の結合されたref [関数ref]を作成するmergeRefs関数のユースケースです。次に、その結​​合されたrefは、関数refの場合は呼び出すか、refオブジェクトの場合は.currentを設定することにより、提供されたすべてのrefに着信参照要素を配信します。不変のRefObject<T>とMutableRefObject<T> in Ref<T>が含まれていないため、これは困難です。forwardRefとRefについて別々の問題を提起する必要があります。難しさ？）

上記の理由により、 useRefのタイプを変更していません（ただし、 createRefはまだ検討中です）が、その理由について質問がありますか？

https://github.com/DefinitelyTyped/DefinitelyTyped/issues/31065#issuecomment -457650501でカバーされているアイテムについて、別の問題を提起する必要がありますか？

はい、分けましょう。

null値で始まる可変refオブジェクトが必要な場合は、ジェネリック引数にも| nullを指定してください。 Reactではなく「所有」しているため、変更可能になります。

これをありがとう！ useRefジェネリックにnullを追加すると、問題が解決しました。

前

const ref = useRef<SomeType>(null) 

// Later error: Cannot assign to 'current' because it is a constant or a read-only property.

後

const ref = useRef<SomeType | null>(null)

forwardRefコンポーネントに関する別のコメントが作成されましたか？ 基本的に、参照を転送して現在の値を直接変更することはできません。これは、参照を転送するポイントの一部だと思います。

次のフックを作成しました。

export const useCombinedRefs = <T>(...refs: Ref<T>[]) =>
    useCallback(
        (element: T) =>
            refs.forEach(ref => {
                if (!ref) {
                    return;
                }

                if (typeof ref === 'function') {
                    ref(element);
                } else {
                    ref.current = element; // this line produces error
                }
            }),
        refs,
    );

そして、「読み取り専用のプロパティであるため、「current」に割り当てることができません」というエラーが表示されます。
currentを書き込み可能に変更せずにそれを解決する方法はありますか？

そのためには、ごまかす必要があります。

(ref.current as React.MutableRefObject<T> ).current = element;

はい、これは少し不健全ですが、この種の割り当てが偶然ではなく意図的なものであると私が考えることができる唯一のケースです-あなたはReactの内部動作を複製しているので、ルールを破らなければなりません。

createRefを変更して同じオーバーロードロジックを使用することもできますが、引数がないため、条件付きの型を返す必要があります。 | nullを含めると、$＃ MutableRefObjectが返されます。含めない場合は、（不変） RefObjectなります。

どうもありがとう

(ref.current as React.MutableRefObject<T>).current = element;

する必要があります：

(ref as React.MutableRefObject<T>).current = element;

Reactの内部動作を複製しています

これは、ここのドキュメントが古くなっていることを意味しますか？ これは、内部の動作ではなく、意図されたワークフローとして明確に説明されているためです。

その場合のドキュメントは、所有している参照を参照していますが、HTML要素にref属性として渡す参照の場合は、読み取り専用である必要があります。

function Component() {
  // same API, different type semantics
  const countRef = useRef<number>(0); // not readonly
  const divRef = useRef<HTMLElement>(null); // readonly

  return <button ref={divRef} onClick={() => countRef.current++}>Click me</button>
}

私の悪い、さらに上にスクロールする必要があります。 私が所有している参照に対してreadonlyに関するエラーが発生し、それが同じケースであると想定しました。 （現在、別のワークフローを使用しており、残念ながらエラーを再現できません...）

とにかく、説明ありがとうございます！

トピックのcreateRefの部分が移動したかどうかはわかりませんが、ここにも投稿します。

私はReactNative（React Navigation）用の人気のあるナビゲーションライブラリを使用しています。 そのドキュメントでは、通常、 createRefを呼び出してから、参照を変更します。 これは、Reactがそれらを管理していないためだと確信しています（DOMはありません）。

React Nativeのタイプは異なる必要がありますか？

参照： https ：//reactnavigation.org/docs/navigating-without-navigation-prop

@sylvanaar
ナビゲーションを初期化するときにもこの問題に直面しましたが、解決策を見つけましたか？

私が今読んだことを要約すると： createRef<T>によって作成されたrefに値を設定する唯一の方法は、それを使用するたびにそれをキャストすることですか？ その背後にある理由は何ですか？ その場合、 readonlyは、refへの値の設定を実質的に妨げているため、関数の目的全体が無効になります。

TLDR：初期値がnull （詳細：または型パラメーター以外のもの）の場合、型パラメーターに| nullを追加すると、 .currentが可能になります。通常のように割り当てられます。