Feliz: String-Überladungen zu CSS-Eigenschaften für benutzerdefinierte Rohwerte hinzufügen

Erstellt am 11. Nov. 2019  ·  15Kommentare  ·  Quelle: Zaid-Ajaj/Feliz

Endlich mehr mit Feliz selbst spielen. Mir sind ein paar Dinge aufgefallen, die geändert werden sollten/könnten:

Einige Eigenschaften sind zu streng. Wenn ich beispielsweise Material-UI verwende und box-shadow festlegen möchte, kann ich es nicht durch boxShadow festlegen, da die Überladungen nur int- und int-Tupel akzeptieren. MaterialUI theme.shadows ist ein Array von Strings und die allgemeine Verwendung ist wie folgt:

Styles.create [ style.custom ("box-shadow", (theme.shadows.[5])) ]

Ich bin mir nicht sicher, ob dies so angepasst werden sollte, dass alle Stil-Requisiten eine Zeichenfolge akzeptieren oder sie einfach style.custom ausführen lassen, wenn diese Art von Einstellung ausgeführt wird. @cmeeren Gedanken?

Mir ist auch aufgefallen, dass outline und justify-content komplett fehlen.

Feliz enhancement good first issue

Hilfreichster Kommentar

Feliz existiert für das Entwicklerglück. Wenn Entwickler es lieber missbrauchen, als die typsicheren Überladungen zu verwenden – nicht dass ich unbedingt denke, dass sie es sind – sollten wir sie wirklich stoppen?

Ich stimme zu, ist eigentlich kein Problem, aber ich möchte vorsichtig sein, zu viele Dinge hinzuzufügen, die einen in den Fuß schießen lassen. In diesem Zusammenhang ist es definitiv nicht der Fall.

Alle 15 Kommentare

Entschuldigung, ich bin verloren. Grundlegende CSS-Requisiten haben nichts mit MUI zu tun. Feliz hat Recht, sie nach der CSS-Spezifikation zu modellieren. Wenn Sie sagen, dass MUI ein Array von Zeichenfolgen verwendet, was meinen Sie damit? AFAIK CSS hat kein Konzept eines Arrays. Könnten Sie CSS-Requisiten mit Komponenten-Requisiten mischen?

Nun, es ist nur ein Array von Strings, auf die ich wie im obigen Ausschnitt über einen Index zugreife. Ja, ich stimme zu, dass Feliz eine Bibliothek nicht speziell berücksichtigen sollte. Meine Frage war, ob die Dinge zurückgreifen sollten, um String-Eingaben für diese Requisiten zu ermöglichen.

Oh, richtig. Du meinst das :

image

Ja, vielleicht sollte Feliz' boxShadow gelockert werden?

Siehe übrigens diese Seite . Ich habe keine Ahnung, was sie damit meinen, aber vielleicht gibt es eine andere Möglichkeit, das Array shadows des Themas in MUI zu verwenden, indem der Index in einer Eigenschaft boxShadow (nicht im Stil) angegeben wird?

Sieht leider nicht so aus, als ob Fade diese Stütze unterstützt, wofür ich diese spezielle Eigenschaft verwende.

Ich habe diese Requisite für keine Komponenten gesehen, und ich habe auch nicht die Box Komponente gesehen, die sie auf der Seite verwenden, die ich auch verlinkt habe, weshalb ich verwirrt bin. Nur der Einfachheit halber könnten Sie versuchen, eine benutzerdefinierte "boxShadow" oder "box-shadow" Requisite für eine beliebige Komponente festzulegen und zu sehen, was funktioniert.

Auf jeden Fall sollte die "Schatten"-Dokumentenseite wirklich verbessert werden.

Ja, vielleicht sollte Feliz' BoxShadow gelockert werden?

Im Idealfall sollte es nicht sein, denn dafür gibt es style.custom . Da wir über diese Reaktion sprechen, denke ich, dass es boxShadow . Aber auch hier sollte eine string Überladung nicht schädlich sein. ich werde darüber nachdenken

Mit einer Basis-String-Überladung für alles können die Leute dasselbe wie style.custom tun, ohne nachschlagen zu müssen oder sich an den tatsächlichen CSS-Namen zu erinnern. Eine Option wäre, etwas wie style.boxShadow.custom damit sie immer noch wissen, dass sie die typischen Anwendungsfälle für diesen Stil verlassen.

Mit einer Basis-String-Überladung für alles können die Leute dasselbe wie style.custom tun, ohne nachschlagen zu müssen oder sich an den tatsächlichen CSS-Namen zu erinnern.

