Aspnetcore: ViewComponentTagHelper: разрешить необязательные параметры

Согласованный. Понятия не имею, насколько это возможно, но с мнением согласен :smile:

Это кажется вполне осуществимым. Нам нужно научить этот код значениям по умолчанию. В настоящее время он говорит, что каждый параметр является обязательным атрибутом

@rynowak кандидат на превью2?

Я собираюсь переместить его и отметить его для захвата. На данный момент блокировка наших общедоступных API и завершение истории инструментов должны иметь приоритет.

Очень жду этого исправления. В настоящее время использование помощника по тегам VC очень опасно. Добавьте новый параметр к существующему и широко используемому вспомогательному тегу и пропустите обновление одного из мест, где он вызывается, и он _тихо выйдет из строя при отправке разметки на стороне сервера в браузер_. Полагаю, мы слишком далеко продвинулись, чтобы сделать это в 2.0.0?

Это не собирается делать это для 2.0.0. На данный момент у нас нет времени обновлять инструменты.

Я считаю, что это должно быть помечено как ошибка .

Это работает:

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

Это не работает

<vc:My />

Это ожидаемое поведение, и, поскольку вы не показываете никаких предупреждений, ошибок, отладочных сообщений, ничего, это расстраивает многих людей, задающихся вопросом, почему, черт возьми, компонент представления не отображается.

Так войдет ли это в следующий релиз?

Ждем обновлений по этому вопросу. Будет ли это добавлено в ближайшее время? Довольно неприятно иметь с ним дело.

Пришел сюда, чтобы сказать то же самое, обнаружив эту проблему и потратив некоторое время на выяснение того, почему один из моих помощников по тегам, называемый VC, не выдает никаких результатов.

Привет @rynowak :

Я подумал, что сделаю это, и после прочтения исходного кода здесь (ваша ссылка мертва) кажется, что это довольно легко исправить. Однако есть по крайней мере два способа (либо создать реплику RequiredAttributeDescriptor и друзей, либо перейти на базовый класс/интерфейс), чтобы сделать это, и это требует значительного количества изменений кода.

@rynowak и/или @DamianEdwards , пожалуйста, скажите что-нибудь @CamiloTerevinto , так как мы хотим, чтобы это стало лучше.

Обновлены компоненты View в ASP.NET Core с

Все параметры компонента представления являются обязательными.

Каждый параметр в компоненте представления является обязательным атрибутом. См. этот выпуск GitHub . Если какой-либо параметр опущен:

• Сигнатура метода InvokeAsync не будет совпадать, поэтому метод не будет выполняться.
• ViewComponent не будет отображать никакой разметки.
• Никаких ошибок не будет.

Просто сильно укусил (уведомления не было, когда я реализовал его в своем приложении)

Есть ли запланированное решение или оно останется таким в обозримом будущем? Так как это может быть действительно опасно, особенно из-за того, что он молча терпит неудачу... Может ли быть хотя бы предупреждение или что-то в этом роде во время компиляции?

Да, согласен с последним комментарием. Я также недавно сильно укусил это, и тот факт, что он просто молча терпит неудачу, не является хорошим.

@rynowak можно ли сгенерировать ошибку?

@rynowak Будет ли это поддерживаться в будущем?

Прошло более двух лет, и, честно говоря, очень неудобно дублировать параметры по умолчанию везде, где используется компонент представления.

@rynowak какой правильный номер строки в

Это кажется вполне осуществимым. Нам нужно научить этот код значениям по умолчанию. В настоящее время он говорит, что каждый параметр является атрибутом _required_

этот код : обновленная ссылка, но, возможно, неправильная строка

Спасибо @Rick-Anderson за обновление документов, но смешно, что вам вообще нужно это делать. Это делает вспомогательный тег непригодным для серьезных проектов. Совершенно неприемлемо, чтобы код _тихо_ терпел неудачу при рефакторинге или добавлении функций. Я ошеломлен тем, что это все еще открыто спустя почти три года после первого сообщения. Планируется ли какое-то исправление?!

Кто-нибудь из команды aspnetcore посмотрел на это и дал окончательный ответ, будет ли это реализовано? Я лично думаю, что это то, что делает компоненты представления действительно полезными и уменьшает избыточный код. Как минимум, я хотел бы, чтобы кто-то из команды взял на себя ответственность и принял решение о судьбе этой функции.

