Naming Convention sub component

[franklupo]

Hi,

i am developing a new component using the Fluent prefix. In the case of subcomponents how should i call them?
For example the FluentDataGrid has subcomponents called: PropertyColumn,SelectColumn,TemplateColumn.

If tomorrow i had to develop a new FluentDataGrid2 the column names are already taken.

The components are all at the same namespace level.

Wouldn't it be better to use the component prefix on the subcomponents?

I saw that Devexpres does this, DxGrid and the columns DxGridSelectionColumn, DxGridDataColumn.

Could we think of creating new ones with prefix and making the old ones obsolete?

best regards

[vnbaaij]

Hi,

While I welcome discussion about this, it also feels a bit like finding a solution to a problem that does not really exists

i am developing a new component using the Fluent prefix. In the case of subcomponents how should i call them? For example the FluentDataGrid has subcomponents called: PropertyColumn,SelectColumn,TemplateColumn.

If tomorrow i had to develop a new FluentDataGrid2 the column names are already taken.

What would then be stopping you from using PropertyColumn2,SelectColumn2 or TemplateColumn2?

The components are all at the same namespace level.

Yes, and that greatly improves discoverability for devs. If we would use separate namespaces, using's would need to be added in _Imports.cs, in .razor and/or .cs files.

Wouldn't it be better to use the component prefix on the subcomponents?

I saw that Devexpres does this, DxGrid and the columns DxGridSelectionColumn, DxGridDataColumn.

That works as they have a (rather cool) Dx prefix and a very short component name. For us it would then become something like FluentDataGridPropertyColumn which, although clear, is not very friendly.

And what happens if DevExpress decides to develop the next version of DxGrid? If that then would become DxGrid2, I think we know what will happen to the column names then, right? 😀

With doing this, we would stop having the Fluent-prefix only on 'top-level' components. With top-level I mean components that can be directly used in a page and produce rendered output. Granted, for a quite a few of those, like FluentAppBarItem or FluentAccordionItem it would not really make sense to use them standalone. I think having this distinction is the biggest advantage of keeping the 'scheme' as-is.

Could we think of creating new ones with prefix and making the old ones obsolete?

We can consider that for the next major version but it will also introduce another breaking change and code that needs to be changed/rewritten for people upgrading to that version.

[franklupo]

For backwards compatibility, you could create a file that aliases the usings. If necessary, user will import it.
You could create a FUI prefix for the new library.
For subcomponents, I always use the prefix.

[vnbaaij]

For backwards compatibility, you could create a file that aliases the usings. If necessary, user will import it.

Yes, but that is still extra work for the dev, needs to be documented by us, etc.

You could create a FUI prefix for the new library.

Bit too close to 'f*ck you' for me, 😁

For subcomponents, I always use the prefix.

I think Denis and I described how we see this.

[franklupo]

Understood

[dvoituron]

When organizing your Blazor components, especially sub-components, it's crucial to strike a balance between reusability and specificity.

It's not particularly useful to prefix subcomponents. The Fluent prefix we use is mainly to avoid confusion with similar standard components (such as FluentButton vs button) and to help the developer when writing code, thanks to Intellisense, which groups them easily.

Once in a main component (like the DataGrid), it's easier to access sub-components directly, with clear, concise names and, if possible, no abbreviations.

This is also the logic adopted by MudBlazor.

<MudDataGrid Items="@employees" Filterable="false" SortMode="@SortMode.None" Groupable="false">
    <Columns>
        <PropertyColumn Property="x => x.Name" />
        <PropertyColumn Property="x => x.Position" />
        <PropertyColumn Property="x => x.YearsEmployed" Title="Years Employed" />
        <PropertyColumn Property="x => x.Salary" Format="C" />
        <PropertyColumn Property="x => x.Salary * x.YearsEmployed" Title="Total Earned" Format="C" />
        <TemplateColumn CellClass="d-flex justify-end">
            <CellTemplate>
                <MudStack Row>
                    <MudRating Size="@Size.Small" SelectedValue="@context.Item.Rating" />
                    <MudButton Size="@Size.Small" Variant="@Variant.Filled" Color="@Color.Primary">Hire</MudButton>
                </MudStack>
            </CellTemplate>
        </TemplateColumn>
    </Columns>
</MudDataGrid>

[franklupo]

I noticed that there are different ways to indicate the same thing. Ex. Anchor (FluentTooltip), AnchorId (FluentPopover)
There are other cases of different names. Maybe we should unify the names

[vnbaaij]

Yes, absolutely. But for a next major (or minor if we do not too many at once) as these are breaking changes for which we need to provide mitigation steps. Or do it with Obsolete attributes and new properties

[franklupo]

Obsolete attributes and new properties

[franklupo]

Is there a shared todo list or roadmap?

[vnbaaij]

Is there a shared todo list or roadmap?

No, nothing formal. Denis and I both have a sort of list in paper/head/...

But we will work on making a more formal roadmap available here! (after the summer)