Aspnetcore: ViewComponentTagHelper: permitir parámetros opcionales

Acordado. No tengo idea de cuán factible es, pero estoy de acuerdo con el sentimiento :smile:

Esto parece bastante factible. Necesitamos enseñarle a este código sobre los valores predeterminados. Actualmente dice que cada parámetro es un atributo requerido

@rynowak candidato para preview2?

Voy a moverlo y marcarlo para que lo agarre. En este punto, bloquear nuestras API públicas y completar la historia de las herramientas debe tener prioridad.

Con muchas ganas de esta solución. Tal como están las cosas, usar el asistente de etiquetas VC es muy peligroso. Agregue un nuevo parámetro a un asistente de etiquetas existente y ampliamente utilizado y no actualice uno de los lugares a los que se llama y _falla silenciosamente mientras emite el marcado del lado del servidor al navegador_. Supongo que estamos demasiado avanzados ahora para que esto llegue a 2.0.0.

Esto no va a hacer para 2.0.0. No tenemos tiempo para actualizar las herramientas en este momento.

Creo que debería estar marcado como un error .

Esto está funcionando:

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

Esto no está funcionando

<vc:My />

Es el comportamiento esperado y dado que no muestra ninguna advertencia, error, mensaje de depuración, nada, molesta a muchas personas que se preguntan por qué diablos no se procesa el componente de vista.

Entonces, ¿esto llegará a la próxima versión?

Buscando una actualización sobre este tema. ¿Se agregará esto pronto? Bastante frustrante de tratar.

Vine aquí para decir lo mismo después de encontrar este problema y pasar un tiempo rastreando por qué mi asistente de etiquetas llamado VC no presentaba ningún resultado.

Hola @rynowak :

Pensé en darle una oportunidad a esto y después de leer el código fuente aquí (su enlace está muerto), parece bastante fácil de arreglar. Sin embargo, hay al menos dos formas (crear una réplica de RequiredAttributeDescriptor y amigos, o pasar a una clase/interfaz base) para hacer esto y es una cantidad sustancial de cambios de código.

@rynowak y/o @DamianEdwards , por favor dígale algo a @CamiloTerevinto ya que queremos ver esto mejorado.

Componentes de View actualizados en ASP.NET Core con

Todos los parámetros del componente de vista son obligatorios

Cada parámetro en un componente de vista es un atributo obligatorio. Consulte este problema de GitHub . Si se omite algún parámetro:

• La firma del método InvokeAsync no coincidirá, por lo tanto, el método no se ejecutará.
• El ViewComponent no generará ningún marcado.
• No se arrojarán errores.

Simplemente me mordió con fuerza (el aviso no estaba allí en el momento en que lo implementé en mi aplicación)

¿Existe una solución planificada o se mantendrá así en el futuro previsible? Como esto puede ser realmente peligroso, especialmente porque falla silenciosamente... ¿Podría haber al menos una advertencia o algo así en tiempo de compilación?

Sí, estoy de acuerdo con el último comentario. También me mordió mucho esto recientemente y el hecho de que simplemente falle en silencio no es bueno.

@rynowak ¿es posible generar un error?

@rynowak ¿Habrá algún apoyo para esto en el futuro?

Han pasado más de dos años y, sinceramente, es una molestia tener que duplicar los parámetros predeterminados en todos los lugares donde se usa un componente de vista.

@rynowak ¿cuál es el número de línea correcto en

Esto parece bastante factible. Necesitamos enseñarle a este código sobre los valores predeterminados. Actualmente dice que cada parámetro es un atributo _requerido_

este código : enlace actualizado pero tal vez no sea la línea correcta

Gracias @Rick-Anderson por actualizar los documentos, pero es ridículo que tengas que hacerlo. Esto hace que el asistente de etiquetas sea INUTILIZABLE para proyectos serios. Que el código falle _silenciosamente_ cuando refactorizas o agregas funciones debería ser completamente inaceptable. Estoy sorprendido de que esto todavía esté abierto casi tres años después de que se informó por primera vez. ¿Hay alguna solución planeada?

¿Alguien del equipo de aspnetcore ha analizado esto y ha dado una respuesta definitiva sobre si se implementará o no? Personalmente, creo que es algo que hace que los componentes de vista sean realmente útiles y reduciría el código redundante. Como mínimo, me gustaría que alguien del equipo se hiciera cargo y tomara una decisión sobre el destino de esta característica.