@mkArtakMSFT @rynowak, пожалуйста, просмотрите, а @rynowak можете проверить

@rynowak какой правильный номер строки в

Это кажется вполне осуществимым. Нам нужно научить этот код значениям по умолчанию. В настоящее время он говорит, что каждый параметр является атрибутом _required_

этот код : обновленная ссылка, но, возможно, неправильная строка

так что за 3 года этот парень @rynowak так и не разобрался в этом вопросе

@brgrz ты нашел решение? Потому что, если «этот @rynowak » не может придумать, может быть, вы могли бы прийти и помочь (пытаясь быть конструктивным, возможно, вместо деструктивного, ваш комментарий здесь ничего не дает, ИМО...)

Я должен согласиться, что грустно осознавать, что пока нет предложенного решения и что об этой проблеме сообщалось давно, но никогда не забывайте, что над ней работает не 1000 человек, и у них есть много областей, которые нужно охватить... так что я не удивлен, что некоторые проблемы остаются нерешенными в течение длительного времени, это то же самое для каждого проекта с открытым исходным кодом.... (почти)

Мы добавим поддержку этого в 5.0!

@brgrz ты нашел решение? Потому что, если «этот @rynowak » не может придумать, может быть, вы могли бы прийти и помочь (пытаясь быть конструктивным, возможно, вместо деструктивного, ваш комментарий здесь ничего не дает, ИМО...)

Я должен согласиться, что грустно осознавать, что пока нет предложенного решения и что об этой проблеме сообщалось давно, но никогда не забывайте, что над ней работает не 1000 человек, и у них есть много областей, которые нужно охватить... так что я не удивлен, что некоторые проблемы остаются нерешенными в течение длительного времени, это то же самое для каждого проекта с открытым исходным кодом.... (почти)

@ os1r1s110 О, пожалуйста... прекратите нести чушь об участниках, rynowak написал "Это кажется вполне возможным" 3 года назад. Бьюсь об заклад, эта единственная проблема стоила разработчикам во всем мире сотен потраченных впустую часов отладки и головокружения.

Кроме того, ASP.NET Core не является ни моим продуктом, ни продуктом сообщества, это продукт MS. Даже если бы я захотел, я очень сомневаюсь, что они примут мое решение, а сотрудникам MS за это платят.

@brgrz Как я уже сказал, мне также было грустно, что это не было исправлено раньше, но я думаю, что все еще есть способ представить вещи и не считать, что все, кто работает над проектами с открытым исходным кодом, вам что-то должны (платно или нет). Да, им платят за работу над ядром asp.net и сопутствующими проектами, но это не значит, что у них достаточно ресурсов для своевременного выполнения всех потребностей (и я даже не говорю здесь конкретно о проектах с открытым исходным кодом, в настоящее время в каждой чертовой области есть потребность в квалифицированных кадрах).

Извините, если я обидел вас, ответив на ваш пост, но я все еще думаю, что это не способ сдвинуть дело с мертвой точки (и я не считаю это «чушью авторов»), хотя похоже, что это действительно заставило вещи сдвинуться с мертвой точки. .. :)

Вернемся к Next sprint planning , так как мы не добрались до этого в этой вехе.

Мы перенесли эту проблему в этап Backlog. Это означает, что он не будет работать над предстоящим релизом. Мы проведем повторную оценку невыполненной работы после текущего выпуска и рассмотрим этот пункт в то время. Чтобы узнать больше о нашем процессе управления проблемами и получить больше информации о различных типах проблем, вы можете прочитать наш процесс сортировки .

Мы добавим поддержку этого в 5.0!

Это собирается сделать это в конце концов?

@guitax, учитывая, сколько раз он откладывался, а также тот факт, что он был возвращен в список невыполненных работ, я бы сказал, что шансы действительно очень малы 😕 Похоже, что новый приоритет теперь — это blazor.

Будем надеяться, что это в конечном итоге будет реализовано, поскольку это действительно раздражающая проблема. 😂

По крайней мере, было бы неплохо, если бы это требование было более четко изложено в документации. Отсутствующие атрибуты со стандартным значением по умолчанию являются нормой в HTML; мысль о том, что они потребуются для компонентов представления, мне не приходила в голову, пока я не наткнулся на эту ветку.