Aspnetcore: ViewComponentTagHelper: Optionale Parameter zulassen

Einverstanden. Keine Ahnung wie machbar das ist, aber ich stimme dem zu :smile:

Das scheint ziemlich machbar. Wir müssen diesem Code Standardwerte beibringen. Derzeit heißt es, dass jeder Parameter ein erforderliches Attribut ist

@rynowak Kandidat für Vorschau2?

Ich werde es einziehen und zum Mitnehmen markieren. An diesem Punkt muss das Sperren unserer öffentlichen APIs und das Vervollständigen der Tooling-Story Vorrang haben.

Freue mich wirklich auf diesen Fix. Aus heutiger Sicht ist die Verwendung des VC-Tag-Helfers sehr gefährlich. Fügen Sie einem vorhandenen und weit verbreiteten Tag-Hilfsprogramm einen neuen Parameter hinzu und verpassen Sie die Aktualisierung einer der Stellen, an denen es aufgerufen wird, und es schlägt _stillschweigend fehl, während es serverseitiges Markup an den Browser ausgibt_. Ich schätze, wir sind jetzt zu weit, um es in 2.0.0 zu schaffen?

Das wird es nicht für 2.0.0 schaffen. Wir haben zu diesem Zeitpunkt keine Zeit, die Tools zu aktualisieren.

Ich glaube, es sollte als Fehler markiert werden .

Das funktioniert:

<strong i="8">@await</strong> Component.Invoke(typeof(MyViewComponent));

Das funktioniert nicht

<vc:My />

Es ist ein erwartetes Verhalten, und da Sie keine Warnung, Fehler, Debug-Meldung, nichts anzeigen, verärgert es viele Leute, die sich fragen, warum zum Teufel die Ansichtskomponente nicht gerendert wird

Wird es das also in die nächste Version schaffen?

Suchen Sie nach einem Update zu diesem Problem. Wird dies in absehbarer Zeit hinzugefügt? Eher frustrierend, damit umzugehen.

Kam hierher, um dasselbe zu sagen, nachdem ich dieses Problem gefunden und einige Zeit damit verbracht hatte, herauszufinden, warum einer meiner Tag-Helfer namens VCs keine Ausgabe präsentierte.

Hallo @rynowak :

Ich dachte, ich würde es versuchen, und nachdem ich den Quellcode hier gelesen habe (Ihr Link ist tot), scheint es ziemlich einfach zu beheben zu sein. Es gibt jedoch mindestens zwei Möglichkeiten (entweder eine Kopie von RequiredAttributeDescriptor und Freunden erstellen oder zu einer Basisklasse/-schnittstelle wechseln), um dies zu tun, und es ist eine beträchtliche Menge an Codeänderungen erforderlich.

@rynowak und/oder @DamianEdwards , bitte erzähl @CamiloTerevinto etwas, da wir dies verbessern möchten.

Aktualisierte View-Komponenten in ASP.NET Core mit

Alle Ansichtskomponentenparameter sind erforderlich

Jeder Parameter in einer Ansichtskomponente ist ein erforderliches Attribut. Siehe dieses GitHub-Problem . Wenn irgendein Parameter weggelassen wird:

• Die Methodensignatur InvokeAsync stimmt nicht überein, daher wird die Methode nicht ausgeführt.
• Die ViewComponent rendert kein Markup.
• Es werden keine Fehler ausgegeben.

Wurde gerade hart davon gebissen (der Hinweis war noch nicht da, als ich ihn in meine App implementiert habe)

Gibt es eine geplante Lösung oder wird es auf absehbare Zeit so bleiben? Da dies wirklich gefährlich sein kann, insbesondere wenn es stillschweigend fehlschlägt ... Könnte es zumindest zur Kompilierzeit eine Warnung oder ähnliches geben?

Ja, dem letzten Kommentar stimme ich zu. Mich hat das kürzlich auch hart gebissen und dass es einfach lautlos versagt, ist nicht gut.

@rynowak ist es möglich, einen Fehler zu generieren?

@rynowak Wird es dafür in Zukunft Unterstützung geben?

Es ist über zwei Jahre her, und ehrlich gesagt ist es mühsam, Standardparameter überall dort duplizieren zu müssen, wo eine Ansichtskomponente verwendet wird.

@rynowak was ist die richtige Zeilennummer in

Das scheint ziemlich machbar. Wir müssen diesem Code Standardwerte beibringen. Derzeit heißt es, dass jeder Parameter ein _erforderliches_ Attribut ist

Dieser Code : aktualisierter Link, aber möglicherweise nicht korrekte Zeile

Danke @Rick-Anderson für die Aktualisierung der Dokumentation, aber es ist lächerlich, dass Sie das überhaupt müssen. Dies macht den Tag-Helfer für ernsthafte Projekte UNNUTZBAR. Dass Code beim Umgestalten oder Hinzufügen von Funktionen _stillschweigend_ fehlschlägt, sollte völlig inakzeptabel sein. Ich bin fassungslos, dass dies fast drei Jahre nach der ersten Meldung immer noch offen ist. Ist eine Behebung geplant?!

Hat sich jemand vom Aspnetcore-Team dies angesehen und eine endgültige Antwort gegeben, ob dies implementiert wird oder nicht? Ich persönlich denke, es ist etwas, das Ansichtskomponenten tatsächlich nützlich macht und redundanten Code reduzieren würde. Als absolutes Minimum würde ich gerne sehen, dass jemand aus dem Team die Verantwortung übernimmt und eine Entscheidung über das Schicksal dieser Funktion trifft.

