Ich mag die Gegenwehr von Katie Kodes hier. Ich habe in der Vergangenheit gesagt, dass ich nicht glaube, dass serverseitige Sprachen "komponentenhaftes Bauen" so gut beherrschen wie JavaScript, aber hey, das ist ein guter Punkt
1. Jedes grundlegende HTML-Fragment "Komponente", das Sie mit JSX in einer Datei definieren und dann als
<MyComponent key="value" />referenzieren können, können Sie genauso einfach mit Liquid in einer Datei definieren und in Jekyll als{% include MyComponent.html key=value %}referenzieren.2. Jedes grundlegende HTML-Fragment "Layout", das Sie mit JSX in einer Datei definieren und dann als
<MyLayout>Hallo, Welt</MyLayout>referenzieren können, können Sie genauso einfach mit Liquid in einer Datei definieren und dann im Front Matter einer Jekyll-Vorlage alslayout: MyLayoutreferenzieren.
Jeder HTML-Präprozessor, der Partials mit lokalen Variablen verarbeiten kann, kommt der Replikation des Besten von zustandslosen JavaScript-Komponenten ziemlich nahe. Die Grenze verschwimmt noch weiter mit Dingen wie Eleventy Serverless, das einzelne Seiten bei Bedarf durch Aufrufen einer Cloud-Funktion erstellen kann.
Das ist aber der Punkt. "Zustandslos". Sobald Sie JavaScript benötigen, um den Zustand der Komponente nach einem Ereignis zu ändern, erkennen Sie, wie viel schöner es gewesen wäre, die Komponente einfach deklarativ in JavaScript zu schreiben.
Nicht um Templating/HTML-Preprocessing schlechtzureden. Ich schreibe beruflich jeden Tag "Komponenten" in Twig, und meistens ist es ziemlich großartig. Aber das Schreiben des Anfangszustands einer Komponente, die Berücksichtigung von Props und dann die Verwendung traditioneller imperativer DOM-Manipulation zur Handhabung von Zustandsänderungen von dort aus ist genau der unübersichtliche Knackpunkt, auf den meiner Meinung nach angespielt wird, wenn das Gefühl "Jekyll (et al.) kann keine Komponenten" ausgedrückt wird.
Wenn Sie nur zustandslose Komponenten benötigen, ist das großartig. Aber eigentlich ist es die *Zustandhaftigkeit*, die den Dreh- und Angelpunkt der Konversation darstellt.
Ich stimme zwar zu, dass "Komponente" eher ein Begriff für eine Denkweise über das Design/die Architektur von Teilen eines Projekts ist. Aber wenn es zustandslos ist, ist die tatsächliche Datei, die Sie weitergeben, einfach eine Vorlage. Das Wort "Komponente" bezieht sich meiner Meinung nach auf die Denkweise *und* die tatsächliche Datei, die Sie schreiben, sobald Sie Zustandhaftigkeit einführen. Nochmals, nicht um auf Kosten anderer zu profitieren; ich mag es wirklich, komponentenbasiertes Design in Twig zu machen. Aber die Unterscheidung ist nützlich.
Ein Teil von mir denkt, nun ja, wenn diese kleinen Teile dann zu Web Components würden, dann bekämen wir auch die Interaktivitäts-Bits. Und bald könnten wir die Stile mit @scope versehen, und immer mehr bekommen wir, was wir wirklich von "Komponenten" wollen.