C# > Blazor and Web Development > Blazor Components > Component Parameters

Passing Data to Blazor Components with Parameters

This example demonstrates how to define and use component parameters in Blazor to pass data from a parent component to a child component. Component parameters allow you to make your components reusable and customizable.

Defining a Component with Parameters

This code defines a simple Blazor component named `MyComponent`. It has two parameters: `Title` and `Message`. The `[Parameter]` attribute is crucial; it tells Blazor that these properties are intended to be set from outside the component. The component displays the `Title` in an `

` tag and the `Message` in a `

` tag.

@page "/mycomponent"

<h3>@Title</h3>
<p>@Message</p>

@code {
    [Parameter]
    public string Title { get; set; }

    [Parameter]
    public string Message { get; set; }
}

Using the Component in a Parent Component

This code shows how to use the `MyComponent` in another Blazor component, here named `Parent`. The values for the `Title` and `Message` parameters are passed as attributes when using the `MyComponent` tag. Notice that we can use `MyComponent` multiple times with different parameter values, demonstrating reusability.

@page "/parent"

<h1>Parent Component</h1>

<MyComponent Title="Greeting" Message="Hello from the parent component!"></MyComponent>
<MyComponent Title="Farewell" Message="Goodbye!"></MyComponent>

@code {

}

Concepts Behind the Snippet

  • Component Parameters: Component parameters are properties within a Blazor component that are marked with the `[Parameter]` attribute. These properties can be set from outside the component, allowing data to be passed in.
  • Data Flow: The data flows from the parent component (the component that uses the child component) to the child component (the component with the parameters).
  • Reusability: Component parameters are fundamental to creating reusable components. By accepting parameters, a component can adapt its behavior or appearance based on the data provided to it.

Real-Life Use Case

Imagine you are building a product listing. You could create a `ProductCard` component. This component would accept parameters such as `ProductName`, `ProductDescription`, `ProductPrice`, and `ImageUrl`. The parent component (e.g., a product catalog page) could then iterate through a list of products and render a `ProductCard` for each one, passing the relevant product data as parameters. This avoids code duplication and keeps the UI consistent.

Best Practices

  • Use descriptive parameter names: Choose parameter names that clearly indicate the purpose of the parameter. This improves code readability and maintainability.
  • Provide default values (where appropriate): Consider providing default values for parameters, especially if the parameter is optional. This makes the component easier to use and reduces the risk of errors.
  • Consider using strongly-typed parameters: Instead of using `string` for everything, use more specific data types (e.g., `int`, `decimal`, custom classes). This improves type safety and reduces the risk of runtime errors.
  • Document your parameters: Use XML documentation comments to document the purpose of each parameter. This makes it easier for other developers to understand how to use your component.

When to Use Them

Use component parameters whenever you want to make a component reusable and customizable. If a component's behavior or appearance depends on data that is provided from outside, then it's a good candidate for using parameters. Avoid hardcoding values within a component when those values are likely to change or vary across different use cases.

Alternatives

Alternatives to component parameters include using a service to share state between components or using cascading parameters. Services are generally used for managing application-wide state, while cascading parameters are used to pass data down through a hierarchy of components without having to explicitly pass it to each component. Component parameters are ideal when a parent component knows exactly the data the child component requires.

Pros

  • Reusability: Components can be used in multiple places with different data.
  • Modularity: Promotes modular design by separating concerns.
  • Testability: Easier to test components in isolation by providing different parameter values.
  • Readability: Makes code more readable by clearly defining the input to a component.

Cons

  • Complexity: Can add complexity if overused or not well-managed.
  • Performance: Excessive parameter passing can potentially impact performance (though this is rarely a significant concern in typical Blazor applications).

FAQ

  • What happens if I don't provide a value for a parameter?

    If you don't provide a value for a parameter, the parameter will have its default value (e.g., `null` for strings and reference types, `0` for integers, `false` for booleans). If the parameter is a non-nullable type and you don't provide a value, you will get a compilation error.
  • Can I use different data types for parameters?

    Yes, you can use any data type for parameters, including strings, numbers, booleans, custom classes, and even other components. Using strongly-typed parameters is generally recommended for better type safety.
  • Can I have multiple parameters?

    Yes, you can have as many parameters as you need.