Kentico Xperience 13 Beta 3 - Page Builder View Components in ASP.NET Core
Sean G. Wright
Posted on June 24, 2020
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.
-
- This provides access to services we need:
- 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 MVCICurrentPageRetriever
.
- This method is passed a view model containing our Widget's properties and returns a
- 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
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:
Posted on June 24, 2020
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.