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.
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 :
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 👍
Hilfreichster Kommentar
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.