@mkArtakMSFT @rynowak por favor revise y @rynowak puede verificar

@rynowak ¿cuál es el número de línea correcto en

Esto parece bastante factible. Necesitamos enseñarle a este código sobre los valores predeterminados. Actualmente dice que cada parámetro es un atributo _requerido_

este código : enlace actualizado pero tal vez no sea la línea correcta

así que en 3 años este tipo @rynowak no solucionó este problema

@brgrz ¿ha encontrado una solución? Porque si "este @rynowak " no puede pensar en uno, tal vez podrías venir y ayudar (tratando de ser constructivo en lugar de destructivo, tu comentario no trae nada a la mesa aquí en mi opinión...)

Debo estar de acuerdo en que es triste darme cuenta de que aún no hay una solución propuesta y que este problema se informó hace mucho tiempo, pero nunca olvide que no hay 1000 trabajando en él y tienen muchas áreas que cubrir... así que estoy No me sorprende que algunos problemas queden sin resolver durante largos períodos, es lo mismo para todos los proyectos de código abierto que existen... (casi)

¡Agregaremos soporte para esto en 5.0!

@brgrz ¿ha encontrado una solución? Porque si "este @rynowak " no puede pensar en uno, tal vez podrías venir y ayudar (tratando de ser constructivo en lugar de destructivo, tu comentario no trae nada a la mesa aquí en mi opinión...)

Debo estar de acuerdo en que es triste darme cuenta de que aún no hay una solución propuesta y que este problema se informó hace mucho tiempo, pero nunca olvide que no hay 1000 trabajando en él y tienen muchas áreas que cubrir... así que estoy No me sorprende que algunos problemas queden sin resolver durante largos períodos, es lo mismo para todos los proyectos de código abierto que existen... (casi)

@ os1r1s110 Oh, por favor... olvídate de las tonterías del colaborador, rynowak publicó "Esto parece bastante factible" hace 3 años. Apuesto a que este único problema les costó a los desarrolladores de todo el mundo cientos de horas de depuración desperdiciadas y golpes de cabeza mientras tanto.

Además, ASP.NET Core no es mi producto ni es un producto de la comunidad, es un producto de MS. Incluso si quisiera, dudo mucho que aceptaran mi solución y a los empleados de MS se les paga por hacerlo.

@brgrz Como dije, también me entristeció que no se arreglara antes, pero creo que todavía hay una manera de presentar las cosas y no considerar que todos los que trabajan en proyectos de código abierto le deben algo (pagado o no). Sí, se les paga por trabajar en el núcleo de asp.net y proyectos relacionados, pero eso no significa que tengan suficientes recursos para satisfacer todas las necesidades de manera oportuna (y ni siquiera estoy hablando específicamente de proyectos de código abierto aquí, hay una necesidad de personal calificado en cada maldito dominio hoy en día).

Lo siento si te ofendí respondiendo a tu publicación, pero sigo pensando que esa no es la forma de hacer que las cosas se muevan (y no lo considero una "mierda de colaborador"), aunque parece que hizo que las cosas se movieran... .. :)

Volviendo a Next sprint planning ya que no llegamos a esto en este hito.

Hemos movido este problema al hito de Backlog. Esto significa que no se va a trabajar en el próximo lanzamiento. Volveremos a evaluar la acumulación después del lanzamiento actual y consideraremos este elemento en ese momento. Para obtener más información sobre nuestro proceso de gestión de problemas y tener mejores expectativas con respecto a los diferentes tipos de problemas, puede leer nuestro Proceso de clasificación.

¡Agregaremos soporte para esto en 5.0!

¿Esto va a lograrlo al final?

@guitax considerando la cantidad de veces que se ha retrasado más el hecho de que se ha vuelto a poner en el backlog, diría que las posibilidades son realmente muy bajas 😕 Parece que la nueva prioridad ahora es blazor.

Esperemos que esto termine implementándose, ya que es un problema realmente irritante. 😂

Como mínimo, sería bueno si este requisito se hiciera mucho más claro en la documentación. Los atributos que faltan por defecto a un valor estándar son la norma en HTML; la idea de que serían necesarios para ver los componentes no se me ocurrió hasta que encontré este hilo.