Aspnetcore: ViewComponentTagHelper : Autoriser les paramètres facultatifs

D'accord. Aucune idée de la faisabilité, mais je suis d'accord avec le sentiment :smile:

Cela semble assez faisable. Nous devons enseigner à ce code les valeurs par défaut. Actuellement, il est dit que chaque paramètre est un attribut obligatoire

@rynowak candidat pour preview2 ?

Je vais l'emménager et le marquer à gagner. À ce stade, le verrouillage de nos API publiques et l'achèvement de l'histoire de l'outillage doivent être prioritaires.

J'attends vraiment avec impatience ce correctif. Dans l'état actuel des choses, l'utilisation de l'assistant de balise VC est très dangereuse. Ajoutez un nouveau paramètre à un assistant de balise existant et largement utilisé et manquez la mise à jour de l'un des endroits où il est appelé et il _échoue silencieusement lors de l'émission du balisage côté serveur vers le navigateur_. Je suppose que nous sommes trop avancés maintenant pour que cela passe en 2.0.0 ?

Cela ne va pas le faire pour 2.0.0. Nous n'avons pas le temps de mettre à jour l'outillage à ce stade.

Je pense que cela devrait être marqué comme un bogue .

Cela fonctionne :

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

Cela ne fonctionne pas

<vc:My />

C'est un comportement attendu et puisque vous ne montrez aucun avertissement, erreur, message de débogage, rien, cela dérange beaucoup de gens qui se demandent pourquoi diable le composant de vue n'est pas rendu

Cela fera-t-il partie de la prochaine version ?

Vous recherchez une mise à jour sur ce problème. Cela sera-t-il bientôt ajouté ? Plutôt frustrant à gérer.

Je suis venu ici pour dire la même chose après avoir trouvé ce problème et passé du temps à chercher pourquoi l'un de mes assistants de balises appelé VC ne présentait aucune sortie.

Salut @rynowak :

J'ai pensé que j'allais essayer et après avoir lu le code source ici (votre lien est mort), cela semble assez facile à réparer. Cependant, il existe au moins deux façons (créer une réplique de RequiredAttributeDescriptor et amis, ou passer à une classe/interface de base) pour le faire et cela représente une quantité substantielle de modifications de code.

@rynowak et/ou @DamianEdwards , veuillez dire quelque chose à @CamiloTerevinto car nous voulons que cela s'améliore.

Composants View mis à jour dans ASP.NET Core avec

Tous les paramètres du composant de vue sont requis

Chaque paramètre d'un composant de vue est un attribut obligatoire. Voir ce problème GitHub . Si un paramètre est omis :

• La signature de la méthode InvokeAsync ne correspondra pas, donc la méthode ne s'exécutera pas.
• Le ViewComponent ne restituera aucun balisage.
• Aucune erreur ne sera générée.

Je viens de m'y faire mordre (l'avis n'était pas là au moment où je l'ai implémenté dans mon application)

Y a-t-il une solution prévue ou cela restera-t-il comme ça dans un avenir prévisible ? Comme cela peut être vraiment dangereux, surtout qu'il échoue silencieusement... Pourrait-il au moins y avoir un avertissement ou quelque chose comme ça au moment de la compilation ?

Oui, je suis d'accord avec le dernier commentaire. J'ai aussi été mordu par cela récemment et le fait qu'il échoue simplement en silence n'est pas bon.

@rynowak est-il possible de générer une erreur ?

@rynowak Y aura-t-il un support pour cela à l'avenir ?

Cela fait plus de deux ans, et honnêtement, il est pénible de devoir dupliquer les paramètres par défaut partout où un composant de vue est utilisé.

@rynowak quel est le bon numéro de ligne dans

Cela semble assez faisable. Nous devons enseigner à ce code les valeurs par défaut. Actuellement, il est dit que chaque paramètre est un attribut _required_

ce code : lien mis à jour mais peut-être pas la bonne ligne

Merci @Rick-Anderson d'avoir mis à jour la documentation, mais c'est ridicule que vous ayez même à le faire. Cela rend le tag helper INUTILISABLE pour les projets sérieux. Faire échouer le code _silencieusement_ lorsque vous refactorisez ou ajoutez des fonctionnalités devrait être totalement inacceptable. Je suis stupéfait que cela soit toujours ouvert près de trois ans après avoir été signalé pour la première fois. Est-ce qu'un correctif est prévu ? !

Quelqu'un de l'équipe aspnetcore a-t-il examiné cela et a-t-il donné une réponse définitive quant à savoir si cela sera implémenté ou non? Personnellement, je pense que c'est quelque chose qui rend les composants de vue réellement utiles et réduirait le code redondant. Au strict minimum, j'aimerais voir quelqu'un de l'équipe s'approprier et prendre une décision sur le sort de cette fonctionnalité.

