Aspnetcore: Переименуйте компоненты Razor обратно в серверный Blazor

Это утвержденное решение? Можем ли мы еще проголосовать?

Лично я против изменения названия. Я думаю, что Razor Components - лучшее название. :(

@xclud Это открытый форум, поэтому отзывы всегда приветствуются 😃

Мы по-прежнему будем называть компонентную модель компонентами Razor (т.е. файл .razor по-прежнему будет компонентом Razor), но когда мы говорим о модели приложения, мы обнаруживаем, что иметь разные имена очень громоздко. За названием Blazor уже есть довольно сильный импульс, поэтому мы хотели бы его придерживаться. Имена, конечно, субъективны - какое бы имя мы ни выбрали, не все будут счастливы, но Blazor, похоже, пока неплохо нам служил.

Я считаю, что это хороший ход. Не было конца путанице в отношении отношений между Razor Components и Blazor. До такой степени, что люди думали, что они разные фреймворки, а не просто разные способы рендеринга.

К тому же, на мой взгляд, Blazor - классное имя.

Как человек, который очень часто говорит с людьми о Blazor. Компоненты Razor - это не что иное, как путаница. Это сбивает с толку: когда приложение Blazor является приложением Razor Components, компоненты Razor в их отношении к [Razor Pages & Razor Class Libraries] и спотыкаются о себе, когда говорят Razor / Blazor. Это также затрудняет писать о Blazor, затрудняет поисковую оптимизацию, я мог бы продолжить.

Здравомыслие преобладает! Большое спасибо за это изменение.

Что происходит с расширениями файлов .razor, поскольку страницы razor по-прежнему имеют формат .cshtml, а компоненты - .razor, может быть полезно называть его .blazor? Или называть страницы razor также .razor вместо .cshtml?
Довольно запутанный материал

Мы планируем сохранить расширение .razor для компонентов. Компоненты основаны на синтаксисе Razor, но компоненты обрабатываются компилятором Razor по-разному, поэтому им требуется другое расширение файла.

А как насчет шаблона, размещенного на Blazor? Для модели на стороне клиента это самый простой способ:

• применение заголовков безопасности CSP
• вычисление хэшей SRI (в идеале это также потребуется для ресурсов, загружаемых напрямую с помощью blazor.webassembly.js)
• сжатие ресурсов (по крайней мере, до тех пор, пока файлы dll не будут отправлены с типом содержимого wasm, который уже сжат парой опробованных мной CDN)

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

Мне также нравится это переименование обратно в "Blazor". Банкоматы говорят с людьми о компонентах Blazor и Razor - это просто путаница.

Blazor - это технология с (как минимум) двумя хостинговыми моделями. Итак, мне нравится Blazor!

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

Я приветствую это изменение! Мне кажется, что новое (или старое) наименование гораздо менее запутанно.

Я согласен с @vertonghenb, что расширение файла также следует переименовать в .blazor . В этом гораздо больше смысла. И .cshtml и .razor имеют синтаксис бритвы, но только один должен иметь специальный код Blazor, который сделает расширение файла .blazor более точным и менее двусмысленным ИМХО.

Краткий комментарий: я согласен с изменением имени с _Razor Components_ на _Server-side Blazor_.

Длинный ответ: я считаю, что и клиентские, и серверные «компоненты» должны иметь одно и то же имя, каким бы оно ни было: Blazor, Razor Components, ASP.NET Core Components. Например, React и React Native - это гораздо более разные технологии, но у них одно и то же имя.

Преимущество названия Blazor:

• Это уже хорошо зарекомендовавшее себя имя в сообществе. На самом деле это также понимается как технология для запуска .NET в браузере, что не на 100% правильно.
• Людям может быть легче принять / понять, что Blazor можно использовать без .NET на стороне сервера (фактически без какой-либо стороны сервера).

Преимущество названия компонентов Razor:

• Связывание с Razor и ASP.NET Core может помочь людям понять, что технология будет иметь надлежащую поддержку и стабильность. Хотя, поскольку Blazor уже привлек много внимания, я думаю, что он понимается как стабильная технология.

А что касается расширения, это зависит от того, насколько расширяема компиляция Razor. Если, например, в будущем будут создаваться статические страницы Razore также с расширением .razor и компилятор сможет справиться с этим, я бы оставил расширение .razor . В основном, как .xaml extension используется для элементов управления, страниц, ресурсов, объектов приложения.

Я думаю, это вполне достижимо. Я не знаю, каков текущий статус поддержки кода программной части для компонентов Razor. Однако, если есть, то код программной части определяет, унаследован ли компонент от ComponentBase или чего-то еще. И это может определить, как должен компилироваться файл .razor . А без наследования по умолчанию для кода программной части является ComponentBase, и в будущем может появиться возможность изменить базовый класс по умолчанию.

Однако, если будущие объекты Razor должны будут иметь другое расширение, тогда .blazor для компонентов Blazor будет гораздо лучшим вариантом.

Я очень приветствую это изменение! Название «компоненты Razor» всегда немного сбивало с толку, потому что ожидалось, что это будет чисто серверная вещь, как и все остальное, что делает Razor. Таким образом, ожидалось, что компоненты Razor, подобно пользовательским элементам управления в WPF, являются способом составления настраиваемых компонентов с использованием синтаксиса Razor вместо кода (как позволяют помощники тегов).

Переименовав это, эта путаница исчезнет, ​​и у нас действительно есть шанс в какой-то момент придумать компонуемые компоненты Razor на стороне сервера.

Что касается расширения .razor , я считаю, что, как и другие, было бы разумнее использовать вместо него .blazor . Насколько я понимаю, эти файлы могут содержать код, который жизнеспособен только в контексте Blazor, поскольку логика глубоко связана с компонентом. Я не предполагаю, что это можно будет повторно использовать в контексте, отличном от Blazor. Кроме того, если клиентские компоненты Blazor в конечном итоге будут использовать то же самое, я думаю, что последовательное использование .blazor является лучшей идеей для идентификации компонентов Blazor (которые затем могут использоваться как на стороне сервера, так и на стороне клиента) .

Я знаю, что @poke и @duracellko мимоходом упоминали термин компоненты blazor, но мне действительно нравится это название. А как насчет __Blazor Components__ вместо __Blazor (на стороне сервера) __?

Ой. и я думаю, что .blazor в качестве имени расширения тоже хорошая идея.

@myty Я думаю, что концептуально компоненты всегда были «компонентами Blazor» (т.е. вы создаете компоненты с помощью Blazor). «Blazor (на стороне сервера)» и «Blazor (на стороне клиента)» - это две разные модели хостинга, в которых вы можете использовать и запускать одни и те же (я думаю?) Компоненты Blazor. Таким образом, вы должны использовать как «компоненты Blazor», чтобы описать, что вы создаете компонент, так и «серверный Blazor», чтобы описать, как вы выполняете компоненты Blazor.

@myty Я думаю, что концептуально компоненты всегда были «компонентами Blazor» (т.е. вы создаете компоненты с помощью Blazor). «Blazor (на стороне сервера)» и «Blazor (на стороне клиента)» - это две разные модели хостинга, в которых вы можете использовать и запускать одни и те же (я думаю?) Компоненты Blazor. Таким образом, вы должны использовать как «компоненты Blazor», чтобы описать, что вы создаете компонент, так и «серверный Blazor», чтобы описать, как вы выполняете компоненты Blazor.

Тот факт, что это всегда были компоненты Blazor, был тем, что мне понравилось. Скажите, как есть, и это тоже звучит круто. :)

