Split the dataviews primary and non primary actions for display purposes

[afercia]

See #68789

This is a demo PR so far, to illustrate what I would like to propose for #68789

• Filters out the primary actions from the dataviews dropdown menus. The primary actions are already displayed outside of the menu as single buttons and displaying them in two places isn't ideal.
• When there's only one action available, it should display a single button and not a dropdown menu with only one action.

The second point implies that all actions should now have an icon. That's because any action may now be displayed as a single button if it's the only action available. So far, I've added a few icons for some actions but not for all of them yet.

This is a demo, I would greatly appreciate that someone else more familiar then me with dataviews could have a look at it as there's likely many things I'm missing.

What?

Closes

Why?

How?

Testing Instructions

Go to Pages and observe the 'Edit' action is not duplicate in the menu any longer:

Go to Templates and observe the only available action (Edit) is now displayed with a single icon button a no longer with an ellipsis dropdown menu that contains only one action:

Go to All Patterns and observe the only available action (Duplicate) is now displayed with a single icon button a no longer with an ellipsis dropdown menu that contains only one action:

Make sure you have at least one custom pattern (Duplicate one of the 'All patterns)'. Go to My patterns and observe all actions are inside the dropdown menu. This is unchanged from trunk and respects the isCompact prop.

Testing Instructions for Keyboard

Screenshots or screencast

Before	After

[jameskoster]

I'm a bit concerned about removing primary actions from the actions menu. The intended UX pattern is that the menu consistently includes all available actions, while consumers of the Dataviews component can highlight specific actions they believe users will need more frequently in layouts like Table and List. If we change this behavior, we'll introduce inconsistencies where the menu’s contents vary depending on the selected layout.

For example, on the Templates page, the Table layout actions menu would only include ‘Rename,’ whereas in Grid layout, it would contain ‘Edit,’ ‘Rename,’ and ‘Delete.’ This inconsistency could be frustrating for users who habitually access actions via the menu regardless of layout.

Additionally, visually inconsistencies would exist within the same page. In Grid layout on the Templates page, theme-supplied templates would have an 'Edit' icon button, while custom user-generated templates would display an ellipsis icon button. Furthermore, once a theme-supplied template is edited, the 'Edit' button would disappear, replaced by an ellipsis icon button that surfaces a menu including 'Edit' and 'Reset.' I don't know that this behvaior is helpful.

Finally, another reason to keep all actions in the menu is so that it can function as a context menu when users right-click a record, ensuring a consistent and predictable experience.

[afercia]

I understand the concerns but, to me, an ellipsis menu is a 'More' menu and should only show the actions that aren't shown in first function.
Also, rendering a dropdown menu that contains only one action doesn't really make sense.

[afercia]

P.S. when possible, please let's all try to keep the general discussion on the associated issue so that it's all in one place and not scattered around issues and PRs. Ideally, PRs should only serve to discuss the coding part.

[afercia]

Quoting from the issue:

I think using some with id check instead of includes would be a more robust approach here, like this:

const _nonPrimaryActions = _eligibleActions.filter(
      ( action ) =>
      !_primaryActions.some(
	   ( primaryAction ) => primaryAction.id === action.id
      )
);

@Rishit30G Sure totally in favor of improvements. Could you please add more context on why it would be more robust in your view?

[Rishit30G]

Sure @afercia,

For the given scenario, the code snippet with includes definitely works as expected!
This is because the objects in our primaryActions and eligibleActions arrays are referentially identical , _primaryActions is derived directly from _eligibleActions using filter().

But let's say in-future, these two situations arise:

• Actions are cloned or recreated.
• Actions are derived from different sources

In these two cases referential equality for objects will fail, so includes might not work
Hence, using some() with an ID check is safer and more future-proof choice, as it handles cases where object references might change.

[afercia]

Note: a few tests are failing so far. Those should be adjusted, and likely complemented with new tests, depending on the decision about how primary and non-primary actions should be displayed.