@mkArtakMSFT @rynowak veuillez revoir et @rynowak pouvez-vous vérifier

@rynowak quel est le bon numéro de ligne dans

Cela semble assez faisable. Nous devons enseigner à ce code les valeurs par défaut. Actuellement, il est dit que chaque paramètre est un attribut _required_

ce code : lien mis à jour mais peut-être pas la bonne ligne

donc en 3 ans ce gars de @rynowak n'a pas résolu ce problème

@brgrz avez-vous trouvé une solution ? Parce que si "ce @rynowak " ne peut pas en trouver un, peut-être pourriez-vous venir aider (en essayant d'être constructif peut-être au lieu de destructeur, votre commentaire n'apporte rien à la table ici IMO ...)

Je dois convenir qu'il est triste de réaliser qu'il n'y a pas encore de solution proposée et que ce problème a été signalé il y a longtemps, mais n'oubliez jamais qu'ils ne sont pas 1000 à y travailler et qu'ils ont beaucoup de domaines à couvrir... alors je suis pas surpris que certains problèmes restent non résolus pendant de longues périodes, c'est la même chose pour tous les projets open source là-bas .... (presque)

Nous ajouterons la prise en charge de cela dans la version 5.0 !

@brgrz avez-vous trouvé une solution ? Parce que si "ce @rynowak " ne peut pas en trouver un, peut-être pourriez-vous venir aider (en essayant d'être constructif peut-être au lieu de destructeur, votre commentaire n'apporte rien à la table ici IMO ...)

Je dois convenir qu'il est triste de réaliser qu'il n'y a pas encore de solution proposée et que ce problème a été signalé il y a longtemps, mais n'oubliez jamais qu'ils ne sont pas 1000 à y travailler et qu'ils ont beaucoup de domaines à couvrir... alors je suis pas surpris que certains problèmes restent non résolus pendant de longues périodes, c'est la même chose pour tous les projets open source là-bas .... (presque)

@ os1r1s110 Oh, s'il vous plait... coupez les conneries du contributeur, rynowak a posté "Cela semble assez faisable" il y a 3 ans. Je parie que ce problème unique a coûté aux développeurs du monde entier des centaines d'heures de débogage perdues et des coups de tête entre-temps.

De plus, ASP.NET Core n'est pas mon produit ni un produit communautaire, c'est un produit MS. Même si je le voulais, je doute fort qu'ils acceptent ma solution et les employés de MS sont payés pour le faire.

@brgrz Comme je l'ai dit, j'étais également triste que cela n'ait pas été corrigé plus tôt, mais je pense qu'il existe toujours un moyen de présenter les choses et de ne pas considérer que tout le monde travaillant sur des projets open source vous doit quelque chose (payé ou non). Oui, ils sont payés pour travailler sur le noyau asp.net et les projets connexes, mais cela ne signifie pas qu'ils disposent de suffisamment de ressources pour répondre à tous les besoins en temps opportun (et je ne parle même pas spécifiquement des projets open source ici, il y a un besoin de personnel qualifié dans tous les domaines flippants de nos jours).

Désolé si je t'ai offensé en répondant à ton message, mais je pense quand même que ce n'est pas la bonne façon de faire bouger les choses (et je ne considère pas que ce soit des "conneries de contributeur"), même si ça a l'air d'avoir fait bouger les choses.. .. :)

Revenons au Next sprint planning car nous n'y sommes pas parvenus dans cette étape.

Nous avons déplacé ce problème vers le jalon Backlog. Cela signifie qu'il ne sera pas travaillé pour la prochaine version. Nous réévaluerons l'arriéré après la version actuelle et examinerons cet élément à ce moment-là. Pour en savoir plus sur notre processus de gestion des problèmes et avoir de meilleures attentes concernant les différents types de problèmes, vous pouvez lire notre processus de triage .

Nous ajouterons la prise en charge de cela dans la version 5.0 !

Est-ce que ça va le faire à la fin?

@guitax compte tenu du nombre de fois où il a été retardé et du fait qu'il a été remis en attente, je dirais que les chances sont vraiment très faibles 😕 Il semble que la nouvelle priorité soit maintenant blazor.

Espérons juste que cela finira par être mis en œuvre car c'est un problème vraiment irritant. 😂

À tout le moins, ce serait bien si cette exigence était beaucoup plus claire dans la documentation. Les attributs manquants par défaut à une valeur standard sont la norme en HTML ; l'idée qu'ils seraient nécessaires pour les composants de vue ne m'est pas venue jusqu'à ce que je tombe sur ce fil.