Vue: Kindern erlauben, für Eltern registrierte Komponenten zu „erben“.

Irgendein realer Anwendungsfall?

Registrieren Sie in kleinen Anwendungsfällen einfach alles global; In großen Apps ist es viel einfacher zu warten, wenn jede Komponente explizit davon abhängt, was sie benötigt. Es mag in manchen Situationen nützlich sein, aber die Vorteile gehen mit einem globalen Kompromiss einher. Die Idee hinter 1.0 ist, dass "wenn etwas nur geringfügig nützlich ist oder negative Auswirkungen auf die Wartbarkeit hat, entfernen wir es."

Ja. Meine Anwendung hat ein Popup-Fenster mit einer komplexen Struktur aus benutzerdefinierten Editorelementen. Diese Elemente können in einer 3–4-Ebenen-Hierarchie kombiniert werden, was es ineffizient macht, sie explizit für jedes übergeordnete Element zu deklarieren (3–5 übergeordnete Typen * 10 deklarierte Elemente = 50 Zeilen sich wiederholenden Codes). Und es ist auch nicht gut, sie global zu registrieren, da sie niemals in anderen Teilen der Anwendung erscheinen werden. Ich würde sie also gerne "lokal" laden.

Sie explizit zu importieren, ist eine lohnende Wiederholung. Es ermöglicht Ihnen, jede Komponente in dieser Hierarchie einzeln zu betrachten und zu verstehen, woher ihre Abhängigkeiten stammen. Mit implizitem Fallback werden Sie sich 3 Monate später nicht mehr daran erinnern, wo Sie diese Komponenten in die Hierarchie importiert haben.

@yyx990803 Ich habe ein gutes Gedächtnis, danke. Ich werde mich also daran erinnern, dass meine App aus zwei sehr unterschiedlichen Teilen besteht, von denen jeder einen genau definierten Satz von spezifischen Komponenten registriert. Daher hätte ich lieber die Wahl, wo ich meine Assets laden möchte (und ich vermute, dass das Gleiche mit benutzerdefinierten Anweisungen und Filtern passiert ist).

Lassen Sie mich meinen Eindruck teilen. Ich habe mit 0.12.x gearbeitet und es lief SEHR gut (abzüglich einiger kleiner Dinge in der Lernkurve). Minimalistische und saubere API, Syntax, zuverlässiger Code. Jetzt sind wir bei 1.0.0-beta und es wurde SCHLECHTER, nicht besser. Mehr Code-Wiederholung, entfernte Funktionen, die ich verwende, was dazu führt, dass ich denselben Code immer wieder neu schreibe. Ich fange an zu glauben, dass ich einen Fehler gemacht habe, Vue statt React zu wählen, weil ich nicht sicher bin, ob es in Zukunft keine Breaking Changes und Zeitverschwendung mehr geben wird.

@Karevn

1. Es wäre viel hilfreicher, wenn Sie zusätzlich zu diesem Problem tatsächlich die spezifischen Dinge auflisten würden, die die Entwicklererfahrung verschlechtert haben.
2. 1.0.0-alpha sind Vorabversionen, was bedeutet, dass es überhaupt keine API-Stabilitätsgarantie gab. Wenn Sie Wert auf Stabilität legen, sollten Sie bei 0.12 bleiben und auf Stable 1.0 warten (das auch eine endgültige Migrationsversion haben wird). Die Verwendung einer Vorabversion bedeutet, dass Sie zugestimmt haben, mit ständigen Breaking Changes umzugehen.
3. 1.0.0-beta ist noch nicht einmal veröffentlicht. Es ist wahrscheinlich keine gute Idee, einen nicht veröffentlichten, in Arbeit befindlichen Zweig zu verwenden.
4. Ich entwerfe die API basierend auf meinen Erfahrungen und dem Feedback der gesamten Community. Sie haben Anspruch auf alles, was Sie denken, und können jederzeit zu anderen Frameworks wechseln, wenn die Änderungen nicht in eine Richtung gehen, die Ihnen gefällt. (Tatsächlich müssen Sie in React auch alles explizit importieren und noch mehr Zeug wiederholen.)