Hm, eigentlich keine schlechte Idee. Ich meine, wir wollen auf jeden Fall die Typensicherheit fördern. Aber in CSS ist sowieso alles ein String, und es wäre schön, manchmal eine Fluchtluke für "schnelles und schmutziges" Zeug zu haben oder, wie

Ich bin nicht überzeugt, dass es eine gute Idee ist, String-Überladungen für alle Stilattribute zu haben, aber es ist zumindest etwas, das man in Betracht ziehen sollte.

Wie wäre es mit allen bekannten Stilnamen, die an style.custom angehängt sind, um zu vermeiden, dass einzelnen Stilen Überladungen zugewiesen werden müssen.

style.custom.boxShadow "3px 3px red, -1em 0 0.4em olive"
style.custom.transition "margin-right 4s ease-in-out 1s"
style.custom("-webkit-text-stroke", "4px navy") // keep original custom fallback too

Ich bin nicht überzeugt, dass es eine gute Idee ist, String-Überladungen für alle Stilattribute zu haben, aber es ist zumindest etwas, das man in Betracht ziehen sollte.

@cmeeren Die Verwendung einer externen Bibliothek, die Daten für einen Stil bereitstellen könnte, wird style.custom ("..", someLibraryThing)

Wie wäre es mit allen bekannten Stilnamen, die an style.custom angehängt sind, um zu vermeiden, dass einzelnen Stilen Überladungen zugewiesen werden müssen.

@zanaptak Ich mag diese Idee auch, ich bin mir nicht sicher, ob das besser oder schlechter ist als das, was ich für die

Die Verwendung einer externen Bibliothek, die Daten für einen Stil bereitstellen könnte, wird mühsam sein, wenn sie direkt an den Stil bereitgestellt werden sollen

Wahr.

Ich denke, die einfachste Lösung ist, einfach eine string Überladung für alle Stil-Requisiten zu haben. Der String-Parameter könnte rawValue oder ähnlich heißen, um deutlich zu machen, dass Sie auf sich allein gestellt sind.

Ich denke, die einfachste Lösung ist, einfach eine String-Überladung für alle Stil-Requisiten zu haben. Der String-Parameter könnte rawValue oder ähnlich heißen, um deutlich zu machen, dass Sie auf sich allein gestellt sind.

@cmeeren Ich denke, dieser ist gut und ist eine natürliche Erweiterung der bereitgestellten Überladungen, aber ich befürchte, dass, wenn wir nur style.boxShadow(rawValue: string) es viel missbraucht wird, anstatt den Code in der empfohlenen typsicheren Weise zu schreiben. Ich mag auch den Ansatz von @zanaptak, weil er von der Verwendung von Rohwerten für CSS style.boxShadow(rawValue: string) und ich könnte mir vorstellen, dass mehr Leute dieses Maß an Leichtigkeit beim Schreiben der benutzerdefinierte Werte.

Beide Ansätze sind gut und haben gute Gründe. Ich persönlich tendiere eher zum früheren Ansatz von style.boxShadow(rawValue: string) .

Tut mir leid, dass ich diese Woche wegen der Arbeit nicht in der Lage war, viele Probleme rund um Feliz/Feliz.Mui zu besprechen/zu beheben genial)

es wird viel missbraucht, anstatt den Code in der empfohlenen typsicheren Weise zu schreiben

Feliz existiert für das Entwicklerglück. Wenn Entwickler es lieber missbrauchen, als die typsicheren Überladungen zu verwenden – nicht dass ich unbedingt denke, dass sie es sind – sollten wir sie wirklich stoppen?

Auf jeden Fall scheinen wir uns alle mehr oder weniger auf eine rawValue: string Überladung für alle Stil-Requisiten einig zu sein. :)

Feliz existiert für das Entwicklerglück. Wenn Entwickler es lieber missbrauchen, als die typsicheren Überladungen zu verwenden – nicht dass ich unbedingt denke, dass sie es sind – sollten wir sie wirklich stoppen?

Ich stimme zu, ist eigentlich kein Problem, aber ich möchte vorsichtig sein, zu viele Dinge hinzuzufügen, die einen in den Fuß schießen lassen. In diesem Zusammenhang ist es definitiv nicht der Fall.

Ich möchte vorsichtig sein, zu viele Dinge hinzuzufügen, mit denen Sie sich selbst in den Fuß schießen können.

Absolut mit dir dabei 👍

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen