Typescript: Die Codekorrektur "Diese Fehlermeldung ignorieren" in JSX führt zum Rendern von "// @ ts-ignore"

Erstellt am 4. Okt. 2018  ·  22Kommentare  ·  Quelle: microsoft/TypeScript


TypeScript-Version: 3.2.0-dev.20181004


Suchbegriffe:

disableJsDiagnostics
JSX
Code korrigieren
Ignorieren Sie diese Fehlermeldung
Fügen Sie allen Fehlermeldungen '@ ts-ignore' hinzu

Code

// MyComponent.jsx
// @ts-check
import React from "react";

class MyComponent extends React.Component {
  render() {
    return (
      <div>
        // @ts-ignore
        {doesNotExist}
      </div>
    );
  }
}

export default MyComponent;

Wenn Sie den Code-Fix Ignore this error message oder Add '@ts-ignore' to all error messages ausführen, wird ein // @ts-ignore eingefügt, der den Compiler zufriedenstellt.

Aber,

<div>
  // @ts-ignore
  {doesNotExist}
</div>

wird tatsächlich // @ts-ignore rendern.

Erwartetes Verhalten:

Es sieht so aus, als würden {/* @ts-ignore */} oder {/* // @ts-ignore */} nicht als gültige Ignorierkommentare erkannt.

Das Beste, was ich mir einfallen lassen kann, ist

<div>
  {/* 
  // @ts-ignore */}
  {doesNotExist}
</div>

Tatsächliches Verhalten:

// MyComponent.jsx
// @ts-check
import React from 'react';

class MyComponent extends React.Component {
  render() {
    return (
      <div>
        // @ts-ignore
        {doesNotExist}
      </div>
    );
  }
}

export default MyComponent;

wo // @ts-ignore fälschlicherweise gerendert wird.

Verwandte Themen:

https://github.com/Microsoft/TypeScript/issues/25240

Bug JSTSX Quick Fixes

Hilfreichster Kommentar

(es sei denn, wir denken wirklich so etwas

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

ist in Ordnung?)

Alle 22 Kommentare

Bitte beachten Sie: Sofern wir keine neuen Unterdrückungsformulare (dh Inline) hinzufügen, besteht die einzige Lösung darin, den Quickfix zu deaktivieren, wenn keine gültige Unterdrückungsposition erstellt werden kann.

(es sei denn, wir denken wirklich so etwas

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

ist in Ordnung?)

Es wäre fantastisch, neue Unterdrückungsformulare hinzuzufügen und sogar die Ausrichtung auf bestimmte Fehler zu unterstützen. Wenn dies nicht der Fall ist, werden wir dieses seltsame Kommentarformular verwenden, da wir die Fähigkeit benötigen, Fehler in JSX-Konstrukten zu ignorieren. Es ist nicht schön, aber es ist das einzige, was funktioniert. Das Update könnte es also entweder (1) in dieser Form oder (2) überhaupt nicht enthalten (damit es nicht gerendert wird). Ich mag (1), obwohl es nicht schön ist, weil es funktional korrekt ist - es scheint aus zu sein, wenn die Regel alles außer Fehlern im Hauptteil einer JSX-Komponente ignorieren könnte. Darüber hinaus gibt es einige Präzedenzfälle für seltsam aussehende Ignorierkommentare in Vorlagenzeichenfolgen. Zum Beispiel,

const s = `
Hello ${doesnotexist}`;

wird fix-ignoriert als

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

genial 🌹

Gibt es ein anderes Muster, das andere verwenden?

Das ist wirklich sehr, sehr seltsame Syntax

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

Bearbeiten Sie die oben genannten funktioniert nicht wirklich.

Wie ignorieren Leute heute Typoskriptfehler in TSX -Dateien? Ich habe eine Menge recherchiert und kann keine einzige Lösung finden, die funktioniert. Eine Aussage nicht ignorieren zu können, ist eine große Herausforderung.

Eine andere (seltsam aussehende) Variante, die funktioniert:

<
// @ts-ignore
SomeComponent />