1. Nachdem ich die Diskussion Nr. 1170 gelesen habe, bin ich jetzt fast einverstanden. Aber .. Ich sehe wirklich keinen Sinn darin, bestehenden Code zu entfernen, der diese Funktion bereitstellt, anstatt einfach strict: true zum Standard zu machen. Die Geschmäcker sind verschieden, und einige Leute bevorzugen einen „Fallback“-Ansatz, der manchmal intuitiver ist. Vor allem, wenn Komponenten dynamisch geladen werden. Es kann mit Mixins, Fabriken usw. umgangen werden, aber das alles kostet wertvolle Zeit.
2. Sichere Sache. Aber es gibt immer ein Gleichgewicht zwischen der „idealen Architektur“ und den Kosten von Änderungen. In diesem Fall haben mich ein paar Codezeilen (nämlich: ungefähr 10) die niemandem schaden würden, wenn sie übrig blieben, viel Zeit gekostet. Und ich muss diese instabile Version verwenden, da ich wirklich die Funktion "Lese-Schreib-Bindungsfilter" benötige, die wahrscheinlich nicht auf 0.12.x zurückportiert werden
3. Siehe 2.
4. Die Frage ist nicht "welche API bevorzuge ich". Ich bevorzuge VUE. Zeitraum. Die Frage ist „ob ich mich langfristig auf die Vue API verlassen kann“. Zuverlässigkeit über Schönheit. Wenn Änderungen brechen, sollte es einen ernsthaften Grund dafür geben. Im Fall der neuen Bindungssyntax, die meinen GESAMTEN Code kaputt gemacht hat - okay, lass es sein, es ist besser lesbar und erzwingt eine bessere Codestruktur. In diesem Fall - nein. Diese Änderung ist möglicherweise nicht unterbrechend, da options.strict = true standardmäßig festgelegt ist.

Ja, ein Upgrade ist immer mit dem Schmerz des Refactorings verbunden, aber 1.0 ist die einzige Chance für Vue, sich von diesen veralteten Konfigurationsoptionen zu befreien. Nach 1.0 wird es streng semver sein, und bis 2.0 sollte nichts kaputt gehen. Und ich möchte, dass 1.x so lange wie möglich hält, wegen des Zuverlässigkeitsproblems, über das Sie gesprochen haben.

In Bezug auf den strikten Modus: Es kostet sicherlich Refactoring-Zeit, wenn Sie sich stark darauf verlassen haben - aber idealerweise müssen neue Benutzer, die Vue nach 1.0 verwenden, nicht einmal wissen, dass dieses Ding existiert. Die API-Oberfläche sollte so klein wie möglich sein und das globale Strukturierungsmuster sollte so konsistent wie möglich sein. Das Deaktivieren des strikten Modus ermöglicht im Wesentlichen zwei verschiedene Arten der Strukturierung von Vue-Apps - stellen Sie sich vor, Menschen arbeiten an einer App, die strict: true verwendet, und wechseln dann zu einem anderen Projekt, das strict: false ... verwendet, das es erstellt Fragmentierung der Entwicklererfahrung, und ich möchte diese Möglichkeit beseitigen, und 1.0 ist der einzig vernünftige Ort, um dies zu tun.

Es ist irgendwie unglücklich, dass Sie mitten in diesem Übergang stecken, und ich weiß Ihr Feedback zu schätzen. Aber was getan werden muss, muss getan werden.

@yyx990803 Ich sehe einen konkreten Anwendungsfall, bei dem ich irgendwie feststecke.

Was ich versuche zu tun

Ich baue eine erweiterbare Anwendung: erweiterbar mit Widgets. Ein Widget ist ein vom Entwickler definierter Teil der Anwendung, der die globale Anwendung einfügt, um sie an einigen Stellen zu erweitern. Es wird beim Start der Anwendung dynamisch geladen. Jede Instanz der Anwendung kann einen anderen Satz von Widgets haben und 2 Instanzen der Anwendung können sich auf derselben Seite befinden.

Beim Laden fügt das Widget der vuejs-Anwendung eine dynamisch erstellte Komponente hinzu.
Widgets können andere Widgets (untergeordnete Widgets) enthalten. Wir wissen nicht, wie es beim Start sein wird, da dieser Teil vom Benutzer verwaltet wird, nachdem die Anwendung geladen wurde. Deshalb müssen Widgets einander kennen und andere Widgets registrieren.

Das Problem

Ich möchte vermeiden, diese Widgets global zu registrieren (Kompatibilitätsgründe).
Da die Komponenten dynamisch erstellt und geladen werden, muss ich alle Komponenten in jeder Komponente registrieren, die Kinder enthalten kann. Das macht eine Menge Registrierung, die möglicherweise nicht verwendet wird. Sehen Sie, was ich meine (bitte beachten Sie, dass ich im Moment keine lokale Registrierung von Komponenten versucht habe, sondern die Tests mit globaler Registrierung durchgeführt habe):

