Luego de buscar en varios repositorios y páginas webs de internet finalmente nos encontramos con la respuesta que te mostramos aquí.
Solo necesitas heredar de ComponentBase en tus ItemComponent clase como esta.
public class ItemComponent : ComponentBase
public async Task GetItems()
ItemModel[] ItemList;
HttpClient Http = new HttpClient();
ItemList = await Http.GetJsonAsync("api/Item/GetItems");
return ItemList;
El artículo está un poco desactualizado BlazorComponent fue renombrado hace un tiempo.
Solo asegúrese de mover todo el código que tiene en el functions bloquee su vista en la clase base, ya que mezclar los dos enfoques puede tener efectos secundarios extraños.
Tienes dos opciones. El primero ya lo mencionó Chris Sainty. Cree una clase que herede de ComponentBase y heredela en su vista de Razor.
Tu clase se definiría como:
public class MyBaseClass : ComponentBase
Y en tu vista de Razor usas:
@inherits MyBaseClass
Esto hace que MyBaseClass se convierta en una página de código subyacente para su vista de Razor y puede anular todos los eventos del ciclo de vida de la vista.
La segunda opción es crear un ViewModel. Creas una clase C # estándar y la inyectas en tu vista de Razor usando la inyección de propiedades.
Tú defines tu clase normalmente:
public class MyViewModel
E inyéctelo en su vista de Razor:
@inject MyViewModel
Esta clase ViewModel no conoce los eventos del ciclo de vida de la página y no depende de nada relacionado con Blazor. Si solo desea vincular su vista de Razor a un objeto y necesita algo que pueda reutilizarse (o desea ponerlo en un proyecto compartido), esta puede ser una buena opción.
Puede usar un código heredado detrás y un ViewModel inyectado en la misma Vista de Razor si lo necesita o si desea mantener el código del ciclo de vida de la página separado de sus enlaces de datos.
También hay otra solución aquí que es similar al punto de Louis Hendrick que:
Puede usar un código heredado detrás y un ViewModel inyectado en la misma Vista de Razor si lo necesita o si desea mantener el código del ciclo de vida de la página separado de sus enlaces de datos.
Considere el ‘estado’ como una alternativa a los modelos de vista
En los últimos años se ha hablado mucho de gestionar el estado actual de una aplicación utilizando el concepto de ‘Estado’. Esto es algo que ha sido particularmente popular en el mundo de React (y ahora en otros frameworks JS) desde el surgimiento del patrón Flux (y en particular la implementación de Redux).
¿Cuál es la diferencia entre estado y modelo de vista?
Un modelo de vista generalmente representa el estado de una página en particular y, a menudo, comprenderá propiedades relacionadas con la forma en que se representa esa página (por ejemplo, los datos para una lista de selección, una propiedad adicional para decir si una sección de la página debe ser visible, etc. ) y también una propiedad que contiene el objeto con los datos que se vincularán en esa página (por ejemplo, un SalesOrder clase dice).
El enfoque basado en el estado hace casi lo mismo, pero en lugar de agrupar el estado por la página que se aplica (como lo hace un modelo de vista), el enfoque basado en el estado a menudo agrupa el código por comportamiento (por ejemplo, todo el estado relacionado con pedir una pizza, entonces, de qué se compone la pizza actual y también qué elementos de la interfaz de usuario deben mostrarse si un pedido está en proceso) y reconoce que el estado puede ser mostrado por múltiples componentes, por lo que los objetos de estado no necesariamente se asignan directamente a un solo archivo de afeitar en el forma en que normalmente lo haría un ViewModel.
¿Por qué adoptar el enfoque estatal?
El enfoque basado en el estado tiene dos beneficios principales:
- Debido a que la clase de estado no depende de la clase o marco de la interfaz de usuario (por lo que no se hace referencia a Blazor, Razor, etc.), se puede probar como cualquier otra clase de C #. Eso significa que puede, por ejemplo, verificar si un botón estará deshabilitado cuando una propiedad en la clase de datos se establece en un cierto valor simplemente probando que
MyState.SaveButtonEnabled' property istrue”. Eso es mucho más simple que intentar probar el comportamiento a través de la automatización de la interfaz de usuario o similar. - El enfoque basado en el estado tiene en cuenta el hecho de que el estado de un área de funcionalidad en una aplicación a menudo cruza varios componentes o páginas. Para aplicaciones de una sola página (SPA) más pequeñas, a menudo es suficiente tener un objeto de estado único para representar toda la aplicación. Obviamente, ese enfoque solo funciona realmente para un SPA en el que toda la aplicación permanece durante la duración de la sesión del usuario.
Un excelente ejemplo y tutorial, cortesía del equipo de .NET
Esto es más fácil con un ejemplo y, afortunadamente, el taller de blazor de Blazing Pizza del equipo de Microsoft Blazor ofrece uno excelente.
Como ejemplo rápido de ese tutorial, este es el OrderState clase que contiene el estado actual relacionado con la orden en curso:
public class OrderState public event EventHandler StateChanged; public bool ShowingConfigureDialog get; private set; public Pizza ConfiguringPizza get; private set; public Order Order get; private set; = new Order(); public void ShowConfigurePizzaDialog(PizzaSpecial special) ConfiguringPizza = new Pizza() Special = special, SpecialId = special.Id, Size = Pizza.DefaultSize, Toppings = new List(), ; ShowingConfigureDialog = true; public void CancelConfigurePizzaDialog() ConfiguringPizza = null; ShowingConfigureDialog = false; StateHasChanged(); public void ConfirmConfigurePizzaDialog() Order.Pizzas.Add(ConfiguringPizza); ConfiguringPizza = null; ShowingConfigureDialog = false; StateHasChanged(); public void RemoveConfiguredPizza(Pizza pizza) Order.Pizzas.Remove(pizza); StateHasChanged(); public void ResetOrder() Order = new Order(); private void StateHasChanged() StateChanged?.Invoke(this, EventArgs.Empty); ```
Tenga en cuenta que esta clase de estado no tiene un concepto de la interfaz de usuario vinculada a ella, pero tiene propiedades que controlan el comportamiento de la interfaz de usuario.
Las clases de maquinilla de afeitar todavía tienen los bloques @functions también en ese ejemplo, pero se simplifican considerablemente al introducir propiedades en la clase State que tienen roles explícitos en el control del comportamiento de la interfaz de usuario (p. Ej. ShowingConfigureDialog). Por ejemplo, de index.razor:
@if (specials != null) @foreach (var special in specials)