... но я также вижу путаницу между серверной и клиентской стороной. Трудно рассказать историю, не назвав их специально.

Да! Наконец-то :) Блазор - настоящее имя.

ты вообще пылаешь?

да

Для меня Blazor = WASM.

Так что «Razor Components» (SignarR!) - это совсем другое. Объяснить разницу достаточно просто: Blazor - это WASM.

ИМХО.

Это однозначно правильное решение. Даже после того, как был введен новый термин «компоненты Razor», я и мои коллеги по-прежнему называем его серверным Blazor. Я также предпочитаю расширение .blazor или что-то вроде .component. Представления в MVC также используют синтаксис razor, поэтому .razor вносит дополнительную путаницу.

Я думаю, что поворот к переименованию компонентов Razor обратно в Blazor - это хорошо.

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

Я думаю, что .blazor или .component будут лучшей альтернативой, чем .razor .

Спасибо, что вернули это имя обратно на серверную сторону Blazor . Я рад, если честно. У меня был маленький лолвут? момент, когда я впервые услышал изменение названия на Razor Components .

Лично я считаю, что слово Razor достаточно перегружено:

• Бритва
• Просмотры Razor
• Razor Pages
• Контроллеры страниц Razor
• Модели страниц Razor
• Библиотеки классов Razor
• Частичные просмотры Razor
• Компоненты Razor View
• : new: Компоненты Razor: confused: //confusing much yet?
• Следующая функция семейства Razor : // just kidding :)

Мы уже усложнили кому-то новичку, пытаясь ориентироваться во всех этих вещах Razor, а также пытались понять каждый вариант использования.

Не только сочувствие новичкам, но и попытка объяснить и поддерживать «правильную» терминологию в больших командах при описании и координации (как / когда / что) использовать.

Blazor - хорошее имя, поскольку мы уже привыкли к его вариантам использования. Йо, даже Razor Sockets было бы лучше, чем Razor Components . :солнечные очки:

