company_banner

Что нового в Blazor 0.7.0

https://blogs.msdn.microsoft.com/webdev/2018/11/15/blazor-0-7-0-experimental-release-now-available/
  • Перевод
Blazor 0.7.0 теперь доступен! В этом обновлении основное внимание уделяется ADRs (ancestor-descendent relationships). Кроме того, мы добавили некоторые улучшения в процесс отладки. Подробнее под катом!

Немного про Blazor: фреймворк для браузерных приложений, написанный на .NET и запускающийся с помощью WebAssembly. Он даёт вам все преимущества современных одностраничных приложений (SPA), позволяя при этом использовать .NET от начала и до конца, вплоть до общего кода на сервере и клиенте. [1]



Небольшое введение или «Что такое Blazor?».

Вот что нового в версии Blazor 0.7.0:

  • Каскадные значения и параметры
  • Усовершенствования отладки

Полный список изменений в этой версии можно найти в примечаниях к выпуску Blazor 0.7.0.

Получите Blazor 0.7.0


Установите следующее:

  1. .NET Core 2.1 SDK (2.1.500 или позднее).
  2. Visual Studio 2017 (15.9 или позднее) с ASP.NET.
  3. Последнее расширение Blazor Language Services из Visual Studio Marketplace.
  4. Шаблоны Blazor в командной строке:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates

Вы можете найти инструкции, документы и руководства для Blazor на blazor.net.

Обновите существующий проект до Blazor 0.7.0


Чтобы обновить проект Blazor 0.6.0 до 0.7.0:

  • Установите предварительные условия, перечисленные выше.
  • Обновите пакеты Blazor и ссылки инструмента .NET CLI до 0.7.0. Обновленный файл проекта Blazor должен выглядеть следующим образом:

<Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <RunCommand>dotnet</RunCommand>
    <RunArguments>blazor serve</RunArguments>
    <LangVersion>7.3</LangVersion>
</PropertyGroup>

<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Browser" Version="0.7.0" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="0.7.0" />
    <DotNetCliToolReference Include="Microsoft.AspNetCore.Blazor.Cli" Version="0.7.0" />
</ItemGroup>

</Project>

Это оно! Теперь вы можете оценить последние возможности Blazor.

Каскадные значения и параметры


Компоненты Blazor могут принимать параметры, которые могут использоваться для передачи данных в компонент и воздействовать на рендеринг компонента. Значения параметров предоставляются от родительского компонента к дочернему компоненту. Иногда, однако, неудобно передавать данные от компонента-предка к компоненту-потомку, особенно когда между ними много слоев. Каскадные значения и параметры решают эту проблему, предоставляя удобный способ для компонента-предка предоставить значение, которое затем доступно для всех компонентов-потомков. Они также обеспечивают отличный способ координации компонентов.

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

Предположим, что класс ThemeInfo передает всю информацию о теме, которую вы хотите передать по иерархии компонентов, чтобы все кнопки в этой части вашего приложения имели одинаковый внешний вид:

public class ThemeInfo 
{
    public string ButtonClass { get; set; }
}

Родительский компонент может обеспечивать каскадное значение с использованием компонента CascadingValue. Компонент CascadingValue обертывает поддерево иерархии компонентов и задает одно значение, которое будет доступно всем компонентам внутри этого поддерева. Например, мы могли бы указать информацию о теме как каскадный параметр для всех компонентов, составляющих тело макета:

@inherits BlazorLayoutComponent

<div class="sidebar">
    <NavMenu />
</div>

<div class="main">
    <div class="top-row px-4">
        <a href="http://blazor.net" target="_blank" class="ml-md-auto">About</a>
    </div>

    <CascadingValue Value="@theme">
        <div class="content px-4">
            @Body
        </div>
    </CascadingValue>
</div>

@functions {
    ThemeInfo theme = new ThemeInfo { ButtonClass = "btn-success" };
}

Чтобы использовать каскадные значения, компоненты могут объявлять каскадные параметры, используя атрибут [CascadingParameter]. Каскадные значения привязаны к каскадным параметрам по типу. В следующем примере компонент Counter изменен, чтобы иметь каскадный параметр, который привязывается к каскадному значению ThemeInfo, который затем используется для установки класса для кнопки.

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn @ThemeInfo.ButtonClass" onclick="@IncrementCount">Click me</button>

@functions {
    int currentCount = 0;

    [CascadingParameter] protected ThemeInfo ThemeInfo { get; set; }

    void IncrementCount()
    {
        currentCount++;
    }
}

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