@mkArtakMSFT @rynowak bitte überprüfen und @rynowak können Sie überprüfen

@rynowak was ist die richtige Zeilennummer in

Das scheint ziemlich machbar. Wir müssen diesem Code Standardwerte beibringen. Derzeit heißt es, dass jeder Parameter ein _erforderliches_ Attribut ist

Dieser Code : aktualisierter Link, aber möglicherweise nicht korrekte Zeile

Also hat dieser @rynowak- Typ in 3 Jahren dieses Problem nicht gemeistert

@brgrz hast du eine Lösung gefunden? Denn wenn "dieser @rynowak " keinen finden kann, könnten Sie vielleicht kommen und helfen (versuchen, vielleicht konstruktiv statt destruktiv zu sein, Ihr Kommentar bringt hier meiner Meinung nach nichts auf den Tisch ...)

Ich muss zugeben, dass es traurig ist zu erkennen, dass es noch keine vorgeschlagene Lösung gibt und dass dieses Problem vor langer Zeit gemeldet wurde, aber vergessen Sie nie, dass nicht 1000 daran arbeiten und sie viele Bereiche abdecken müssen ... also ich nicht überrascht, dass einige Probleme für lange Zeit ungelöst bleiben, es ist das gleiche für jedes Open-Source-Projekt da draußen .... (fast)

Wir werden dies in 5.0 unterstützen!

@brgrz hast du eine Lösung gefunden? Denn wenn "dieser @rynowak " keinen finden kann, könnten Sie vielleicht kommen und helfen (versuchen, vielleicht konstruktiv statt destruktiv zu sein, Ihr Kommentar bringt hier meiner Meinung nach nichts auf den Tisch ...)

Ich muss zugeben, dass es traurig ist zu erkennen, dass es noch keine vorgeschlagene Lösung gibt und dass dieses Problem vor langer Zeit gemeldet wurde, aber vergessen Sie nie, dass nicht 1000 daran arbeiten und sie viele Bereiche abdecken müssen ... also ich nicht überrascht, dass einige Probleme für lange Zeit ungelöst bleiben, es ist das gleiche für jedes Open-Source-Projekt da draußen .... (fast)

@os1r1s110 Oh, bitte ... lass den Beitrags-Bullshit, Rynowak hat vor 3 Jahren "Das scheint ziemlich machbar" gepostet. Ich wette, dass dieses einzige Problem Entwickler weltweit Hunderte von vergeudeten Debugging-Stunden und Headbanging in der Zwischenzeit gekostet hat.

Außerdem ist ASP.NET Core weder mein Produkt noch ein Community-Produkt, sondern ein MS-Produkt. Selbst wenn ich wollte, bezweifle ich stark, dass sie meine Lösung akzeptieren würden und dass MS-Mitarbeiter dafür bezahlt werden.

@brgrz Wie gesagt, ich war auch traurig, dass es nicht früher behoben wurde, aber ich denke, es gibt immer noch eine Möglichkeit, Dinge zu präsentieren und nicht zu berücksichtigen, dass jeder, der an Open-Source-Projekten arbeitet, Ihnen etwas schuldet (bezahlt oder nicht). Ja, sie werden dafür bezahlt, an asp.net-Core- und verwandten Projekten zu arbeiten, aber das bedeutet nicht, dass sie über genügend Ressourcen verfügen, um alle Anforderungen zeitnah zu erfüllen (und ich spreche hier nicht einmal speziell von Open-Source-Projekten, Heutzutage wird in jedem verdammten Bereich qualifiziertes Personal benötigt).

Tut mir leid, wenn ich Sie beleidigt habe, indem ich auf Ihren Beitrag geantwortet habe, aber ich denke immer noch, dass dies nicht der Weg ist, die Dinge zu bewegen (und ich halte es nicht für "Beitrags-Bullshit"), obwohl es so aussieht, als hätte er die Dinge bewegt. .. :)

Kommen wir zurück zu Next sprint planning , da wir in diesem Meilenstein nicht dazu gekommen sind.

Wir haben dieses Problem in den Backlog-Meilenstein verschoben. Dies bedeutet, dass für die kommende Version nicht daran gearbeitet wird. Wir werden den Rückstand nach der aktuellen Veröffentlichung neu bewerten und diesen Punkt zu diesem Zeitpunkt berücksichtigen. Um mehr über unseren Issue-Management-Prozess zu erfahren und bessere Erwartungen in Bezug auf verschiedene Arten von Issues zu haben, können Sie unseren Triage-Prozess lesen.

Wir werden dies in 5.0 unterstützen!

Ob das am Ende ausreicht?

@guitax Wenn man bedenkt, wie oft es verzögert wurde, und die Tatsache, dass es wieder in den Rückstand gesetzt wurde, würde ich sagen, dass die Chancen wirklich sehr, sehr gering sind 😕 Es scheint, als ob die neue Priorität jetzt Blazor ist.

Hoffen wir nur, dass dies implementiert wird, da es sich um ein wirklich irritierendes Problem handelt. 😂

Zumindest wäre es schön, wenn diese Anforderung in der Dokumentation deutlicher herausgestellt würde. Fehlende Attribute, die standardmäßig einen Standardwert haben, sind die Norm in HTML; Die Idee, dass sie für View-Komponenten benötigt werden, kam mir erst in den Sinn, als ich über diesen Thread stolperte.