View components are another brand new feature in ASP.NET Core that combines server code with view code to encapsulate chunks of the response.
- [Instructor] Another new feature in ASP.net core are View Components. And these combine server-side code with partial views and are used to render a chunk of the response. Some common uses are dynamically created menus, like in the same app provide for you, a login panel, or shopping cart. There are some limitations. They can't serve as a client-side end point, they don't use model binding, and they don't participate in the controller lifecycle.
So they're very similar to child actions, which have gone away, combined with partial views. To create a ViewComponent Class, create a new public, non-nested, nonsealed class; and those are actual requirements. Derive from ViewComponent. You don't have to derive from ViewComponent, there are some other games you can play, but really to get the most value out of a ViewComponent, you should derive from a ViewComponent. Then you implement the InvokeAsync and return an IViewComponentResult, which is typically a view.
Any data needed for the view needs to be passed into the view as a view model. And then typically, like I said, you return a partial view. The view that gets rendered is just a standard MBC partial view, the default name is "default.cshtml" but you can name it anything you want. There is a pretty strong restriction, though, of where these views can live. So you have to be either in...
Views/<controller_name>/Components/ <view_component_name>, and that's without the view component suffix, /<view_name>, or, where most people put them... Views/Shared/Components/<view_component_name>/<view_name>. If you want to invoke a ViewComponent from a layout, you call Component.InvokeAsync, the name of the view component, again, without the view component suffix, if you named it such.
And then anonymous type with any parameters that it might need. To invoke it from a controller action method, you would just call ViewComponent, with the name, and the anonymous type with parameters. There is an update to this in one point one, and that is a view component can be invoked as a Tag Helper from a view or layout. So let's look at a view component in code.
So here I have my CategoriesAsMenusViewComponent, I've derived from ViewComponent. You are not required to name it ViewComponent if you derive from ViewComponent, but that is pretty much the standard that people follow. Supports, dependents, and injection, so I have my I category repo here that will be passed in by the DI container built into ASP.net core. And then I have my InvokeAsync method.
So what this method is going to do is get all of the categories from the repository, and if it succeeds it'll return this partial view passing in the I list of categories into the view. If it fails, it'll return a content ViewComponent result, which is just text. Since I did not name it "default.cshtml", we have to specify the name of the view.
And this is similar how action methods work, right? If we don't follow the naming convention of an action method, we have to pass in the name of the view. Let's look at our view. It's very very simple. The model is an IEnumeral of category. We use an anchor Tag Helper to create the featured menu item. And then for each of the categories in the model, we create a new link. To plug this into our layout...
I have replaced a standard menu with Component.InvokeAsync here on line 37. The name of the ViewComponent, without the ViewComponent tag, dot result. I could also do an "@await" to render it the same way.
- Running and debugging ASP.NET Core applications
- Pros and cons of migrating existing applications to ASP.NET Core.
- Built-in dependency injection
- Environment awareness and app configuration
- Web host configuration and SSL
- View components invoked as tag helpers
- Configuration and logging
- Using Razor Pages