(es sei denn, wir denken wirklich so etwas

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

ist in Ordnung?)

wie schlau du bist !!!

Bearbeiten Sie die oben genannten funktioniert nicht wirklich.

Wie ignorieren Leute heute Typoskriptfehler in TSX -Dateien? Ich habe eine Menge recherchiert und kann keine einzige Lösung finden, die funktioniert. Eine Aussage nicht ignorieren zu können, ist eine große Herausforderung.

Funktioniert für .tsx mit Typescript 3.6.2

(es sei denn, wir denken wirklich so etwas

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

ist in Ordnung?)

Ja, all diese Flusenregeln werden sich über diese Syntax so freuen

Tun Sie dies jetzt: neutral_face:

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

Ich habe in Typoskript 3.7 in Verbindung mit Prettier noch mehr Spaß gehabt, weil Prettier die Attribute in einer separaten Zeile hält und jetzt @ ts-ignore unmittelbar vor der Eigenschaft positioniert werden muss, nicht am Anfang des Tags.

Hier ist die Problemumgehung, die ich habe:

{/* 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',
      }}
    />

vorher:

    {/* 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',
      }}
    />

Keine Ahnung, ob sich hübscher auch über übermäßige Spreads beschweren wird, aber

    <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',
      }}
    />

sollte auch funktionieren? Irgendwann ist das schönere Ignorieren jedoch einfach die bessere Wahl. Es gibt einfach nicht viele Optionen für Kommentarpositionen in jsx.

Warum ist das geschlossen? Haben wir uns gerade für die hässliche Lösung entschieden?

bitte wieder öffnen ...

Haben wir uns gerade für die hässliche Lösung entschieden?

Ja. Der Quickfix macht jetzt das Hässliche. "Hübschheit" ist kein Problem, wenn es um Unterdrückungen geht, die auf jeden Fall außergewöhnliche Ereignisse sein sollten. Wir sind ziemlich davon überzeugt, was die jsx-Syntax erlaubt, also ist es wirklich das, was es ist.

Wir haben uns definitiv der flüchtigen Lösung verschrieben ... aber vielleicht auch nicht.

Können wir darüber abstimmen / uns darauf einigen, dies offen zu halten? Ich würde das gerne in meiner Freizeit angehen, möchte aber keine Zeit verschwenden, wenn die aktuelle Lösung die bevorzugte Option ist.

Einverstanden. Ich verwende derzeit die flüchtige Lösung, da eine Bibliothek eines Drittanbieters, auf die ich mich verlasse, im neuesten Code falsche Eingaben enthält. Fugly-Lösung funktioniert vorerst, aber es wäre gut, wenn möglich einen Einzeiler zu haben.

Leider gibt es keine andere Möglichkeit, einen Kommentar in jsx zu erhalten. Es muss innerhalb von {} .

Gibt es ein separates Problem, um die Möglichkeit zu verfolgen?

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

Persönlich denke ich

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

ist die beste und universellste Lösung dafür.

Werkzeuge zur automatischen Formatierung (hübscher usw.) können unter Hacks versagen.

Hinweis:
Diese Lösung funktioniert gut

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

während dies

<
// @ts-ignore
SomeComponent />

wird automatisch formatiert und wird ungültig (zumindest in meinen hübscheren Einstellungen)

Basierend auf dem Erfolg von # 38228 denke ich, dass dies in 3.9 gelandet ist: tada:

Ich denke, dies ist eher ein JSX-Problem, aber sehen Sie sich das an:

Nehmen wir an, ich habe Folgendes :

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 Ich kann mich nicht ändern und möchte den Fehler unterdrücken, den <MyComponent /> erzeugt.

Wenn Sie jedoch den untergeordneten Elementen des SomeComponentFromLibrary weiteres Element hinzufügen, wird die Typbeschränkung children?: React.ReactElement aufgehoben, was zu einem weiteren Typfehler führt.

Ist es möglich, in JSX Kommentare zu erstellen, die nicht in Code umgewandelt werden?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen