Typescript: JSXの「このエラーメッセージを無視する」コード修正により、 `// @ ts-ignore`がレンダリングされます

注意：新しい抑制フォーム（つまり、インライン）を追加しない限り、これに対する唯一の修正は、有効な抑制位置を生成できない場合にクイックフィックスを無効にすることです。

（私たちが本当に次のようなことを考えない限り

{/* 
  // @ts-ignore */}

大丈夫ですか？）

新しい抑制フォームを追加したり、特定のエラーをターゲットにするためのサポートを追加したりするのは素晴らしいことです。 ただし、それがない場合は、JSX構造のエラーを無視する機能が必要なため、その奇妙なコメントフォームを使用します。 それはきれいではありませんが、それが機能する唯一のものです。 したがって、修正では、（1）この形式に含めるか、（2）まったく含めない（レンダリングされない）可能性があります。 私は（1）が好きですが、機能的には正しいのできれいではありません。ルールがJSXコンポーネントの本体のエラー以外のすべてを無視できるとしたら、それは間違っているように見えます。 さらに、テンプレート文字列内の奇妙に見える無視コメントにはいくつかの前例があります。 例えば、

const s = `
Hello ${doesnotexist}`;

修正される-として無視される

const s = `
Hello ${
// @ts-ignore
doesnotexist}`;

{/* 
  // @ts-ignore */}

素晴らしい🌹

他の人が使用している別のパターンはありますか？

これは本当に奇妙な構文です

{/* 
  // @ts-ignore */}

上記の編集は実際には機能しません。

今日、人々はTSXファイル内のタイプスクリプトエラーをどのように無視していますか？ 私はたくさんの研究をしましたが、うまくいく単一の解決策を見つけることができません。 一部のステートメントを無視できないことは、大きな課題です。

動作する別の（奇妙な）バリエーション：

<
// @ts-ignore
SomeComponent />

（私たちが本当に次のようなことを考えない限り

{/* 
  // @ts-ignore */}

大丈夫ですか？）

あなたはなんて賢いのでしょう！

上記の編集は実際には機能しません。

今日、人々はTSXファイル内のタイプスクリプトエラーをどのように無視していますか？ 私はたくさんの研究をしましたが、うまくいく単一の解決策を見つけることができません。 一部のステートメントを無視できないことは、大きな課題です。

Typescript 3.6.2で.tsxします

（私たちが本当に次のようなことを考えない限り

{/* 
  // @ts-ignore */}

大丈夫ですか？）

ええ、それらすべてのリンティングルールはその構文にとても満足しています

今これを行う：neutral_face：

    <   // eslint-disable-line react/jsx-tag-spacing
        // @ts-ignore
    Component/>

prettierは属性を別の行に保持するため、typescript 3.7をprettierと組み合わせてさらに楽しくなりました。現在、@ ts-ignoreは、タグの先頭ではなく、プロパティの直前に配置する必要があります。

これが私が持っている回避策です：

{/* lol https://github.com/Microsoft/TypeScript/issues/27552#issuecomment-495830020
      // @ts-ignore */ /* prettier-ignore */}
    <MyComponent foo={{
        a: 'prop',
        with: 'lots a',
        big: 'object',
        that: 'forces',
        prettier: 'to wrap',
      }}
    />

以前：

    {/* lol https://github.com/Microsoft/TypeScript/issues/27552#issuecomment-495830020
      // @ts-ignore */}
    <MyComponent
      foo={{
        a: 'prop',
        with: 'lots a',
        big: 'object',
        that: 'forces',
        prettier: 'to wrap',
      }}
    />

よりきれいな人が過度のスプレッドについても不平を言うかどうかはわかりませんが、

    <MyComponent
      {...{}/* lol https://github.com/Microsoft/TypeScript/issues/27552#issuecomment-495830020
      // @ts-ignore */}
      foo={{
        a: 'prop',
        with: 'lots a',
        big: 'object',
        that: 'forces',
        prettier: 'to wrap',
      }}
    />

また動作する必要がありますか？ ただし、ある時点で、よりきれいな無視がより良い選択です。 jsx内のコメントの場所には多くのオプションがありません。

なぜこれが閉鎖されているのですか？ 醜い解決策にコミットしただけですか？

再開してください...

醜い解決策にコミットしただけですか？

うん。 クイックフィックスは今や醜いことをします。 「かわいさ」は、すべての権利によって例外的な出来事であるはずの抑圧に関しては問題ではありません。 私たちはjsx構文が許可するものにかなりロックされているので、それが実際に何であるかです。

私たちは間違いなく醜い解決策に取り組んでいます...しかしそうではないかもしれません。

これをオープンに保つことに投票/同意できますか？ 自由な時間にこれに取り組みたいのですが、現在の解決策が好ましい選択肢である場合は時間を無駄にしたくありません。

同意しました。 私が依存しているサードパーティのライブラリの最新のコードの入力が間違っているため、現在、あいまいなソリューションを使用しています。 醜い解決策は今のところ機能しますが、可能であればワンライナーを用意するとよいでしょう。

残念ながら、jsxでコメントを取得する方法は他にありません。 {}以内にする必要があります。

これの可能性を追跡するための別の問題はありますか？

{/* @ts-ignore */}
{whatever}

私たちは今それを開いているように聞こえます： https ：
ここでのPR： https ：//github.com/microsoft/TypeScript/pull/38228🎉

個人的には

{/* @ts-ignore */}
{whatever}

これに対する最良かつ最も普遍的なソリューションです。

自動フォーマットツール（よりきれいなど）は、ハックの下で台無しになる可能性があります。

注意：
このソリューションは正常に機能しています

{/* 
  // @ts-ignore */}

この間

<
// @ts-ignore
SomeComponent />

自動フォーマットされて無効になります（少なくとも私のきれいな設定では）

＃38228の成功に基づいて、これは3.9に着陸したと思います：tada：

これはJSXの問題だと思いますが、これを確認してください。

私がこれを持っているとしましょう：

import * as React from 'react';

declare var SomeComponentFromLibrary: React.FC<{
    children?: React.ReactElement
}>;

declare var MyComponent: React.FC<{
    foo: string,
}>;

export default () => (
    <SomeComponentFromLibrary>
        {/* @ts-expect-error */}
        <MyComponent />
    </SomeComponentFromLibrary>
)

SomeComponentFromLibrary変更できません。 <MyComponent />生成するエラーを抑制したいと思います。

ただし、 SomeComponentFromLibraryの子に別の要素を追加すると、 children?: React.ReactElement型の制約が解除され、別の型エラーが発生します。

コードに変換されないコメントをJSXで作成することは可能ですか？