var components = {

    appComponents: {
       template: "...",
       components: components
    },

    appComponents2: {
       template: "...",
       components: components
    },

    widgetComponents: {
       template: "...",
       components: components
    },

    widgetComponents2: {
       template: "...",
       components: components
    },

}

Gibt es dabei einen Leistungsengpass?

Aus diesem Grund denke ich, dass der Bereich einer "halbglobalen" Komponente nützlich sein könnte. Es könnte hilfreich sein, Anwendungen mit einem geschlossenen Bereich von Komponenten zu erstellen, bei denen Komponenten von Root- und untergeordneten Komponenten aus erreichbar sind. Aber nicht aus anderen Vuejs-Wurzeln. Was denkst du?

Die globale Registrierung registriert nicht rekursiv, sondern nur die
Komponente selbst und nicht die innerhalb der Option components . also denke ich
Es gab kein Problem.

Am Mo, 22. August 2016, 16:00 schrieb Soufiane Ghzal [email protected] :

@yyx990803 https://github.com/yyx990803 Ich sehe einen konkreten Anwendungsfall
Ich stecke irgendwie fest.

_Was ich versuche zu tun_

Ich baue eine erweiterbare Anwendung: erweiterbar mit Widgets. Ein Widget ist ein
vom Entwickler definierter Teil der Anwendung, wird dynamisch geladen
Start der Anwendung. Jede Instanz der Anwendung kann haben
verschiedene Widgets.

Wenn das Widget geladen wird, fügt es eine dynamisch erstellte Komponente hinzu
vuejs-Anwendung.
Widgets können andere Widgets (Kinder) enthalten, uns ist nicht bekannt, wie das geht
wird beim Start sein, da dieser Teil vom Benutzer danach verwaltet wird
Anwendung wird geladen. Deshalb müssen sich Widgets gegenseitig bewusst sein.

_Das Problem_

Ich möchte vermeiden, diese Widgets global zu registrieren.
Da Widgets dynamisch geladen werden, muss ich alle Widgets registrieren
jedes Widget, das Kinder enthalten kann. Das macht eine Menge zu registrieren
darf nicht verwendet werden. Sehen:

var-Komponenten = {

appComponents: {
   template: "...",
   components: components
},

appComponents2: {
   template: "...",
   components: components
},

}

_Gibt es dabei einen Leistungsengpass?_

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/vuejs/vue/issues/1297#issuecomment -241339596, oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFTLl6QDePtH93VOU2lgrC72Z0vKLsv-ks5qiVcXgaJpZM4F7M1v
.

@fnlctrl Es geht nicht um die globale Registrierung.

Das Problem ist, dass

• globales Registrierungsregister für alle vue+Komponenteninstanzen.
• Lokale Registrierungsregister nur für die aktuelle Komponente
• und es gibt keine Möglichkeit, sich für root und untergeordnete Elemente "semi global" zu registrieren: etwas, das die Registrierung für die aktuelle vue-Instanz ermöglicht (einschließlich der zu dieser Instanz hinzugefügten Komponenten).

Meiner Meinung nach besteht das Problem darin, dass vue zwar für den statischen (globalen) Weg gedacht ist, aber für den verpackten/verteilbaren (lokalen) Weg eingeschränkt ist.

semi-global Registrierung ist eigentlich schon möglich, da Vue prototypische Vererbung hat.
https://jsfiddle.net/fnlCtrl/32dt9e9g/

@fnlctrl
Ich bin mir nicht sicher, was Sie mit der von Ihnen gesendeten Geige zeigen möchten (bitte beachten Sie, dass Ihr Beispiel einen Fehler enthält: Unknown custom element: <bar> - did you register the component correctly? )

Ich bin nicht klar genug, vielleicht hast du nicht verstanden, was ich erklären möchte. Lass uns noch einmal beginnen:

Was ich erklären möchte, ist, dass wir:

• Komponenten global mit Vue.component('name', {...}) registrieren (das ist perfekt für Single-Page-Apps)
• Registrieren Sie eine Komponente lokal in einer Komponente new Vue({ components: {...} }); (das ist gut, um Komponenten mit Abhängigkeiten für die lokale Wiederverwendbarkeit zu versenden)

Aber wir können den Kindern keine Komponenten vom Elternteil zur Verfügung stellen. So etwas wie das globale Registrieren von Komponenten für die aktuelle vm -Instanz und alle in dieser Instanz geladenen Komponenten, aber nicht für in anderen VM-Instanzen geladene Komponenten. Siehe Beispiel: https://jsfiddle.net/p8wqafm1/2/

