Problem/Motivation

Right now we are checking for `status_messages` block placed in the active theme, and using that block to render the confirmation message when product is added to cart.

AjaxAddToCartForm::refreshAddToCartForm()

    $block = self::getStatusMessagesBlock();
    if ($block) {
      $elements = [
        '#type' => 'status_messages',
      ];

      $response->addCommand(new RemoveCommand('.messages__wrapper'));
      $response->addCommand(new AppendCommand(".region-{$block->getRegion()}", \Drupal::service('renderer')->renderRoot($elements)));
    }

In my opinion I thought it is the best way to implement #2910738: Ajaxify the confirmation message.

Proposed resolution

Get this approach reviewed by someone. Ask Bojan or Matt Glaman for instance, or just ping in #contrib Drupal Slack channel.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Comments

subhojit777 created an issue. See original summary.

subhojit777’s picture

Status: Active » Fixed

I am closing this issue because I just committed a fix here #2920694-7: [Code Improvement] Unhardcode status message block id inside RefreshPageElementsHelper.

Earlier the block id for status messages was hardcoded. Although it is not clear in this issue description that why I didn't like the approach (apologies for being vague), I am quite sure that the hardcoding of block id was the main reason.

The block id is now obtained using an entityQuery() #2920694-3: [Code Improvement] Unhardcode status message block id inside RefreshPageElementsHelper. And this makes the code loosely coupled with the site settings.

I will create a new ticket if someone points out any fault in this approach in future.

  • subhojit777 committed af61196 on 8.x-1.x
    Issue #2915360 by subhojit777: Review the approach of showing...

Status: Fixed » Closed (fixed)

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