Каскадные параметры также позволяют компонентам взаимодействовать по иерархии компонентов. Например, предположим, что у вас есть компонент TabSet, который содержит несколько компонентов Tab:

<TabSet>
    <Tab Title="First tab">
        <h4>First tab</h4>
        This is the first tab.
    </Tab>

    @if (showSecondTab)
    {
        <Tab Title="Second">
            <h4>Second tab</h4>
            You can toggle me.
        </Tab>
    }

    <Tab Title="Third">
        <h4>Third tab</h4>

        <label>
            <input type="checkbox" bind=@showSecondTab />
            Toggle second tab
        </label>
    </Tab>
</TabSet>

В этом примере дочерние компоненты Tab не передаются явно в качестве параметров в TabSet. Вместо этого они просто являются частью дочернего содержимого TabSet. Но TabSet все равно должен знать о каждой вкладке, чтобы она могла отображать заголовки и активную вкладку. Чтобы включить эту координацию, не требуя какой-либо конкретной связи с пользователем, компонент TabSet может представить себя как каскадное значение, которое затем может быть подобрано компонентами Tab-компонента:

В TabSet.cshtml:

<!-- Display the tab headers -->
<CascadingValue Value=this>
    <ul class="nav nav-tabs">
        @ChildContent
    </ul>
</CascadingValue>

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

В Tab.cshtml:

[CascadingParameter] TabSet ContainerTabSet { get; set; }


Посмотрите полный образец TabSet здесь.

Усовершенствования отладки


В Blazor 0.5.0 мы добавили поддержку отладки клиентских приложений Blazor в браузере. Хотя этот эксперимент продемонстрировал, что отладка приложений .NET в браузере возможна, это был довольно опасный опыт. Теперь вы можете более надежно установить и удалить breakpoints, а надежность пошаговой отладки была улучшена.

Microsoft

300,00

Microsoft — мировой лидер в области ПО и ИТ-услуг

