Make the "add to cart" threshold configurable

I don’t love the fundamental assumption here, but I do not want to stand in the way of Drupal CMS.

I think the experience should be to assume a default of NULL (the experience we have today), but anyone doing a custom render element can set it to what they want (like the post-install recipe picker).

I might go so far as to someday allow a user to choose. If I think about Drupal CMS as a “way in” for ambitious site builders, I still think that shortly after settling on Drupal as a platform, they’ll want to be able to batch-add modules and/or batch apply recipes, and I think we need to consider their journey a little bit deeper.

I agree that this is much less likely to be confusing for an experienced user! But if you think about someone visiting the page for the first time, or first few times, it's different. The first time *I* saw the change, I was pretty thrown. Granted the queue / dequeue terminology was a big part of that, and we will fix that up. The overall UX of this pattern could be improved (hello, floating button!) and that is definitely part of the reaction to it currently.

If you think about the user's expectation, they see the module they want and then they expect to install it. After they choose one module, they may continue browsing and find another one, and another. I don't think the mental model for this is a shopping cart, because that's not how plugins or apps work anywhere else AFAIK. Maybe this is a queue behind the scenes but that's somewhat of a technical term that users probably don't really care about.

I completely understand the technical considerations and concerns about performance and we have to balance that. My opinion on the tradeoff right now is that it's probably better to align with the user's expectation for the behaviour (click install and it installs) rather than optimising for a performance concern that then makes the UX confusing.

I know a lot of this is UX, but there IS a lot of precedent for batch actions in Drupal - see the content page, for example. We do want/intend to change the UI from the floating button to something that matches the content page batch actions. And Queue/Dequeue language was the only thing stopping us from putting in a substantial feature that was truly often-requested in our listening sessions (granted, by more-experienced users).

But again, I'm not opposed to it behaving slightly differently in slightly different contexts.

📌 Change UI for the install queue to match bulk operations Active
📌 [PP-1] Decide on naming Queue/Dequeue button text Postponed

I think if the UI matched other bulk operations, it would be a lot less confusing.

But I also think part of the issue with this UX is that it's not clear that the reason for the queue is performance. I would guess that many new users would click Queue and then immediately click Install anyway. If I didn't have the context, I think I would certainly click Install before I did a new search, or went to a new page, since there's no indication that my selection would persist.

For my part I don't find that I am often installing a lot of contrib modules at once, other than early on in the project, and generally I know what these are so I wouldn't use d.o or even PB; I would just install them via composer. It's hard for me to picture someone frequently using PB to install a bunch of modules at once. Not saying it wouldn't happen, but it seems like it would be less common.

The functionality is complete, but tests are failing due to changes in functionality. I will update the tests if the changes in the MR align with the requirements specified in the issue.

Test failures seems not related to this issue. Other feedback addressed. It is ready for review again.

Looks like this needs to be synced with HEAD.

While testing this MR i found one issue with the current state of the MR.
When we click on install(when max_selection is set to 1 by default) the other button's label on the module cards toggle to select .Attaching the SS for the same.

While the captcha module is being installed you can see the other module's cards have select as the button's label.

Fixed the issue outlined in #18.Marking it NR.

Looks like this needs to be re-synced with HEAD. :(

Rebased with latest changes form HEAD.Marking it NR again.

The changes make sense to me but I found a few things that need to be changed. Nothing too serious, though.

Looks okay to me. No new test failures. Ship it.

NW for making configurable

It's a bit gauche of me to do this, but the circumstances are extenuating (we need this for Drupal CMS). Restoring RTBC.

Yeah, this rocks.

i've pulled the latest changes in 2.0.x but i wonder where is the threshold set introduced with this MR?

It's developer-facing. It's a property of the project_browser render element. The default behavior for users is unchanged.

Automatically closed - issue fixed for 2 weeks with no activity.