[wp-trac] [WordPress Trac] #37269: Introduce removed event for wp.customize.Values collection

WordPress Trac noreply at wordpress.org
Mon Jul 4 16:46:06 UTC 2016


#37269: Introduce removed event for wp.customize.Values collection
-------------------------+----------------------------------------
 Reporter:  westonruter  |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Future Release
Component:  Customize    |    Version:  trunk
 Severity:  normal       |   Keywords:  needs-patch good-first-bug
  Focuses:  javascript   |
-------------------------+----------------------------------------
 Notifications were added to Customizer controls in #34893. Notifications
 are re-rendered when the `control.notifications` collection (a
 `wp.customize.Values`) has a `wp.customize.Notification` added or removed
 with the code as follows (via `wp.customize.Control#initialize`):

 {{{#!js
 // After the control is embedded on the page, invoke the "ready" method.
 control.deferred.embedded.done( function () {
         /*
          * Note that this debounced/deferred rendering is needed for two
 reasons:
          * 1) The 'remove' event is triggered just _before_ the
 notification is actually removed.
          * 2) Improve performance when adding/removing multiple
 notifications at a time.
          */
         var debouncedRenderNotifications = _.debounce( function
 renderNotifications() {
                 control.renderNotifications();
         } );
         control.notifications.bind( 'add', function( notification ) {
                 wp.a11y.speak( notification.message, 'assertive' );
                 debouncedRenderNotifications();
         } );
         control.notifications.bind( 'remove', debouncedRenderNotifications
 );
         control.renderNotifications();

         control.ready();
 });
 }}}

 Notice the multi-line comment. We can't re-render the notifications at a
 `remove` event because this event gets triggered just ''before'' it is
 removed, somewhat unexpectedly. We should therefore introduce a `removed`
 event that gets triggered ''after'' the removal so that workarounds using
 `debounce` or `defer` aren't required.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37269>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list