Поделиться публикацией
Комментарии 27
    +2
    Вы бы хоть написали что это такое, Blazor. На самом деле интереснейшая вещь, собрали .Net runtime под Mono под webAssembly и заставили это исполнять IL. Выглядит интересно. (Сам не пробовал, восхищён подходом)
      0
      Согласен с вами, спасибо. Добавил небольшое описание.
      –3

      Blazor это типа ответ Microsoft гугловскому GWT?

        +2
        Нет
          0

          А можно как-то раскрыть ответ? Идеологически, проекты очень похожи. Компиляция в Wasm — это деталь реализации, её и к GWT прикрутить можно было, если бы Гугл не закопал проект

        +1
        В Blazor меня смущают две вещи:

        1. Насколько тяжёл (в байтах) будет итогвый рантайм?
        2. Интероп с JavaScript попахивает. Это не то же самое, что написать библиотеку на F# и спокойно использовать её в С# как будто она была написана на нем самом.

        В общем, сплошные эксперименты.
        +1
        «Мы запустим виртуальную машину в виртуальной машине, чтобы ты мог интерпретировать байт-код когда интепретируешь байт-код» :)
        [да, я знаю про AOT-режим и про то что что WASM компилируется при загрузке, но все равно забавно получается]
          0
          Выглядит как-то не очень оптимально. Не было бы более оптимально, если бы вместо WASM застандартизировали какой-нибудь существующий vm-рантайм? JVM, CLR…
          0
          Два вопроса.

          Первый Насколько я понимаю, wasm, это исключительно для быстрой и типизированной математики. То есть, в нем нет всего того, что есть в js, то есть самого синтаксиса. И насколько я понимаю, есть два варианта решения этой проблемы — написать свой js движок на wasm или проксировать самому js. Первый вариант очень объемный, второй медленный. То есть, если я прав, то единственно существующие проблемы вэба, помимо нелюбви к js, подобный подход только усугубит. Это так?

          И второй вопрос. Многие смотрят на вэб, как на какую-то фигню, амежду тем, современные клиентские вэб инструменты на много лет вперед опередили любые существующие технологии создания интерфейсов. Поэтому очень интересно чем именно вдохновлялись при создании этого инструмента?
            0
            в нем нет всего того, что есть в js, то есть самого синтаксиса. И насколько я понимаю, есть два варианта решения этой проблемы — написать свой js движок на wasm или проксировать самому js.

            Они собрали под WASM CLR. Зачем им движок JS?


            чем именно вдохновлялись при создании этого инструмента?

            ASP.NET MVC

              0
              А вы случаем не знаете сколько clr под wasm весит? Ведь если я правильно понимаю, то кроме кода самого приложения ещё придется и clr грузить? Если да, то поисковики такие вэб приложения никогда не пропустят в выдаче. Ещё интересно вот что. Гугл умеет парсить spa, а как дела будут обстоять с подобными приложениями? То есть spa впрод уже сегодня можно делать, а подобные когда и можно ли будет вообще хоть когда-то? Для очень крутых приложений обязательно нужно ssr настраивать. Как дела с ssr у текущей технологии?

              .net mvc я бы не хотел использовать в 2019 для построения интерфейсов.
                0
                А вы случаем не знаете сколько clr под wasm весит?

                Что мешает самостоятельно посмотреть в веб-инспекторе? :) https://lupblazordemos.z13.web.core.windows.net/ целиком весит порядка 7 Мб.


                Ведь если я правильно понимаю, то кроме кода самого приложения ещё придется и clr грузить?

                Да.


                Гугл умеет парсить spa, а как дела будут обстоять с подобными приложениями?

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


                Как дела с ssr у текущей технологии?

                Хотят, но не в приоритете. Понемногу экспериментируют.

                  0
                  Никто не делает? А кому они вообще такие приложения нужны? Вспомните фразы, когда вэб программисты говорят о разработке десктопа и мобайла на js? Вот теперь им есть чем ответить. Вэб на .net — хаха! Я обожаю .net, я обожаю js и точно говорю, что при таком раскладе, это мертвяк.
                  wasm сделали для быстрой математики. Время когда подобные условия даже не будут браться в расчет… это сколько километров броды нужно сбрить?
                    0

                    Какую-то свою нишу занять вполне может, особенно если команда бэкендеров-фуллстеков уже есть. Перенести фронтенд из ASP.NET MVC на Blazor скорее всего будет проще, чем писать с нуля на React, Angular или другом подобном.


                    Что касается индексации, то она тоже нужна далеко не всем проектам. Большая часть ниши SPA — это всякие админки и веб-приложения. Так что взлететь вполне может, особенно с учётом поддержки Майкрософта.

                      +2
                      Нишу? Да. Чуваков, которые как непробиваемые динозавры не хотят поверить что часть вэба под названием frontend самая крутая в построении интерфейсов. Вот они непременно будут мучатся делать уродливую админку на текущем инструменте.

                      Проще быть не может! Самое простое и самое современное это angular и react.

                      И сегодня только трешсайты не используют spa. Прошло то время, когда spa было только для админок.
                        +1
                        Чуваков, которые как непробиваемые динозавры не хотят поверить
                        Проще быть не может! Самое простое и самое современное это

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

              Ну, это довольно смелое утверждение. Что каксается Ангуляра, то для .NET разработчика там нет ничего нового — это тот же самый XAML + ReactiveUI. Как видите, реактивное программирование использовалось в .NET ещё с 2013 года. Про DI я даже не говорю. По поводу React + Redux, то у меня есть сильные сомнения по поводу этой связки, учитвая количество хаков и бойлерплейта вокруг всего этого, я не удвлюсь, если через несколько лет это будет «considered harmful». Про Vue не говорю, так как это китайская реплика Angular.
              Поэтому очень интересно чем именно вдохновлялись при создании этого инструмента?

              Ангуляром. Blazor == Angular.NET == XAML + ReactiveUI. Учитывая, что ReactiveX это изначально разработка Microsoft, то получается, что своими же идеями и вдохновлялись.

              0

              Узнал о Blazor отсюда. Здорово, что есть и что развивается. WebAssembly видимо будущее веб разработки.

                0
                Вот бы ещё разметку на xaml писать можно было)
                  0
                  Можно и разметку на XAML писать (точнее на Xamarin.Forms)
                    0

                    Возможно, в перспективе, можно будет AvaloniaUI запустить в wasm… Ну или Xamarin.Forms.

                      0
                      AvaloniaUI вряд ли, а вот Xamarin.Forms уже запускается, смотрите мой коммент выше
                    0
                    Поковырял 3 шаблона для студии, в последнем используется app.UseServerSideBlazor<App.Startup>();
                    для вызова проекта с blazor(netstandart) через net core проект, есть какой то практический смысл в этом?
                      0
                      Работаю с Blazor уже некоторое время. Пишем backend на asp.NET MVC, Core. На frontend используем jQuery, React.js, Vue.js. Могу всем кто пишет backend на asp.NET рекомендовать ознакомление с Blazor. Это совсем другой подход и поначалу кажется фантастикой.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое