Use a regular entity listing for Commerce Product Attributes editing

I can confirm that, at least for our use cases with additional fields on custom attributes, a regular list of entity labels (like for taxonomy terms) with "Edit" links would be better than the current kind of inline entity form editing of the attributes in the entity type edit form!

The main reasons are:

• Many attributes lead to loading / memory issues
• SX / UX is not very nice with many attributes and additional fields
• The UX differs from typical Drupal entity listings

So in a first step it would be nice to get some maintainer feedback, which way to go here. Should the regular attributes entity listing (Drupal Core way) be implemented:

• in addition
• as replacement
• in contrib
• ...?

Thank you!

PS: While the memory limit error is a real kind of bug problem, I'd say we should categorize the regular listing as feature request, which is also able to solve that edge-case bug and improve / standardize SX / UX for more complex cases (where the inline entity editing might still be helpful for very simple cases!)

PPS: A real problem with the memory limit error is, that you can't even edit the Product Attributes (Entity type) settings any more, so I'd see the current implementation on the same page as antipattern and untypical for Drupal? (provocative thesis ;))

I feel a contrib module with a dependency on https://www.drupal.org/project/draggableviews → could fill the gap?

You could then replace the default list with a Views based alternative and add filters and paging and all the other bells and whistles?

In order to not to break the existing UI, I feel like we should add a threshold to the existing UI (e.g: Up to 50 attributes we just keep the existing UI), and if there is more than that, we should skip the inline form completely or something?

Thank you for your feedback!

I'm not a big fan of #6 due to the additional dependency and contrib solution, as the current built-in solutions is already differing from Drupal Core standards.

I agree with #7 - should we then add the regular list additionally? I don't think it would make things worse?

SX / UX is not very nice with many attributes and additional fields

When there are potentially 400 choices, how does the UI get better?

I'm just wondering, when someone is making a choice... 400 options?

@howards you're talking about the end-user UI? We're using these values headless and in different combinations, they are not all shown to the end-users ;D

In the admin backend, it should be just like having 400 terms in a taxonomy or 400 nodes of a node type. No problem. But the current inline edit display is a problem :)