Verstehst du?

Ups, es scheint, dass meine Geige nicht richtig gespeichert wurde.
Das ist die, die ich dir zeigen wollte..
https://jsfiddle.net/fnlCtrl/32dt9e9g/1/

Ich lese gerade dein Beispiel.

Ich habe Ihr Beispiel hier gegabelt, das korrigiert wurde, um zu funktionieren. Ich hoffe, ich habe Sie richtig verstanden:
Sie möchten innerhalb von Foo begrenzte dynamische Komponenten hinzufügen.

@fnlctrl Vielen Dank für Ihr Beispiel, aber es scheint, dass es noch nicht abdeckt, was ich zu erreichen versuche.

Wenn Sie die Methode in Ihrem Beispiel verwenden, werden Komponenten nur in Foo registriert, aber das macht sie nicht in den untergeordneten Elementen Foo verfügbar (in diesem Beispiel Bar ).

Sehen Sie sich die Geige an, ich registriere Baz in Foo und möchte, dass sie in Bar verfügbar ist, weil sie von Foo geladen wird: https://jsfiddle .net/8y0Lmb01/3/

Ihr Beispiel gegabelt: https://jsfiddle.net/fnlCtrl/uvzaotaz/

Der Punkt ist, dass Komponenten einen klaren Abhängigkeitsbaum haben sollten und dynamische Komponenten, die voneinander abhängig sind, keine Ausnahme sein sollten.

@fnlctrl In Baz in Foo nicht mehr verfügbar.

