Kentico Xperience 13 Beta 3 - Page Builder View Components in ASP.NET Core

The Kentico Xperience 13 Betas let us, the development community, get access to the latest upcoming features in the next version of Kentico Xperience.

Beta 3 is now available. So let's dive in 🤽🏾‍♀️!

How to Get the Kentico Xperience 13 Beta

To get access to the beta we need to have a DevNet account. If you don't have one, you can register here.

After logging into DevNet with our account, we can download the beta in the downloads section of the site.

The beta has instructions 📃 on how to get it up and running, what features are new in this version, the list of known issues, and what the focus should be for developers and users of Kentico Xperience when trying out this version of the beta.

Using the Page Builder with ASP.NET Core

Beta 2 made it possible to run Kentico Xperience on .NET Core. However, there were many limitations on what was available. Key among those was the Page Builder, which has been an amazing feature of Kentico 12 MVC.

It should be no surprise that the feature of Beta 3 that I find most interesting is the ability to use the features of the Page Builder in ASP.NET Core 🎉🙌.

View Components

The biggest change when comparing Page Builder functionality in Kentico 12 MVC and Kentico Xperience 13 is the move from Widget and Section Controller classes to relying completely on View Components.

This change makes sense because View Components were designed to be the replacement for Controller Child Actions 🤓 (which is how Kentico 12 MVC Widgets were built).

Let's take a look 🧐 at the sample code from the DancingGoat demo site for an ArticlesWidgetViewComponent:

// Inherit from the ViewComponent class ✅
public class ArticlesWidgetViewComponent : ViewComponent
{
    public const string IDENTIFIER = "DancingGoat.HomePage.ArticlesWidget";

    private readonly ArticleProvider provider;
    private readonly IPageUrlRetriever pageUrlRetriever;

    // Inject any dependencies we need ✅
    public ArticlesWidgetViewComponent(
        ArticleProvider provider,
        IPageUrlRetriever pageUrlRetriever)
    {
        this.provider = provider;
        this.pageUrlRetriever = pageUrlRetriever;
    }

    // One method, called by the framework ✅
    public ViewViewComponentResult Invoke(
        ComponentViewModel<ArticlesWidgetProperties> viewModel)
    {
        var articles = provider.GetLatestArticlesByNodeAliasPath(
            "/Articles",
            viewModel.Properties.Count);

        var articlesModel = articles
            .Select(article => ArticleViewModel.GetViewModel(
                article,
                pageUrlRetriever)
            );

        // We can store our view file anywhere ✅
        string viewPath = "~/Components/Widgets/Articles/_ArticlesWidget.cshtml";

        return View(viewPath,
            new ArticlesWidgetViewModel
            {
                Articles = articlesModel,
                Count = viewModel.Properties.Count
            });
    }
}

Now, let's note the key differences:

• We inherit from ViewComponent:
  • This is a built-in ASP.NET Core type
  • It replaces Kentico 12 MVC WidgetController<TProperties>.
• We use constructor injection:
  • This provides access to services we need:
    • ArticleProvider for data access
    • The Kentico provided IPageUrlRetriever to generate URLs.
• We have a single method, Invoke():
  • This method is passed a view model containing our Widget's properties and returns a ViewComponentResult.
  • There is an async variation of this method if we need it.
  • ComponentViewModel<TModel> gives us access to the current document context, instead of the Kentico 12 MVC ICurrentPageRetriever.
• The View path can point anywhere:
  • We can specify the path to our View for our View Component.
  • Or we can rely on the convention based view search path.

View Component Benefits

View Components are a much better solution than Controller Child Actions for building out the parts of Kentico Xperience's Page Builder functionality.

So, now that we've noted what's different when compared to a Kentico 12 MVC Widget, let's look at the benefits 😎 these differences bring!

Sync and Async

Where Controller Child Actions were only synchronous, View Components support both a synchronous IViewComponentResult Invoke() and asynchronous Task<IViewComponentResult> InvokeAsync() execution.

This is great if you want to access any asynchronous ASP.NET Core services or make calls to external services in our View Component, since these types of calls allow for higher request concurrency when they are asynchronous 👍🏾.

Built Into ASP.NET Core

View Components are also an ASP.NET Core type, which means we don't need any special Kentico code to make them work. We can opt-in to all the Kentico functionality we want through Dependency Injection, for additional services, or through the ComponentViewModel<T> parameter of the Invoke() method.

View Components have a single method (Invoke()/InvokeAsync()). This follows the Single-Responsibility Principle and keeps the View Component code focused. Compare this to MVC Controllers which could have an infinite number of Action methods 😟.

This thoughtful design from the framework helps us to write better applications 😄.

Simplified Rendering

Unlike Controller Child Actions in ASP.NET MVC, View Components don't participate in the request pipeline, so Action Filters are not executed when they are rendered.

This is great because it leads to faster 💪🏽 execution when rendering Widgets and Sections and it's also less confusing, as the only code executed when rendering a View Component is that View Component's code!

Feature Folder View Configuration

Finally, View Components have flexible configuration and their View files can be stored outside the ~/Views folder 🤔.

This means we can follow the Features Folder pattern (which I highly recommend and detail in my post Kentico 12: Design Patterns Part 3 - Tips and Tricks, Application Structure), and co-locate the .cshtml files with the C# class definitions.

In fact, the DancingGoat sample application takes this very approach ❤🎉🥳!

Kentico 12: Design Patterns Part 3 - Tips and Tricks, Application Structure

Sean G. Wright ・ Jun 1 '19 ・ 7 min read

#mvc #designpatterns #kentico #aspnet

Conclusion

Now that Kentico Xperience 13 Beta 3 is out, we can explore the cool 😎 features of Kentico 12 MVC in a whole new ASP.NET Core world.

For those of us used to building Page Builder functionality with Controller Child Actions, we might find the transition to using View Components a little confusing 🤨.

Fortunately, we've covered the major differences between the Kentico 12 MVC and Kentico Xperience 13 (on ASP.NET Core) approaches to Widgets and Sections.

We've also reviewed the benefits that come with this change:

• ✔ Sync and Async execution
• ✔ View Components are built into ASP.NET Core
• ✔ Simplified rendering process (no filter execution)
• ✔ Feature Folders architecture is enabled

As always, thanks for reading 🙏!

We've put together a list over on Kentico's GitHub account of developer resources. Go check it out!

If you are looking for additional Kentico content, checkout the Kentico tag here on DEV:

Or my Kentico blog series:

• Kentico 12: Design Patterns
• Kentico CMS Quick Tips