Skip to content

Contributing

Jump to bottom
Mladen Macanović edited this page Feb 12, 2026 · 32 revisions

Contributing to Blazorise

We welcome contributions, ideas, and feature requests from the community. Blazorise thrives on collaboration, and we appreciate every effort to improve the project.

All contributions require agreement to our Contributor License Agreement (CLA). By signing the CLA, you confirm that you have the right to grant us permission to use your contribution. The CLA will be presented automatically when you submit a Pull Request.

For full CLA details, please review: https://gist.github.com/stsrki/abfa5ce0f4a5cf1e6ac67b92f8eb5d63

Getting Started

Before contributing, please review our official contribution guide:

https://github.com/Megabit/Blazorise/blob/master/CONTRIBUTING.md

This guide explains how to:

  • Set up the development environment
  • Build the solution
  • Run demo projects
  • Structure your Pull Request

Please ensure the solution builds cleanly before submitting changes.

Conventions & Guidelines

To maintain readability, consistency, and long-term maintainability, we ask contributors to follow the repository conventions when submitting Pull Requests.

We will not reject contributions solely for style issues, but we may request adjustments to align with the established guidelines.

These conventions may evolve over time as the codebase is refactored and modernized. Suggestions for improvement are always welcome.

Formatting

Please adhere to the formatting rules defined in the provided .editorconfig file whenever possible.

Coding Conventions

Naming

We follow consistent naming rules throughout the project:

  • Private fields use camelCase private string exampleField;

  • Methods use PascalCase private void ExampleMethod()

  • Properties use PascalCase public string ExampleProperty { get; set; }

  • Constants use UPPER_CASE with underscores public const string EXAMPLE_CONSTANT

  • Local variables use camelCase var exampleVariable = ...;

General Coding Guidelines

  • Prefer is null / is not null over == null / != null
  • Prefer null propagation where applicable
  • Prefer target-typed new when clarity is preserved
  • Avoid unnecessary verbosity
  • Keep methods focused and readable

For boolean properties:

  • Prefer prefixless names for simple properties (e.g., Loading instead of IsLoading)
  • If exposing a computed getter, the Is prefix is appropriate IsLoading => Options?.Loading ?? Loading ?? false;

RTL Support Considerations

Blazorise supports (and plans further support for) Right-To-Left layouts.

When designing layout-related APIs:

  • Prefer Start over Left
  • Prefer End over Right

These terms are direction-agnostic and work for both LTR and RTL environments.

Blazor Component Structure

When creating or modifying components, separate markup and logic into two files:

  • ComponentName.razor — markup and rendering concerns
  • ComponentName.razor.cs — parameters, members, and component logic (code-behind)

This separation improves maintainability and readability.

Code-Behind Structure

Code-behind files should follow this region structure:

public partial class MyComponent : BaseComponent
{
    #region Members

    #endregion

    #region Constructors

    #endregion

    #region Methods

    #endregion

    #region Properties

    #endregion
}

Keeping a consistent layout makes navigation and maintenance easier across the entire codebase.

Render Fragments

RenderFragment parameters should use the *Template suffix for clarity and consistency.

Examples:

  • ItemTemplate
  • LoadingTemplate
  • HeaderTemplate

Styling & CSS Conventions

Component CSS Naming

  • Prefer b-{component} instead of b-is-{component}

Provider Awareness

Blazorise supports multiple CSS providers. When working with styling or classes:

  • Avoid hardcoding provider-specific class names
  • Use ClassProvider and StyleProvider abstractions where differences exist between providers

This ensures cross-provider compatibility.

CSS Naming Rules

Follow the naming conventions of the underlying CSS framework when applicable.

The b- prefix is used only in the Blazorise.csproj core library because the CSS framework is unknown at that level. The prefix ensures clarity and avoids conflicts.

Public API Stability

Backward compatibility is extremely important.

Please do not introduce breaking changes to public APIs without careful consideration.

If a change is necessary:

  • Propose it clearly in a discussion or issue
  • Mark APIs as [Obsolete("Reason here")]
  • Remove obsolete APIs only in the next major release

Breaking changes should only be introduced in major version increments (v1.x → v2.x, etc.).

Maintaining API stability is essential for teams building long-lived applications on Blazorise.

Clone this wiki locally