There is no need to expose this method.
Can you maintain the scope internal?

internal is accessible in test.

Thank you for the feedback!

As I mentioned in the PR description, just to clarify our use case: in our project, we need to control group expansion programmatically. At the moment, since ToggleGroupExpand is not publicly accessible, we have to rely on reflection to invoke it, which is not ideal or maintainable in the long run. As a MudDataGrid user, I see real value in making this method part of the public API – toggling a specific group node programmatically is a legitimate requirement for many scenarios and should not be considered “internal-only” functionality.

Restricting GroupHierarchyKeysCollection to internal would also cause practical issues for us, as this would effectively block us from being able to use ToggleGroupExpand altogether. If this class is internal, then the GroupDefinition.HierarchyKeys property would also effectively become internal, which would prevent client code from accessing composite keys for advanced scenarios, or passing them to ToggleGroupExpand. This would greatly limit extensibility and force us into more reflection-based workarounds.

Additionally, having GroupHierarchyKeysCollection and ToggleGroupExpand available in the public API would enable advanced scenarios such as determining the precise subgroup within a GroupTemplate, and would provide a better user experience when building the content of a GroupTemplate in DataGridGroupRow, since it can be useful to know exactly which subgroup you are in.

In summary, exposing this type and method makes the library much more flexible for power users. We would greatly appreciate reconsidering making them public.

I agree, thank for the clarification.

Prefer flat namespace.

Done

The namespace should be MudBlazor, like the class GroupDefinition.

Done

There is no need to expose this class.
Can make this new class internal?

Added an answer in the comment section above

I don't think this work when the key is of a type that don't override ToString.
A more viable solution would be to store the keys in an array and compare each key one by one.

I have updated the implementation based on your suggestion. GroupHierarchyKeysCollection now overrides Equals and GetHashCode to compare and hash keys element by element. Also added unit tests for GroupHierarchyKeysCollectionto cover these changes.

Can you consider to use HashCode?
The documentation has a example where the hash is computed from a collection.

done

Unused?

removed unused field

The method now searches for columns by PropertyName instead of using the GroupBy selector. This could fail to find the correct column if PropertyName doesn't match the columnName parameter, especially for columns with custom selectors.

Creating a new GroupKeyPath from innerGroup.KeyPath assumes KeyPath implements IList<object?>, but it's a ReadOnlyCollection. This will likely cause a runtime error since ReadOnlyCollection doesn't implement IList<object?>.

The constructor parameter should validate that the input list is not null to prevent runtime exceptions when creating instances.

I would prefer this method signature :

/// <summary>
/// Expands or collapses the specified group.
/// </summary>
/// <param name="groupKeys">The group keys identifying the specific group to expand or collapse.</param>
/// <param name="expanded">Whether the group should be expanded (true) or collapsed (false).</param>
public void ExpandGroup(GroupKeyPath groupKeys, bool expanded)

@versile2?

Well it's not so much Expand, or Collapse, or Toggle, It should be SetGroupExpansion or something along those lines. bool expanded feeds how you want it, so it's not truly a toggle. It can expand, and it can collapse though.

I like SetGroupExpansion.

Using GroupDefinition.Title to identify the column in ToggleGroupExpand can be unreliable, as it's used to look up the column by PropertyName. A column's Title can be different from its PropertyName, which would cause this to fail.

To make this more robust, I suggest passing the PropertyName instead. This requires a few changes:

1. In src/MudBlazor/Components/DataGrid/GroupDefinition.cs, add a PropertyName property:

   public string PropertyName { get; set; } = string.Empty;

2. In src/MudBlazor/Components/DataGrid/MudDataGrid.razor.cs, populate this new property in ProcessGroup() and when cloning InnerGroup in GetGroupDefinitions():

   // In ProcessGroup()
   return new()
   {
       //...
       PropertyName = column.PropertyName,
       //...
   };
   
   // In GetGroupDefinitions() inside the innerGroup clone
   newGroupDefinition.InnerGroup = new GroupDefinition<T>
   {
       //...
       PropertyName = innerGroup.PropertyName,
       //...
   };

3. Finally, update this line to use the new property.

                DataGrid.ToggleGroupExpand(GroupDefinition.PropertyName, GroupDefinition.KeyPath, _expanded);