Wie man diese Komponente definiert, muss bestimmte Requisiten haben, aber auch zusätzliche Requisiten erlauben

8

Ich übergebe eine Komponente als Requisite.

Dies ist wie folgt definiert.

%Vor%

Das funktioniert gut, aber ich möchte diese Definition aktualisieren, um zu sagen, dass zumindest über Requisiten bestehen sollte, aber um zusätzliche Requisiten zu erlauben.

Gibt es eine Definition, die ich dafür verwenden kann? Zum Beispiel möchte ich, dass eine Komponente mit der folgenden Signatur akzeptiert wird.

%Vor%

Ich habe versucht, sie als Schnittstelle zu definieren, aber sie werden immer noch abgelehnt.

%Vor%

Aktualisieren

Ich denke, das die Probleme demostrates Ich habe Link-

Update 2

@Rajesh ‚s Lösung scheint nicht zu funktionieren, haben hier versucht

    
Tom 30.01.2018, 15:21
quelle

5 Antworten

0

Die Hilfe, die ich brauchte, wurde von Rajesh gepostet, der ihre Antwort gelöscht hat.

Die Antwort war add [key: string]: any auf den Typ.

%Vor%

Dies funktioniert nicht mit einer Schnittstelle, aber mit dem Typ.

Ein Beispiel für diese Arbeiten ist hier: Link-

    
Tom 02.02.2018, 13:30
quelle
1

Was ich in solchen Fällen getan habe, ist Props als eine Vereinigung von TableProps und pro-Komponenten-Requisiten zu definieren:

%Vor%

In diesem Fall würde ich TableProps als Objekttyp beibehalten, nicht als Schnittstelle.

Es ist auch möglich, Schnittstellen zu verwenden, wenn sowohl TableProps als auch Props als Schnittstellen wie folgt definiert sind:

%Vor%

Ich denke, Flow könnte es leichter haben mit der Schnittstellenlösung. Aber ich habe keine besonderen Beweise, um diese Vermutung zu stützen.

    
Jesse Hallett 30.01.2018 17:57
quelle
1

Sie können etwas wie folgt ausprobieren:

%Vor%

Was das bedeutet, wird Sie zwingen, die Eigenschaften value und propName im Objekt zu übergeben, aber Sie können auch andere Eigenschaften haben.

Probe

    
Rajesh 02.02.2018 10:09
quelle
1

Das Problem läuft tiefer als es scheint. Es ist etwas gekünstelt, kann aber durch Anonymisierung der Typnamen hervorgehoben werden, wie hier getan.

%Vor%

Der obige Code erzeugt den folgenden Fehler.

%Vor%

Was sagt es?

  • Wir versuchen, eine Variable g vom Typ FooFn einem Wert f .
  • zuzuweisen
  • Die Funktionsdeklaration für f gibt ihr den Typ (Bar) => any .
  • FooFn ist wirklich nur (Foo) => any .

Das verursacht das Problem: Der LHS-Typ ist nicht derselbe wie der RHS-Typ. Wir können sagen, dass g erweitert f , in der Weise, dass g ein Argument die Erweiterung f übernimmt. Diese Art der Beziehung wird Kontravarianz genannt. Sie können mehr darüber hier lesen. Ich würde auch empfehlen, einen Teil von einem Vortrag <8:12 bis 09:10 zu sehen.

Um ehrlich zu sein, kann Flow keine kontravarianten Beziehungen erfassen (siehe hier und hier ).

Was können Sie tun?

Nicht viel, wirklich. Alle Optionen, die Sie haben, sind unangenehm, um es gelinde auszudrücken.

  1. Unterdrückt den Fluss mit // $FlowFixMe comments (siehe hier ).

  2. Definieren Sie Ihre Funktionen f und g so, dass sie nicht kontravariant sind (kann schwierig sein, kann sogar unmöglich sein).

  3. Deklarieren Sie Ihre Typen unabhängig voneinander, d. h. D o R Wiederholen Sie Y selbst.

  4. Probieren Sie einen Hack aus, der die Verwendung eines statischen Typprüfers als , der von Tom beantwortet wurde, untergräbt und wie hier getan.

Ihr Anruf.

    
zhirzh 03.02.2018 07:08
quelle
0

Vielleicht könnte das helfen.

%Vor%     
japesh singhal 03.02.2018 08:33
quelle

Tags und Links