Will it be possible to use Razor Components as well? Under the view components section in the .NET MVC section docs.microsoft.com/en-us/aspnet/co...
It mentions this:
"When considering if view components meet an app's specifications, consider using Razor Components instead. Razor Components also combine markup with C# code to produce reusable UI units. Razor Components are designed for developer productivity when providing client-side UI logic and composition. For more information, see Create and use ASP.NET Core Razor components.". Will this be supported?
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
Blazor Server requires a SignalR connection between the client and server and Blazor WebAssembly requires sending .dlls down to the client and running them on a WebAssembly compatible .NET runtime (Mono, currently).
There's nothing that stops you from using either of these technologies in any ASP.NET Core app, including a Kentico Xperience 13 site.
However, there is no built in functionality leveraging these technologies in Xperience 13.
Further, neither of these technologies is meant to be integrated with TagHelpers or ViewComponents, which are traditional MVC server-side rendering tools, and Blazor has an entirely different component model and tech stack.
Once you start using Blazor (and Razor Components) on part of the page, Blazor owns that part of the DOM and all child elements.
I'm very interested to see what kinds of cool things Kentico Xperience developers come up with now that we can build on ASPNET Core, and honestly, I wouldn't be surprised to see a team come up with a cool way to combine Xperience 13 and Blazor, but it's not going to be the most common solution for rendering, the way ViewComponents and TagHelpers will.
Thanks for the clarification. Also, do you know if using Kentico and f# can play nice together? I'm sure I could wrangle the asp.net core view layer to use fsharp and just leverage f# features to integrate kentico classes but i'm also interested in customizing kentico itself with fsharp.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
But all I'm doing here is using the .netstandard2.0 Kentico Xperience data access APIs from F#, which isn't that impressive since this is what F# on .NET has always done.
F# isn't supported for Razor, so that's one area you'll have to write C# (I don't think Razor supports VB.NET on ASPNET Core).
You can definitely write libraries in F# and use those in your C# applications. Those libraries can depend on the Kentico.Xperience.LibrariesNuGet package if needed.
You can also, like I did in the screen shot above, write your ASPNET Core code in F# and call Xperience APIs from the app, since it's all .NET.
Since Kentico Xperience has always been a C# based product, you will find a lot of F# integration un-ergonomic... 🤷♂️ it's just the nature of things.
Will it be possible to use Razor Components as well? Under the view components section in the .NET MVC section docs.microsoft.com/en-us/aspnet/co...
It mentions this:
"When considering if view components meet an app's specifications, consider using Razor Components instead. Razor Components also combine markup with C# code to produce reusable UI units. Razor Components are designed for developer productivity when providing client-side UI logic and composition. For more information, see Create and use ASP.NET Core Razor components.". Will this be supported?
Hey Daniel, great question.
Yes and no!
Razor Components are part of Blazor - which means they are not rendered through the traditional MVC / Server side Razor rendering process.
To use them you need to pick either Blazor Server or Blazor WebAssembly as your hosting model.
Blazor Server requires a SignalR connection between the client and server and Blazor WebAssembly requires sending .dlls down to the client and running them on a WebAssembly compatible .NET runtime (Mono, currently).
There's nothing that stops you from using either of these technologies in any ASP.NET Core app, including a Kentico Xperience 13 site.
However, there is no built in functionality leveraging these technologies in Xperience 13.
Further, neither of these technologies is meant to be integrated with TagHelpers or ViewComponents, which are traditional MVC server-side rendering tools, and Blazor has an entirely different component model and tech stack.
Once you start using Blazor (and Razor Components) on part of the page, Blazor owns that part of the DOM and all child elements.
I'm very interested to see what kinds of cool things Kentico Xperience developers come up with now that we can build on ASPNET Core, and honestly, I wouldn't be surprised to see a team come up with a cool way to combine Xperience 13 and Blazor, but it's not going to be the most common solution for rendering, the way ViewComponents and TagHelpers will.
Thanks for the clarification. Also, do you know if using Kentico and f# can play nice together? I'm sure I could wrangle the asp.net core view layer to use fsharp and just leverage f# features to integrate kentico classes but i'm also interested in customizing kentico itself with fsharp.
As a matter of fact, I was exploring this recently 😀
But all I'm doing here is using the .netstandard2.0 Kentico Xperience data access APIs from F#, which isn't that impressive since this is what F# on .NET has always done.
F# isn't supported for Razor, so that's one area you'll have to write C# (I don't think Razor supports VB.NET on ASPNET Core).
You can definitely write libraries in F# and use those in your C# applications. Those libraries can depend on the
Kentico.Xperience.LibrariesNuGet package if needed.You can also, like I did in the screen shot above, write your ASPNET Core code in F# and call Xperience APIs from the app, since it's all .NET.
Since Kentico Xperience has always been a C# based product, you will find a lot of F# integration un-ergonomic... 🤷♂️ it's just the nature of things.
You could always stick to C# but use Functional Extensions for C# or go fully functional with C# Functional Programming Language Extensions if you are feeling adventurous!
I've used both, the latter is drinking the functional kool-aid and the former is dipping your toes enough to reap some benefits.