Кроме того, я считаю хорошей идеей переименование .razor в .blazor .

Именование сложно.
Будьте проще.

-Брайан :)

Интерес к Razor Components, потому что он хорошо сочетается с моим проектом, привел меня сюда.
Я понимаю, о чем мы говорим, но тот, кто только начинает, может быть сбит с толку из-за того, что находится под капотом, из-за наименования.
Если цель состоит в том, чтобы поставлять компоненты Razor просто как временную замену грядущему Blazor, я бы не хотел, чтобы его название изменялось.

@Mitiko Серверный Blazor не будет зависеть от решений, касающихся клиентского Blazor (на основе WebAssembly). Предполагая, что последний будет выпущен в какой-то момент, вы все равно сможете использовать серверный Blazor. Обе модели приложений фактически смогут совместно использовать определенные вещи, поэтому имеет смысл также согласовать их с их именем.

Вот почему это в конечном итоге сбивает с толку. Когда у вас есть логика, которой все равно, где она размещена, как она называется? Затем фреймворк волшебным образом меняет имена в зависимости от того, какую «оболочку» вы используете. Просто не имеет смысла иметь два имени. По поводу того, что думает @poke , смотрите видео ниже: @Mitiko

https://www.youtube.com/watch?v=dNQ7MgPZby4

А как насчет шаблона, размещенного на Blazor?

@ghidello Все остается как есть. Таким образом, будет три шаблона Blazor: автономный клиентский, размещенный на ASP.NET Core и серверный.

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

ИМО, вы также должны назвать имя модели компонента, чтобы ссылаться на Blazor, даже если вы используете синтаксис / движок Razor. Это просто сделало бы его более сплоченным универсальным решением с разумным наименованием.

Что насчет пространства имен компонентов? Его тоже надо переименовать.

И файлы .razor должны быть .blazor, поскольку они связаны с технологией Blazor. В противном случае их следует использовать и для обычного Razor Mvc.

Все еще немного запутался в отношении компонентов:

Итак, если я создаю библиотеку компонентов, которая работает как с серверной, так и с клиентской стороной Blazor, могу ли я называть компоненты «компонентами Blazor» или «компонентами Razor»?

@egil Исходя из того, что сказал Дэн Рот выше, компонент по-прежнему будет называться Razor Component.

Мы по-прежнему будем называть модель компонентов компонентами Razor (т.е. файл .razor по-прежнему будет компонентом Razor).

Добавляю свой голос одобрения этого изменения.

На мой взгляд, RazorComponent - это компонент C #, написанный с использованием синтаксиса Razor и кода C #. Мы могли бы использовать RazorComponents в широком спектре проектов, включая Blectron (как в демонстрации StorageExplorer), HTML-генераторы (например, для генерации тела письма так же, как RazorGenerator делает для .cshtml content. Они не ограничиваются только Blazor .

Напротив, Blazor - это платформа приложения, которая использует RazorComponents на клиенте, используя две разные модели хостинга (WebAssembly и серверную).

Я добавил диаграмму, которая показывает, как я это вижу .. комментарии приветствуются

Blazor (на стороне клиента с WASM) и Blazor (на стороне сервера с .NET Core) звучит великолепно!

Компоненты Razor для пользовательского интерфейса обоих, с Blazor в качестве основы для приложений, независимо от модели размещения. Просто, чисто, и, как сказал бы один из моих любимых комиков .... GIT R DONE!

Клиентская и серверная стороны Blazor действительно хороши.
А новичкам легче понять разницу между клиентской и серверной частью.

Как уже говорили другие, есть веские причины рассмотреть .blazor (и имя «компонента Blazor»). Можно ли использовать более подробное объяснение сохранения .razor (и его имени "компонента Razor")?

До сих пор я мог найти такое обоснование:

Мы планируем сохранить расширение .razor для компонентов. Компоненты основаны на синтаксисе Razor, но компоненты обрабатываются компилятором Razor по-разному, поэтому им требуется другое расширение файла.

Мне кажется, мой взгляд может быть слишком упрощенным:

const string serverSideName = "Blazor (server-side)";
const string clientSideName = "Blazor (client-side)";

string componentModel = "Razor Components";
string ext = ".razor";

if (serverSideName.Contains("Blazor") && clientSideName.Contains("Blazor"))
{
    componentModel = "Blazor Components";
    ext = ".blazor";
} 

Console.WriteLine(componentModel);
Console.WriteLine(ext);

Есть несколько причин, по которым мы предпочли бы сохранить расширение .razor:

