Problem/Motivation

The markup for the initial state of the progress bar is inside progress-bar.html.twg:

<div id="progress" class="progress">
  {% if label %}
    <div class="progress__label">{{ label }}</div>
  {% endif %}
  <div class="progress__track"><div class="progress__bar" style="width: {{ percent }}%"></div></div>
  <div class="progress__percentage">{{ percent }}%</div>
  <div class="progress__description">{{ message }}</div>
</div>

The markup for each 'update' of the progress bar added as a string inside of progress.js:

this.element = $('<div class="progress" aria-live="polite"></div>').attr('id', id);
    this.element.html('<div class="progress__label">&nbsp;</div>' +
      '<div class="progress__track"><div class="progress__bar"></div></div>' +
      '<div class="progress__percentage"></div>' +
      '<div class="progress__description">&nbsp;</div>');

If a theme wants to change the mark up of the progress bar they must do it in two places, which is not obvious. It's also more complex and potentially dangerous to change the mark up string in the the javascript:

setProgress: function (percentage, message, label) {
      if (percentage >= 0 && percentage <= 100) {
        $(this.element).find('div.progress__bar').css('width', percentage + '%');
        $(this.element).find('div.progress__percentage').html(percentage + '%');
      }
      $('div.progress__description', this.element).html(message);
      $('div.progress__label', this.element).html(label);
      if (this.updateCallback) {
        this.updateCallback(percentage, message, this);
      }
    },

To update the progress bar the javascript looks for specific classes in mark up/

Proposed resolution

This is a fun excuse to experiment with Twig.js. If we loaded progress-bar.html.twig on the front-end we would cut out the maintenance burden of specifying the code in two places as well as making it easy for themes to change the mark up.

We can also use this to make the JS less dependant on these specific progress bar classes but just passing the variables through the template each time instead of search for classes in the mark up.

Remaining tasks

  • Discuss
  • Write a patch

User interface changes

None

API changes

None?

Comments

nod_’s picture

To me that's really far off. We need contrib to try that stuff, I'm not comfortable adding that to core if it's not entirely complete and predictable. I'd like to though.

LewisNyman’s picture

Sure, I expect this issue to get pushed to 9.x but it would be nice to play around against an actual use case.

LewisNyman’s picture

Title: Use Twig.js to handle markup in progress.js » Use a theme function to handle markup in progress.js

I realised we could improve this now without using Twig.js

rob3000’s picture

@LewisNyman would the solution for this be by moving it all to a javascript theme??
e.g:

Dupal.theme.prototype.setProgress = function(name, url) {
  return '<a href="' + url + '">' + name + '</a>';
}
nod_’s picture

yes but it's Drupal.theme.whatever now. prototype is not used anymore.

nod_’s picture

rob3000’s picture

Awesome thanks nod_ i'll look at creating a patch for this ;)

rob3000’s picture

Assigned: Unassigned » rob3000
LewisNyman’s picture

Issue tags: +frontend
mgifford’s picture

Assigned: rob3000 » Unassigned

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.