Dazu könnte ich Vue.component('baz', {...} aber das Problem ist, dass es andere vue-Instanzen mit dieser baz Komponente "verschmutzt".

ODER

Ich könnte Baz sowohl in Foo als auch in Bar registrieren, und alle foo-Kinder und alle bar-Kinder und alle Foo-Grand-Kinder usw. Aber das fügt a hinzu viel Komplexität im Falle einer großen/dynamischen App

Verstehst du, was ich meine? Ich kann mich lokal registrieren, aber wir können keine Komponenten für die Kinder, Enkelkinder, ... der aktuellen Komponenten erben _nur_

Ja, jetzt verstehe ich deinen Punkt. Sorry, dass mir das bei der Registrierung nicht bewusst war
Die Komponente unter Foo macht sie im Gegensatz zu Foo nicht global
Vue.Komponente . Werde in die Quelle schauen, um zu sehen, warum.

Am Montag, den 22. August 2016 um 20:17 Uhr schrieb Soufiane Ghzal [email protected] :

@fnlctrl https://github.com/fnlctrl In Ihrem Beispiel ist Baz nicht verfügbar
in Foo mehr.

Dazu könnte ich Vue.component('baz', {...} verwenden, aber das Problem ist das
Es wird andere vue-Instanzen mit dieser Baz-Komponente "verschmutzen".

ODER

Ich konnte Baz sowohl in Foo als auch in Bar und allen foo-Kindern registrieren, und
alle Bar-Kinder und alle Foo Grand-Kinder usw. Aber das fügt eine Menge hinzu
Komplexität im Falle einer großen/dynamischen App

Verstehst du, was ich meine? Ich kann mich lokal registrieren, aber wir können nicht erben
Komponenten für die Kinder, Enkel, ... der aktuellen Komponenten
_nur_

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/vuejs/vue/issues/1297#issuecomment -241395119, oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFTLl2ud0GDO_hOwFN8GIA1TzVEF1q0Fks5qiZM9gaJpZM4F7M1v
.

Danke :)

Der Punkt ist, dass ich eine eigenständige Bibliothek versenden möchte, die von vue abhängt. Das Registrieren von Komponenten für eine bestimmte Instanz ist ein echter Vorteil, da ich als eigenständige Bibliothek sowieso nicht berechtigt bin, diese in der globalen Vue-Instanz zu registrieren ( das würde den eigenständigen Teil kaputt machen).

Bitte lassen Sie mich wissen, ob das, worüber ich gesprochen habe, in Vue implementiert werden könnte

Nun, ich schätze, der Grund war zu offensichtlich, als dass ich ihn übersehen würde: Ich war es nicht
mit new Foo() ...

Wird in 20 Minuten auf meiner Heimfahrt eine Geige bekommen.

Am Montag, den 22. August 2016 um 20:27 Uhr schrieb 宋铄运[email protected] :

Ja, jetzt verstehe ich deinen Punkt. Sorry, dass mir das bei der Registrierung nicht bewusst war
Die Komponente unter Foo macht sie im Gegensatz zu Foo nicht global
Vue.Komponente . Werde in die Quelle schauen, um zu sehen, warum.

Am Mo, 22. August 2016, 20:17 Soufiane Ghzal [email protected]
schrieb:

@fnlctrl https://github.com/fnlctrl In Ihrem Beispiel ist Baz nicht
in Foo nicht mehr verfügbar.

Dazu könnte ich Vue.component('baz', {...} verwenden, aber das Problem ist das
Es wird andere vue-Instanzen mit dieser Baz-Komponente "verschmutzen".

ODER

Ich konnte Baz sowohl in Foo als auch in Bar und allen foo-Kindern registrieren, und
alle Bar-Kinder und alle Foo Grand-Kinder usw. Aber das fügt eine Menge hinzu
Komplexität im Falle einer großen/dynamischen App

Verstehst du, was ich meine? Ich kann mich lokal registrieren, aber wir können nicht erben
Komponenten für die Kinder, Enkel, ... der aktuellen Komponenten
_nur_

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/vuejs/vue/issues/1297#issuecomment -241395119, oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFTLl2ud0GDO_hOwFN8GIA1TzVEF1q0Fks5qiZM9gaJpZM4F7M1v
.

Nun, new Foo(...) hat auch nicht funktioniert: https://jsfiddle.net/8y0Lmb01/5/

In der Tat seltsam ... https://jsfiddle.net/fnlCtrl/p0ggkncu/
Schaue jetzt rein.

Ich habe einen Teil des Quellcodes gelesen und festgestellt, dass wir auf Vue selbst so hacken können:
https://jsfiddle.net/fnlCtrl/522aw9sm/
(Ohne Verwendung von Vue.extend oder Vue.component ist übrigens Vue.component nur eine Hilfsfunktion, die Vue.extend ausführt und Vue.options.components modifiziert)

Obwohl der gleiche Ansatz bei einem erweiterten Vue nicht funktioniert:
https://jsfiddle.net/fnlCtrl/v1m2s16u/

Ich nehme also an, dass das Problem durch die Komponentenauflösung verursacht wird. Ich werde weiter suchen.

@fnlctrl Ok danke, ich habe versucht, einige Dinge zu überprüfen und bin zu demselben Schluss gekommen wie du. Ich kenne den Kern nicht genug, um herauszufinden, warum es so funktioniert. Wissen wir, ob es das erwartete Verhalten ist?

Ich denke, diese Kommentare über resolveAsset

Lösen Sie einen Vermögenswert auf.
Diese Funktion wird verwendet, weil untergeordnete Instanzen Zugriff benötigen
zu Assets, die in seiner Vorfahrenkette definiert sind.

schlägt vor, dass die Registrierung von Komponenten auf Extended Vue funktionieren soll.

Der Code im Funktionskörper betrachtet nicht die Vorfahrenkette, richtig? Vielleicht wurde es noch nicht implementiert?

Ich weiß noch nicht genug, lerne immer noch sein Verhalten, aber ich denke, die "Ahnenkette" bezieht sich auf den ersten Parameter options .

Ich denke, ich kann daraus schließen, dass die Ursache dies ist (src/core/global-api/extend) .
Erweiterte Klassen verwenden die gleiche Methode wie ihre Eltern.

Ich habe das getestet, wenn Sie kopieren, was in core/global-api/assets ist (verwenden Sie den entsprechenden Code in der dist-Version, die natürlich von Typen befreit ist).
zu vue.extend, damit es so aussieht (ändern Sie Vue in Sub ):

config._assetTypes.forEach(function (type) {
        Sub[type] = function (id, definition) {
          if (!definition) {
            return this.options[type + 's'][id];
          } else {
            /* istanbul ignore if */
            if ("development" !== 'production') {
              if (type === 'component' && config.isReservedTag(id)) {
                warn('Do not use built-in or reserved HTML elements as component ' + 'id: ' + id);
              }
            }
            if (type === 'component' && isPlainObject(definition)) {
              definition.name = definition.name || id;
              definition = Sub.extend(definition);
            }
            if (type === 'directive' && typeof definition === 'function') {
              definition = { bind: definition, update: definition };
            }
            this.options[type + 's'][id] = definition;
            return definition;
          }
        };
      });

die Foo = Vue.extend() und Foo.component() funktionieren.

Obwohl ich denke, dass dies zu Leistungseinbußen führen wird.

@gsouf Und ich glaube, ich habe das letzte Puzzleteil gefunden (eine gleichwertige Problemumgehung, ohne vue zu ändern):
https://jsfiddle.net/fnlCtrl/v1m2s16u/

var Root = Vue.extend()

Root.options.components.Foo = Root.extend({
    template: '<div>Foo</div>'
})

Root.options.components.Bar = Root.extend({
    template: '<div>Bar, uses <foo></foo></div>'
})

new Root({
    template: `
  <div>
    <foo></foo>
    <bar></bar>
  </div>
  `
}).$mount('#app')

Hallo @fnlctrl , danke für die Ausgabe und entschuldige die Verzögerung.

Tatsächlich sieht es so aus, als ob Komponenten Komponenten von ihrem Konstruktor erben, nicht von ihrem Elternteil. Ich suche derzeit, ob ich einen Patch für meinen Anwendungsfall anwenden kann.

In Ihrem Fall bleibt es an einen Konstruktor gebunden, nicht an eine Instanz. Ich suche, dass es nur Teil der Instanz ist

@fnlctrl Aufgrund der Funktionsweise von Javascript und dank Ihres Beispiels könnte ich dies umgehen, indem ich vue für jede von mir erstellte Instanz "dynamisch erweitere" und alles nur für diese Anwendung verfügbar mache.:

createVueInstance = function(el, data){
    var vExtend = Vue.extend();
    vExtend.partial('some-semiglobal-partial', "...");
    vExtend.component('some-semiglobal-component', vExtend.extend({...}));

    return new vExtend({
        el: el,
        data: data
    });
};

Nachdem ich überprüft habe, wie der Kern gebaut wurde, sieht es nicht so aus, als ob er gebaut wurde, um eine einfache Integration von pro Instanz verfügbaren Komponenten zu ermöglichen, und diese Problemumgehung ist stabil genug für mich.

Danke für Ihre Hilfe!

Übrigens, ich denke, das Beispiel, das Sie mir gezeigt haben, könnte in der Dokumentation ausführlich erklärt werden. Ich habe dazu keine Erwähnung gefunden

@gsouf Gern geschehen . Ich denke, dieses Problem ist genug für diejenigen, die ein ähnliches Feature implementieren möchten :smile:

Hier habe ich einen "semi-globalen" Anwendungsfall:

Ich habe eine relativ universelle Layout-Komponente, aber der Inhalt ist durch die Komponenten konfigurierbar, die die Layout-Komponente verwenden, z. Komponente A verwendet Layout und möchte ihren Inhalt mit Komponente B konfigurieren, eine andere Komponente verwendet möglicherweise Layout und konfiguriert ihren Inhalt mit Komponente C usw.

Soll dieses Muster unterstützt werden?

Oder gibt es eine Lösung, um dieses Design zu ersetzen?

Das Muster wird in iOS häufig verwendet, um die Wiederverwendung von Code zu verbessern, und dies ist ein flexibles Design.

@hpsoar Was Sie wahrscheinlich brauchen, sind Spielautomaten

Mein Design ist wie folgt, im Grunde erlaubt mir dies, zwei Dinge mit der Zelle zu tun:

1. einfache Konfiguration der Zelle mit einem CSS-Stil, der für viele Fälle ausreicht;
2. Fügen Sie eine Komponente in die Zelle ein, die für spezielle Fälle verwendet wird.

<template>
  <div class="tile is-ancestor">
    <div class="tile is-parent">
      <article class="tile is-child box">
        <div class="table-responsive">
          <table class="table is-bordered is-striped is-narrow">
            <thead>
            <tr>
              <th v-for="c in columns">
                {{c.title}}
              </th>
            </tr>
            </thead>
            <tbody>
            <tr v-for="(item, index) in items">
              <template v-for="c in columns">
                <td v-if="c.hasOwnProperty('component')"><div :is="c.component"></div></td>
                <td v-else>{{ item[c.name] }}</td>
              </template>
            </tr>
            </tbody>
          </table>
        </div>
      </article>
    </div>
  </div>
</template>

<script>

export default {
  components: {
  },
  props: [
    'columns',
    'items'
  ],
  data: function () {
    return {
    }
  }
}

</script>

<style lang="scss" rel="stylesheet/scss">
  .table-responsive {
    display: block;
    width: 100%;
    min-height: .01%;
    overflow-x: auto;
  }
</style>