• Название по-прежнему точное и информативное. Файл .razor - это компонент пользовательского интерфейса, написанный с использованием синтаксиса Razor.
• Уменьшите отток. Обновление расширения файла требует изрядной координации между несколькими командами и проектами. Поскольку мы уже проделали эту работу для .razor, мы бы предпочли не делать этого снова, если для этого нет действительно веской причины.
• Изолируйте структуру от изменений названия продукта или стратегии. Сохраняя более универсальное именование компонентной модели, мы надеемся уменьшить влияние любого потенциального перетасовки имен или изменений в направлении проекта в будущем.

@ danroth27 Меня беспокоит то, что синтаксис Razor присутствует как в файлах .cshtml, так и .razor. Я думаю, возникнет путаница, какое расширение для какого вида Razor Page / Component / MVC.

Остальные два пункта вполне справедливы.

@ danroth27

Название по-прежнему точное и информативное. Файл .razor - это компонент пользовательского интерфейса, написанный с использованием синтаксиса Razor.

В этом аргументе меня беспокоит то, что файл .razor содержит такие вещи, как обработчики событий, методы жизненного цикла или привязки переменных. Эти концепции очень специфичны для Blazor и не будут работать вне его. Таким образом, хотя это синтаксис Razor, это очень специфическая разновидность, которая позволяет выполнять логику на стороне клиента.

Эти вещи не будут работать для «компонентов Razor» исключительно на стороне сервера и с рендерингом на сервере, что может быть гипотетическим явлением в будущем (поскольку, например, фрагменты рендеринга будут довольно хорошо работать и на сервере).

Поэтому мы блокируем расширение файла .razor и имя «Компонент Razor» для определенного варианта Razor, который будет работать только для компонентов со встроенным поведением на стороне клиента.

@ danroth27 Почти все (включая меня) хотят, чтобы это .blazor вместо .razor тогда почему вы хотите придерживаться .razor индивидуально. Есть ли какие-нибудь технические проблемы, чтобы это изменить? или это предпочтение вы и ваша команда?

Спасибо.

Поскольку @ danroth27 упомянул координацию с несколькими командами, я могу думать о VS Team, Razor team team, это может быть большой кусок работы, у каждой команды разные приоритеты по задачам.

Я могу увидеть примерку расширения .razor если это будет более общая вещь, описывающая любые компоненты, написанные в Razor, например, как .xaml используется как для ресурсов, так и для элементов управления в мире рабочего стола.

Скажем, если возможно, в будущем вы могли бы использовать собственные элементы управления UWP / xaml созданные с помощью razor, а не html помощью электронов, а чисто собственные, поскольку императивный стиль создания элементов управления razor может быть убедительной альтернативой для .xaml's Текущий декларативный способ делать что-то (особенно поддержка razor для потоков управления C #).

Это теоретический пример, хотя на этом этапе вы могли бы сказать, что он использует компоненты Razor, но не в контексте Blazor, а в собственном контексте, таком как React Native, где вещи могут отличаться, например, разные привязки событий, некоторые специфические атрибуты Blazor не применимы. так далее...

Я рассматриваю Blazor как фреймворк, который использует компоненты Razor ( .razor ), например, как React как фреймворк использует .jsx/.tsx для составления компонентов, и как .jsx/.tsx , возможно, это будет может использоваться в других подобных фреймворках, например, как Vue и TKO поддерживают .jsx/.tsx путем настройки того, что система сборки делает с файлами .jsx/.tsx .

Спасибо всем за отзывы по этой проблеме. Переименование компонентов Razor обратно в серверное Blazor выполнено!

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

Также переименуйте метку feature-Components в feature-Blazor.

Уважаемые, я использую vs 2019, я установил последнюю версию Blazor, у меня есть предварительный просмотр ядра 3 4, я создал проект Blazor, все страницы теперь с расширением .razor вместо .cshtml, я запустил приложение, но дал мне Загрузка ... без перехода на страницу Index.razor, пожалуйста, помогите. Заранее спасибо.

@ImadMichaelAyoub Есть ли у вас сообщения об ошибках в консоли? Вы используете Blazor на стороне клиента или на стороне сервера?

Я бы предположил, что это, вероятно, не лучшее место для обсуждения. Возможно, лучше всего будет присоединиться к каналу Blazor Gitter (https://gitter.im/aspnet/Blazor), и мы сможем вам помочь.

Спасибо за ответ. Я использую клиентский Blazor. Кажется, что приложение запускает файл index.html в wwwroot и не перемещается в index.cshtml в папке страниц.

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

Мы планируем сохранить расширение .razor для компонентов. Компоненты основаны на синтаксисе Razor, но компоненты обрабатываются компилятором Razor по-разному, поэтому им требуется другое расширение файла.

Означает ли это - «Планируется сохранить такое же расширение .razor ... но требуется другое расширение, чем .razor, даже если оно не планируется»?

«Великие технологии сопровождаются большой путаницей в названиях»